Received: from ietf.org by ietf.org id aa04100; 1 Aug 97 7:20 EDT Received: from ecrc.de by ietf.org id aa03848; 1 Aug 97 7:02 EDT Received: (qmail 20871 invoked from network); 1 Aug 1997 10:57:32 -0000 Received: from scorpio.ecrc.de (141.1.4.100) by ecrc.de with SMTP; 1 Aug 1997 10:57:32 -0000 Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125]) by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP id MAA25921; Fri, 1 Aug 1997 12:57:31 +0200 (MET DST) Sender:ietf-request@ietf.org From: Dave Morton Received: (from dave@localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id MAA18973; Fri, 1 Aug 1997 12:57:29 +0200 (MET DST) Date: Fri, 1 Aug 1997 12:57:29 +0200 (MET DST) Message-Id: <199708011057.MAA18973@acrab25.ecrc.de> To: IETF@ietf.org, pjnesser@martigny.ai.mit.edu Subject: Re: ip addresses for Munich Source-Info: From (or Sender) name not authenticated. >Have I somehow missed the information about getting IP addresses early for >laptops that need to be configured for firewalls? Will they be available >before the IETF? Phil, I just send the E-mail below to the IETF announcement list. Sorry for the delay. Dave >---> Phil >Date: Fri, 1 Aug 1997 12:30:32 +0200 (MET DST) >To: ietf-announce@ietf.org >Subject: Munich - 39th IETF Terminal Room Annoucement >Cc: Philip.Horn@ecrc.de, hubert@multinet.de, maly@multinet.de, > Todd.Ferguson@ecrc.de, noc@ecrc.de >Status: R > >Dear IETF Munich attendees, > >This message contains some information about the terminal room for >the 39th IETF meeting to be held in Munich, Germany, 11-15 August 1997. >Sorry about the delay in getting this info. out to you for those who >need to pre-cofigure firewalls etc. > >The terminal room will be located in the Munich Room, basement level >if the Sheraton Hotel. > >The terminal room will be available at the latest from 12:00 on Sunday >to 12:00 on Friday with Help Desk coverage from 8 am to 8pm. > >The terminal room will be eqipped with > >o 4 Fujitsu/ICL Printers (3 plain paper & 1 overhead transparencies) >o 30 Silicon Graphics O2 Workstations. >o 20 PCs/Network Computers Siemens-Nixdorf and two servers > >All the SGIs and PCs will be numbered out of the Class-C network >195.27.192.128/25 > >All SGIs will have Netscape Navigator 3.0, Netscape Mail und News Reader 2.0. >All PCs will operate Win-95, Microsoft Internet Explorer, MS-Office 97. > >There will be 100 10BaseT drops for laptops and few Localtalk drops for >those with Macs. > >All of the laptops will be numbered out of the Class C network >195.27.194.0/23. > >Digital will be providing some 2.422 GHz RoamAbout adapters and 3 access >points for the 39th IETF. These will be numbered out of the Class-C network >195.27.193.0/24. > >A DHCP server (195.27.192.0/27) will be operating to allocate addresses >to DHCP speaking clients. > >All machines will be part of the domain ietf.de. > >Looking forward to seeing everyone in Munich. > >Best regards, >Dave Morton   Received: from ietf.org by ietf.org id aa04743; 1 Aug 97 7:54 EDT Received: from ietf.ietf.org by ietf.org id aa04536; 1 Aug 97 7:48 EDT To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: Dave Morton Subject: Munich - 39th IETF Terminal Room Annoucement Date: Fri, 01 Aug 1997 07:48:57 -0400 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9708010748.aa04536@ietf.org> Dear IETF Munich attendees, This message contains some information about the terminal room for the 39th IETF meeting to be held in Munich, Germany, 11-15 August 1997. Sorry about the delay in getting this info. out to you for those who need to pre-cofigure firewalls etc. The terminal room will be located in the Munich Room, basement level if the Sheraton Hotel. The terminal room will be available at the latest from 12:00 on Sunday to 12:00 on Friday with Help Desk coverage from 8 am to 8pm. The terminal room will be eqipped with o 4 Fujitsu/ICL Printers (3 plain paper & 1 overhead transparencies) o 30 Silicon Graphics O2 Workstations. o 20 PCs/Network Computers Siemens-Nixdorf and two servers All the SGIs and PCs will be numbered out of the Class-C network 195.27.192.128/25 All SGIs will have Netscape Navigator 3.0, Netscape Mail und News Reader 2.0. All PCs will operate Win-95, Microsoft Internet Explorer, MS-Office 97. There will be 100 10BaseT drops for laptops and few Localtalk drops for those with Macs. All of the laptops will be numbered out of the Class C network 195.27.194.0/23. Digital will be providing some 2.422 GHz RoamAbout adapters and 3 access points for the 39th IETF. These will be numbered out of the Class-C network 195.27.193.0/24. A DHCP server (195.27.192.0/27) will be operating to allocate addresses to DHCP speaking clients. All machines will be part of the domain ietf.de. Looking forward to seeing everyone in Munich. Best regards, Dave Morton   Received: from ietf.org by ietf.org id aa08626; 1 Aug 97 9:44 EDT Received: from ietf.ietf.org by ietf.org id aa08532; 1 Aug 97 9:41 EDT To: IETF-Announce: ; Subject: WG ACTION: Humanities and Arts (harts) to conclude Date: Fri, 01 Aug 1997 09:41:11 -0400 Sender:ietf-announce-request@ietf.org From: Steve Coya Message-ID: <9708010941.aa08532@ietf.org> The Humanities and Arts (harts) Working Group of the User Services Areas has concluded. The mailing list will remain active until the end of the year. The IESG contact person is Joyce K. Reynolds   Received: from ietf.org by ietf.org id aa09147; 1 Aug 97 9:51 EDT Received: from jazz.viagenie.qc.ca by ietf.org id aa09047; 1 Aug 97 9:50 EDT Received: from classic.viagenie.qc.ca by jazz.viagenie.qc.ca (VG1.0/Viagenie) id JAA06973; Fri, 1 Aug 1997 09:43:14 -0400 Message-Id: <3.0.1.32.19970801094708.0271b598@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 01 Aug 1997 09:47:08 -0400 To: Dave Morton Sender:ietf-request@ietf.org From: Marc Blanchet Subject: Re: Munich - 39th IETF Terminal Room Annoucement Cc: ietf@ietf.org In-Reply-To: <9708010748.aa04536@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Source-Info: From (or Sender) name not authenticated. It would be very useful to have SSH installed on the PC and SGI, if it is possible. To download: http://www.DataFellows.com/f-secure/ssh/download.htm Regards, Marc. At 07:48 97-08-01 -0400, you wrote: >Dear IETF Munich attendees, > >This message contains some information about the terminal room for >the 39th IETF meeting to be held in Munich, Germany, 11-15 August 1997. >Sorry about the delay in getting this info. out to you for those who >need to pre-cofigure firewalls etc. > >The terminal room will be located in the Munich Room, basement level >if the Sheraton Hotel. > >The terminal room will be available at the latest from 12:00 on Sunday >to 12:00 on Friday with Help Desk coverage from 8 am to 8pm. > >The terminal room will be eqipped with > >o 4 Fujitsu/ICL Printers (3 plain paper & 1 overhead transparencies) >o 30 Silicon Graphics O2 Workstations. >o 20 PCs/Network Computers Siemens-Nixdorf and two servers > >All the SGIs and PCs will be numbered out of the Class-C network >195.27.192.128/25 > >All SGIs will have Netscape Navigator 3.0, Netscape Mail und News Reader 2.0. >All PCs will operate Win-95, Microsoft Internet Explorer, MS-Office 97. > >There will be 100 10BaseT drops for laptops and few Localtalk drops for >those with Macs. > >All of the laptops will be numbered out of the Class C network >195.27.194.0/23. > >Digital will be providing some 2.422 GHz RoamAbout adapters and 3 access >points for the 39th IETF. These will be numbered out of the Class-C network >195.27.193.0/24. > >A DHCP server (195.27.192.0/27) will be operating to allocate addresses >to DHCP speaking clients. > >All machines will be part of the domain ietf.de. > >Looking forward to seeing everyone in Munich. > >Best regards, >Dave Morton > > > ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagenie inc. | http://www.viagenie.qc.ca 3107 des hotels | tel.: 418-656-9254 Ste-Foy, Quebec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ pgp: 57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7 ------------------------------------------------------------ Auteur du livre TCP/IP Simplifi, Editions Logiques, 1997 ------------------------------------------------------------   Received: from ietf.org by ietf.org id aa09991; 1 Aug 97 9:57 EDT Received: from [207.41.52.2] by ietf.org id aa09554; 1 Aug 97 9:56 EDT Received: by quest_1.symquest.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BC9E60.B44597C0@quest_1.symquest.com>; Fri, 1 Aug 1997 09:53:03 -0400 Message-ID: Sender:ietf-request@ietf.org From: David Wolfe To: "'ietf@ietf.org'" Subject: Attending IETF the meeting via multicast/broadcast media. Date: Fri, 1 Aug 1997 09:53:02 -0400 Return-Receipt-To: X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. This will be the third IETF meeting that I have tried to attend via a multicast/broadcast. I would appreciate a pointer to the location of information that might result in my success. If possible, please reply via email to minimize list traffic. Thank you, in advance, for your time and attention. -dw ++++++++++++++++++++++++++++++++++++++++++++++++++++++ David A. Wolfe SymQuest Group Sales Engineer Mailto:dwolfe@woofnet.com EdNet Manager/Instructor dwolfe@symquest.com 802.658.9869 (voice) http://www.woofnet.com/~woof/ 802.658.9801 (fax) http://www.symquest.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++   Received: from ietf.org by ietf.org id aa10045; 1 Aug 97 9:57 EDT Received: from ecrc.de by ietf.org id aa09719; 1 Aug 97 9:56 EDT Received: (qmail 26124 invoked from network); 1 Aug 1997 13:52:01 -0000 Received: from scorpio.ecrc.de (141.1.4.100) by ecrc.de with SMTP; 1 Aug 1997 13:52:01 -0000 Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125]) by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP id PAA28668; Fri, 1 Aug 1997 15:51:58 +0200 (MET DST) Sender:ietf-request@ietf.org From: Dave Morton Received: (from dave@localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id PAA19444; Fri, 1 Aug 1997 15:51:57 +0200 (MET DST) Date: Fri, 1 Aug 1997 15:51:57 +0200 (MET DST) Message-Id: <199708011351.PAA19444@acrab25.ecrc.de> To: Dave.Morton@ecrc.de, Marc.Blanchet@viagenie.qc.ca Subject: Re: Munich - 39th IETF Terminal Room Annoucement Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. >It would be very useful to have SSH installed on the PC and SGI, if it is >possible. > >To download: http://www.DataFellows.com/f-secure/ssh/download.htm > >Regards, Marc. Marc, that can be done - thanks for pointer. Dave   Received: from ietf.org by ietf.org id aa13550; 1 Aug 97 10:08 EDT Received: from ietf.ietf.org by ietf.org id aa12975; 1 Aug 97 10:06 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-asid-ldap-mult-mast-rep-01.txt Date: Fri, 01 Aug 1997 10:06:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011006.aa12975@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : LDAP Multi-master Replication Protocol Author(s) : Chris Weider and J. Strassner Filename : draft-ietf-asid-ldap-mult-mast-rep-01.txt Pages : 8 Date : 31-Jul-97 This paper defines a multi-master, incremental replication protocol using the LDAP protocol [LDAPv3]. This protocol uses and builds upon previous LDAP support protocols, namely the changelog [change] and LDIF [LDIF] protocols. It defines the use of two types of transport protocols for replication data, and specifies the schema that must be supported by a server that wishes to participate in replication activities using this protocol. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-asid-ldap-mult-mast-rep-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-ldap-mult-mast-rep-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-asid-ldap-mult-mast-rep-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13565; 1 Aug 97 10:08 EDT Received: from ietf.ietf.org by ietf.org id aa12913; 1 Aug 97 10:06 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ipp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-ipp-security-01.txt Date: Fri, 01 Aug 1997 10:06:44 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011006.aa12913@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Security Author(s) : R. deBry and J. Hadsell and D. Manchala and X. Riley and J. Wenn Filename : draft-ietf-ipp-security-01.txt Pages : 18 Date : 1997-07-31 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard, which describes a distributed printing service. The full set of IPP documents includes: Requirements for an Internet Printing Protocol Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Security Internet Printing Protocol/1.0: Protocol Specification Internet Printing Protocol/1.0: Directory Schema This document is the `Internet Printing Protocol/1.0: Security' document. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-ipp-security-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-security-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-ipp-security-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731114339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-security-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-ipp-security-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731114339.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13558; 1 Aug 97 10:08 EDT Received: from ietf.ietf.org by ietf.org id aa12848; 1 Aug 97 10:06 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-wang-mpls-scaling-atm-00.txt Date: Fri, 01 Aug 1997 10:06:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011006.aa12848@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Scalability Issues in Label Switching over ATM Author(s) : G. Armitage and Zheng Wang Filename : draft-wang-mpls-scaling-atm-00.txt Pages : 6 Date : 30-Jul-97 The scalability of label switching over ATM is one of fundamental issues in MPLS that has not been fully understood. Whether or not one should assume stream merging in ATM is a major design decision that has many implications to MPLS protocols and ATM hardware design. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-wang-mpls-scaling-atm-00.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-wang-mpls-scaling-atm-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-wang-mpls-scaling-atm-00.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731112607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wang-mpls-scaling-atm-00.txt --OtherAccess Content-Type: Message/External-body; name='draft-wang-mpls-scaling-atm-00.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731112607.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13772; 1 Aug 97 10:09 EDT Received: from ietf.ietf.org by ietf.org id aa13329; 1 Aug 97 10:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: snmpv3@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-snmpv3-usm-01.txt Date: Fri, 01 Aug 1997 10:07:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011007.aa13329@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) Author(s) : Bert Wijnen and U. Blumenthal Filename : draft-ietf-snmpv3-usm-01.txt Pages : 72 Date : 31-Jul-97 This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-snmpv3-usm-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-usm-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-snmpv3-usm-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-usm-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-snmpv3-usm-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13796; 1 Aug 97 10:09 EDT Received: from ietf.ietf.org by ietf.org id aa13407; 1 Aug 97 10:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: snmpv3@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-snmpv3-acm-02.txt Date: Fri, 01 Aug 1997 10:07:45 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011007.aa13407@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : View-based Access Control Model for the Simple Network Management Protocol (SNMP) Author(s) : Keith McCloghrie and Bert Wijnen and Randy Presuhn Filename : draft-ietf-snmpv3-acm-02.txt Pages : 38 Date : 31-Jul-97 This document describes the View-based Access Control Model for use in the SNMP architecture [SNMP-ARCH]. It defines the Elements of Procedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-snmpv3-acm-02.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-acm-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-snmpv3-acm-02.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-acm-02.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-snmpv3-acm-02.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970505173055.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14176; 1 Aug 97 10:09 EDT Received: from ietf.ietf.org by ietf.org id aa13690; 1 Aug 97 10:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-goland-url-dns-00.txt Date: Fri, 01 Aug 1997 10:08:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011008.aa13690@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Uniform Resource Locators (URL): DNS URL Naming Scheme Author(s) : Y. Goland Filename : draft-goland-url-dns-00.txt Pages : 2 Date : 31-Jul-97 This document proposes mapping DNS names into the URL scheme space for the purpose of preventing namespace collisions amongst URL schemes whose syntax and functionality are not appropriate for standardization. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-goland-url-dns-00.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-goland-url-dns-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-goland-url-dns-00.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731155416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-goland-url-dns-00.txt --OtherAccess Content-Type: Message/External-body; name='draft-goland-url-dns-00.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731155416.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14297; 1 Aug 97 10:10 EDT Received: from ietf.ietf.org by ietf.org id aa13831; 1 Aug 97 10:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: receipt@cs.utk.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-receipt-mdn-05.txt Date: Fri, 01 Aug 1997 10:08:57 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011008.aa13831@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Receipt Notifications for Internet Mail Working Group of the IETF. Title : An Extensible Message Format for Message Disposition Notifications Author(s) : Roger Fajman Filename : draft-ietf-receipt-mdn-05.txt Pages : 30 Date : 1997-07-31 This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary 'LAN-based' systems, and often referred to as 'read receipts,' 'acknowledgements,' or 'receipt notifications.' The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary 'LAN-based' systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of 'foreign' addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support 'tunneling' of foreign notifications through Internet Mail. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-receipt-mdn-05.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-receipt-mdn-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-receipt-mdn-05.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731161416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-receipt-mdn-05.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-receipt-mdn-05.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731161416.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14402; 1 Aug 97 10:10 EDT Received: from ietf.ietf.org by ietf.org id aa13949; 1 Aug 97 10:09 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-gordon-ufdl-spec-00.txt Date: Fri, 01 Aug 1997 10:09:11 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011009.aa13949@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Universal Forms Description Language Specification Version 3.2 Author(s) : D. Manning, R. Bennett, J. Boyer, S. McLellan, M. Mansell Filename : draft-gordon-ufdl-spec-00.txt Pages : 148 Date : 31-Jul-97 The Universal Forms Description Language (UFDL) describes complex business forms for use over the Internet. The objective of the UFDL is to enable the creation of cross-platform Internet business forms that (1) contain both the complex logic and precise layout that administrators require, (2) are simple to maintain and distribute, and (3) integrate easily with existing business systems. As more and more business is done over the Internet, the need for a form description language that incorporates these features grows. HTML is designed for Internet pages, and is severely limited as a form language. This document specifies the vocabulary, syntax, and meaning of the UFDL. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-gordon-ufdl-spec-00.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-gordon-ufdl-spec-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-gordon-ufdl-spec-00.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731160332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gordon-ufdl-spec-00.txt --OtherAccess Content-Type: Message/External-body; name='draft-gordon-ufdl-spec-00.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731160332.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14593; 1 Aug 97 10:10 EDT Received: from ietf.ietf.org by ietf.org id aa14086; 1 Aug 97 10:09 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ietf-ssh@clinet.fi Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-secsh-userauth-01.txt Date: Fri, 01 Aug 1997 10:09:26 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011009.aa14086@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen Filename : draft-ietf-secsh-userauth-01.txt Pages : 12 Date : 1997-07-31 This documents describes the SSH authentication protocol. It is used to prove that the client is authorized access the requested service with the supplied user name. This authorization can be demonstrated through possession of a password, through possession of a key, by authenticating the client host and user, by some other method, or a combination of these. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-secsh-userauth-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-userauth-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-secsh-userauth-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731162651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-secsh-userauth-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731162651.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14601; 1 Aug 97 10:10 EDT Received: from ietf.ietf.org by ietf.org id aa14022; 1 Aug 97 10:09 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ietf-ssh@clinet.fi Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-secsh-transport-01.txt Date: Fri, 01 Aug 1997 10:09:19 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011009.aa14022@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen Filename : draft-ietf-secsh-transport-01.txt Pages : 22 Date : 1997-07-31 This document describes the SSH transport layer protocol. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-secsh-transport-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-transport-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-secsh-transport-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731162435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-secsh-transport-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731162435.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14853; 1 Aug 97 10:11 EDT Received: from ietf.ietf.org by ietf.org id aa14409; 1 Aug 97 10:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-asid-inetorgperson-01.txt Date: Fri, 01 Aug 1997 10:10:08 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011010.aa14409@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : Definition of the inetOrgPerson Object Class Author(s) : Mark Smith Filename : draft-ietf-asid-inetorgperson-01.txt Pages : 17 Date : 1997-07-31 This document describes the SSH connection protocol. It multiplexes a single encrypted tunnel into a number of channels (interactive sessions, forwarded TCP/IP ports, X11 connections, etc). It is intended to run above the SSH user authentication layer. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-asid-inetorgperson-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-inetorgperson-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-asid-inetorgperson-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731165352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-inetorgperson-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-asid-inetorgperson-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731165352.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa14909; 1 Aug 97 10:11 EDT Received: from ietf.ietf.org by ietf.org id aa14479; 1 Aug 97 10:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-asid-ldap-c-api-00.txt Date: Fri, 01 Aug 1997 10:10:15 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011010.aa14479@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : The C LDAP Application Program Interface Author(s) : Chris Weider and Tim Howes and Mark Smith and M. Wahl and A. Herron Filename : draft-ietf-asid-ldap-c-api-00.txt Pages : 53 Date : 31-Jul-97 This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This document replaces the previous definition of this API, defined in RFC 1823, updating it to include support for features found in version 3 of the LDAP protocol. New extended operation functions were added to support LDAPv3 features such as controls. In addition, other LDAP API changes were made to support information hiding and thread safety. The C LDAP API is designed to be powerful, yet simple to use. It defines compatible synchronous and asynchronous interfaces to LDAP to suit a wide variety of applications. This document gives a brief overview of the LDAP model, then an overview of how the API is used by an applica- tion program to obtain LDAP information. The API calls are described in detail, followed by an appendix that provides some example code demon- strating the use of the API. This document provides information to the Internet community. It does not specify any standard. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-asid-ldap-c-api-00.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldap-c-api-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-asid-ldap-c-api-00.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731170017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-ldap-c-api-00.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-asid-ldap-c-api-00.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731170017.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15004; 1 Aug 97 10:13 EDT Received: from ietf.ietf.org by ietf.org id aa14597; 1 Aug 97 10:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ippcp@external.cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-ippcp-lzs-00.txt Date: Fri, 01 Aug 1997 10:10:29 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011010.aa14597@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Using LZS Author(s) : R. Monsour Filename : draft-ietf-ippcp-lzs-00.txt Pages : 8 Date : 1907-07-31 This document describes a IP compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [Thomas]. [Thomas] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-ippcp-lzs-00.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-lzs-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-ippcp-lzs-00.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731172434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-lzs-00.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-ippcp-lzs-00.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731172434.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15206; 1 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa14332; 1 Aug 97 10:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Cc: ietf-ssh@clinet.fi Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-ietf-secsh-connect-01.txt Date: Fri, 01 Aug 1997 10:10:00 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011010.aa14332@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : T. Ylonen Filename : draft-ietf-secsh-connect-01.txt Pages : 17 Date : 1997-07-31 This document describes the SSH connection protocol. It multiplexes a single encrypted tunnel into a number of channels (interactive sessions, forwarded TCP/IP ports, X11 connections, etc). It is intended to run above the SSH user authentication layer. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-secsh-connect-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-connect-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-ietf-secsh-connect-01.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731163606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-secsh-connect-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731163606.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa15470; 1 Aug 97 10:27 EDT Received: from ietf.ietf.org by ietf.org id aa15423; 1 Aug 97 10:26 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary='NextPart' To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION: draft-goland-url-dns-00.txt Date: Fri, 01 Aug 1997 10:26:08 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011026.aa15423@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Uniform Resource Locators (URL): DNS URL Naming Scheme Author(s) : Y. Goland Filename : draft-goland-url-dns-00.txt Pages : 2 Date : 31-Jul-97 This document proposes mapping DNS names into the URL scheme space for the purpose of preventing namespace collisions amongst URL schemes whose syntax and functionality are not appropriate for standardization. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-goland-url-dns-00.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-goland-url-dns-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: 'FILE /internet-drafts/draft-goland-url-dns-00.txt'. NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the 'mpack' utility. To use this feature, insert the command 'ENCODING mime' before the 'FILE' command. To decode the response(s), you will need 'munpack' or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with 'multipart' MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary='OtherAccess' OtherAccess Content-Type: Message/External-body; access-type='mail-server'; server='mailserv@ds.internic.net' Content-Type: text/plain Content-ID: <19970731155416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-goland-url-dns-00.txt --OtherAccess Content-Type: Message/External-body; name='draft-goland-url-dns-00.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970731155416.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa28127; 1 Aug 97 11:56 EDT Received: from ietf.ietf.org by ietf.org id aa27792; 1 Aug 97 11:53 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-laubach-ip-over-802d14-00.txt Date: Fri, 01 Aug 1997 11:53:59 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708011153.aa27792@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Logical IP Subnetworks over IEEE 802.14 Services Author(s) : M. Laubach Filename : draft-laubach-ip-over-802d14-00.txt Pages : 13 Date : 1997-08-01 This memo defines an initial application of classical IP and ARP in an IEEE 802.14 Community Access Television (CATV) Residential Access Network environment. IEEE 802.14 services provide two independent link layer service interfaces which are available to support IP residential access networking services: traditional Ethernet bridging (via IEEE 802.1D layer services) and residential ATM networking services. In this memo, the term Logical IP Subnetwork (LIS) is defined to apply to Classical IP over ATM LIS's operating over IEEE 802.14 services as well as traditional IP over Ethernet operating over IEEE 802.14 services. The recommendations in this draft rely on existing IETF standards for the family of Classical IP and ARP over ATM (IPOA) services and for IP and ARP over Broadcast Ethernet networks. The tree-based hierarchic nature of the IEEE 802.14 MAC subnetwork permits convenient extensions to Classical IPOA model for broadcast and multicast in the downstream direction of the CATV plant. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-laubach-ip-over-802d14-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-laubach-ip-over-802d14-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-laubach-ip-over-802d14-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801113614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-laubach-ip-over-802d14-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-laubach-ip-over-802d14-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801113614.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09034; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08043; 2 Aug 97 11:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: snmpv3@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-snmpv3-appl-01.txt Date: Sat, 02 Aug 1997 11:38:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021138.aa08043@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Version 3 Working Group of the IETF. Title : SNMPv3 Applications Author(s) : B. Stewart, D. Levi, P. Meyer Filename : draft-ietf-snmpv3-appl-01.txt Pages : 68 Date : 01-Aug-97 This memo describes the various types of SNMP applications which make use of an SNMP engine as described in [SNMP-ARCH]. There are five types of application described herein: - Applications which initiate SNMP Get, GetNext, GetBulk, and/or Set requests, called 'command generators'. - Applications which respond to SNMP Get, GetNext, GetBulk, and/or Set requests, called 'command responders'. - Applications which generate notifications, called 'notification originators'. - Applications which forward SNMP Get, GetNext, GetBulk, and/or Set requests or notifications, called 'proxy forwarders'. This memo also defines MIBs for specifying targets of management operations, for notification filtering, and for proxy forwarding. - Applications which receive notifications, called 'notification receivers'. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-snmpv3-appl-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-snmpv3-appl-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-snmpv3-appl-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801150823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-snmpv3-appl-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-snmpv3-appl-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801150823.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09026; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08131; 2 Aug 97 11:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: cat-ietf@mit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-init-04.txt Date: Sat, 02 Aug 1997 11:39:03 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021139.aa08131@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Cryptography for Initial Authentication in Kerberos Author(s) : C. Neuman, J. Wray, B. Tung, J. Trostle, A. Medvinsky Filename : draft-ietf-cat-kerberos-pk-init-04.txt Pages : 13 Date : 1997-08-01 This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerberos-pk-init-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerberos-pk-init-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801153504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-init-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-init-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801153504.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09015; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08013; 2 Aug 97 11:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: mobile-ip@smallworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mobileip-ipv6-03.txt Date: Sat, 02 Aug 1997 11:38:32 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021138.aa08013@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : C. Perkins, D. Johnson Filename : draft-ietf-mobileip-ipv6-03.txt Pages : 58 Date : 1997-08-01 This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send packets destined for the mobile node directly to it at this care-of address. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-ipv6-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ipv6-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-ipv6-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801150438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801150438.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09035; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08160; 2 Aug 97 11:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-tung-transsec-sts-01.txt Date: Sat, 02 Aug 1997 11:39:07 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021139.aa08160@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Simple Transaction Security (STS) Author(s) : B. Tung Filename : draft-tung-transsec-sts-01.txt Pages : 4 Date : 01-Aug-97 This document describes Simple Transaction Security (STS), a protocol for specifying services and protocols used to secure an enclosed message. The framework is flexible enough to allow a wide variety of protocols to be used, at the cost of some negotiation and the optimizations present in protocols such as S-HTTP. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-tung-transsec-sts-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-tung-transsec-sts-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-tung-transsec-sts-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801154956.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-tung-transsec-sts-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-tung-transsec-sts-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801154956.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09018; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08191; 2 Aug 97 11:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kemp-auth-pklogin-03.txt Date: Sat, 02 Aug 1997 11:39:17 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021139.aa08191@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Public Key Login Protocol Author(s) : D. Kemp Filename : draft-kemp-auth-pklogin-03.txt Pages : 18 Date : 1997-08-01 This document defines the Public Key Login (PKL) protocol, a challenge- response authentication mechanism using digital signatures. It provides start-of-session authentication for firewall proxies, dial-up Network Access Servers, remote email servers, and interactive protocols such as Telnet and FTP. It provides functionality similar to One Time Passwords and handheld authentication tokens, and it supports both one-way and mutual authentication. PKL uses the authentication exchanges specified in ISO/IEC 9798-3 and NIST FIPS Pub 196. The PKL protocol provides strong authentication at the beginning of a session, but does not by itself provide communication channel integrity or confidentiality. PKL should be used in conjunction with a channel integrity mechanism, for example to provide authentication of individual users over (host-keyed) Virtual Private Network connections. This Internet Draft is intended to be the last version of the PKL specification prior to publication as an Informational RFC. Comments are requested no later than the expiration date of this draft. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kemp-auth-pklogin-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kemp-auth-pklogin-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kemp-auth-pklogin-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801162200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kemp-auth-pklogin-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-kemp-auth-pklogin-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801162200.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09030; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08264; 2 Aug 97 11:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: w3c-dist-auth@w3.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-webdav-protocol-01.txt Date: Sat, 02 Aug 1997 11:39:26 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021139.aa08264@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Extensions for Distributed Authoring and Versioning on the World Wide Web -- WEBDAV Author(s) : J. Whitehead, D. Jensen, S. Carter, Y. Goland, A. Faizi Filename : draft-ietf-webdav-protocol-01.txt Pages : 65 Date : 1997-08-01 This Document specifies a set of methods and content-types ancillary to HTTP/1.1 for the management of resource properties, simple name space manipulation, simple resource locking (collision avoidance) and resource version control. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-protocol-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-protocol-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-webdav-protocol-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801162656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-protocol-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801162656.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09038; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08214; 2 Aug 97 11:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-state-man-mec-03.txt,.ps Date: Sat, 02 Aug 1997 11:39:12 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021139.aa08214@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. Title : HTTP State Management Mechanism (Rev1) Author(s) : D. Kristol, L. Montulli Filename : draft-ietf-http-state-man-mec-03.txt,.ps Pages : 22 Date : 1997-08-01 This document specifies a way to create a stateful session with HTTP requests and responses. It describes two new headers, Cookie and Set- Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL section.) This document reflects implementation experience with RFC 2109 and obsoletes it. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-http-state-man-mec-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-man-mec-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-state-man-mec-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801155844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-state-man-mec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-state-man-mec-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801155844.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09023; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08461; 2 Aug 97 11:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-esp-v2-00.txt Date: Sat, 02 Aug 1997 11:39:58 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021139.aa08461@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Encapsulating Security Payload (ESP) for Implementors Author(s) : W. Simpson Filename : draft-simpson-esp-v2-00.txt Pages : 15 Date : 1997-08-01 This document describes a confidentiality mechanism for IP datagrams. Payload headers are encapsulated within an opaque envelope. Under some circumstances, authentication and integrity are optionally provided for IP datagrams. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-esp-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-esp-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-esp-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801171813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-esp-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-esp-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801171813.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09036; 2 Aug 97 11:53 EDT Received: from ietf.ietf.org by ietf.org id aa08095; 2 Aug 97 11:38 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-agent-options-02.txt Date: Sat, 02 Aug 1997 11:38:46 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021138.aa08095@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Relay Agent Information Option Author(s) : M. Patrick Filename : draft-ietf-dhc-agent-options-02.txt Pages : 11 Date : 1997-08-01 Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more user hosts. It is advantageous to use DHCP to assign user host IP addresses in this environment, but a number of security and scaling problems arise with such 'public' DHCP use. This draft calls for the definition of a 'DHCP Relay Agent Information' option that is appended to a DHCP packet forwarded from a client to a server by a relay agent. The Server may or may not use the information in the the Relay Agent Information option; in either case, it echoes back the option verbatim in server-to-client replies. The 'Relay Agent Information' option contains sub-options that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a 'circuit ID' for the incoming circuit and a 'remote ID' which provides a trusted identifier for the remote high-speed modem. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agent-options-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-agent-options-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-options-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801152536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-options-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-options-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801152536.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09287; 2 Aug 97 11:57 EDT Received: from ietf.ietf.org by ietf.org id aa09228; 2 Aug 97 11:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-fax@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-fax-tiff-reg-01.txt Date: Sat, 02 Aug 1997 11:55:14 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021155.aa09228@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Fax Working Group of the IETF. Title : Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration Author(s) : G. Parsons, J. Rafferty Filename : draft-ietf-fax-tiff-reg-01.txt Pages : 5 Date : 1997-08-01 This document describes the registration of the MIME sub-type image/tiff. The baseline encoding is defined by [TIFF]. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-fax-tiff-reg-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-fax-tiff-reg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-fax-tiff-reg-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801141801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-fax-tiff-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-fax-tiff-reg-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801141801.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09787; 2 Aug 97 12:00 EDT Received: from ietf.ietf.org by ietf.org id aa09383; 2 Aug 97 11:58 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-calendar@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-mod-01.txt Date: Sat, 02 Aug 1997 11:58:41 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021158.aa09383@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Internet Calendar Model Specification Author(s) : J. Noerenberg Filename : draft-ietf-calsch-mod-01.txt Pages : 17 Date : 01-Aug-97 Internet Calendaring and Scheduling protocols require the definition of objects to encapsulate an event to be scheduled, a calendar on which the event will be stored, and means for exchanging these objects across the Internet between calendars on behalf of people for whom the calendars are meaningful. This document gives an abstract model of the objects and the protocols necessary to accomplish this kind of information exchange. It will establish the context in which other Calendaring and Scheduling RFCs can be interpreted. Included are brief introductions to the other components of Internet calendar protocols and definitions of nomenclature common to all documents defining these protocols. Reading this document will enable implementors and users of Internet Calendaring and Scheduling protocols to understand the goals and constraints chosen for related protocols. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-mod-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-mod-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-calsch-mod-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801132059.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-mod-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-mod-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801132059.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09790; 2 Aug 97 12:00 EDT Received: from ietf.ietf.org by ietf.org id aa09321; 2 Aug 97 11:58 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ngtrans@sunroof.eng.sun.com, dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-harrington-ngtrans-dhcp-option-00.txt Date: Sat, 02 Aug 1997 11:58:34 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021158.aa09321@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Option for IPv6 Transitions Author(s) : D. Harrington Filename : draft-harrington-ngtrans-dhcp-option-00.txt Pages : 4 Date : 1-Aug-97 This draft introduces a proposed DHCP option which could be helpful in establishing connectivity between isolated IPv6 hosts and routers in an IPv4 network. This work is introduced to the NGTrans Working Group initially, and will also be reviewed in the DHCP Working Group. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-harrington-ngtrans-dhcp-option-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-harrington-ngtrans-dhcp-option-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-harrington-ngtrans-dhcp-option-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801112528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-harrington-ngtrans-dhcp-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-harrington-ngtrans-dhcp-option-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801112529.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09794; 2 Aug 97 12:01 EDT Received: from ietf.ietf.org by ietf.org id aa09463; 2 Aug 97 11:58 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rem-conf@es.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-redundancy-01.txt,.ps Date: Sat, 02 Aug 1997 11:58:52 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021158.aa09463@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload for Redundant Audio Data Author(s) : M. Handley, C. Perkins, I. Kouvelas, O. Hodson, J. Bolot, A. Vega-Garcia, S. Fosse-Parisis, V. Hardman Filename : draft-ietf-avt-rtp-redundancy-01.txt,.ps Pages : 10 Date : 1997-08-01 This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-redundancy-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-redundancy-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-redundancy-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801135028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-redundancy-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-redundancy-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801135028.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09792; 2 Aug 97 12:01 EDT Received: from ietf.ietf.org by ietf.org id aa09426; 2 Aug 97 11:58 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hedstrom-dhc-ldap-00.txt Date: Sat, 02 Aug 1997 11:58:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021158.aa09426@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Options for Locating LDAP Servers Author(s) : L. Hedstrom, L. Howard Filename : draft-hedstrom-dhc-ldap-00.txt Pages : 4 Date : 01-Aug-97 This document defines a new DHCP option for delivering configuration information to LDAP (Lightweight Directory Access Protocol) clients. The information returned is represented as LDAP URLs, as specified in the LDAPv3 URL draft[1]. The DHCP client may use the URLs returned by the DHCP server to locate an LDAP server for the client's network. The URL may include the TCP port of the LDAP server, and the distinguished name which identifies the base object for searching. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hedstrom-dhc-ldap-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-hedstrom-dhc-ldap-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-hedstrom-dhc-ldap-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801133036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hedstrom-dhc-ldap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hedstrom-dhc-ldap-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801133036.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09807; 2 Aug 97 12:01 EDT Received: from ietf.ietf.org by ietf.org id aa09569; 2 Aug 97 11:59 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-murray-auth-ftp-ssl-02.txt Date: Sat, 02 Aug 1997 11:59:18 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021159.aa09569@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Securing FTP with TLS Author(s) : E. Murray, P. Ford-Hutchinson, T. Hudson, M. Carpenter Filename : draft-murray-auth-ftp-ssl-02.txt Pages : 26 Date : 1997-08-01 This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by the IETF TLS working group and the extensions to the FTP protocol defined by the IETF CAT working group. It describes the subset of the extensions that are required and the parameters to be used; discusses some of the policy issues that clients and servers will need to take; considers some of the implications of those policies and discusses some expected behaviours of implementations to allow interoperation. TLS is not the only mechanism for securing file transfer, however it does offer some of the following positive attributes:- - Flexible security levels. TLS can support privacy, integrity, authentication or some combination of all of these. This allows clients and servers to dynamically, during a session, decide on the level of security required for a particular data transfer, - Formalised public key management. By use of X.509 public certificates during the authentication phase, certificate management can be built into a central function. Whilst this may not be desirable for all uses of secured file transfer, it offers advantages in certain structured environments such as access to corporate data sources. - Co-existence and interoperation with authentication mechanisms that are already in place for the HTTPS protocol. This allows web browsers to incorporate secure file transfer using the same infrastructure that has been set up to allow secure web browsing. The TLS protocol is a development of the Netscape Communication Corporation's SSL protocol and this document can be used to allow the FTP protocol to be used with either SSL or TLS. The actual protocol used will be decided by the negotiation of the protected session by the TLS/S Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-murray-auth-ftp-ssl-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-murray-auth-ftp-ssl-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-murray-auth-ftp-ssl-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801144023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-murray-auth-ftp-ssl-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-murray-auth-ftp-ssl-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801144023.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09843; 2 Aug 97 12:01 EDT Received: from ietf.ietf.org by ietf.org id aa09645; 2 Aug 97 11:59 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: bmwg@baynetworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ippm-framework-01.txt Date: Sat, 02 Aug 1997 11:59:36 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021159.aa09645@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Framework for IP Provider Metrics Author(s) : G. Almes, J. Mahdavi, V. Paxson, M. Mathis Filename : draft-ietf-bmwg-ippm-framework-01.txt Pages : 31 Date : 1-Aug-97 The purpose of this memo is to define a general framework for partic- ular metrics to be developed by the IETF's IP Performance Metrics effort, begun by the Benchmarking Methodology Working Group (BMWG) of the Operational Requirements Area, and being continued by the IP Per- formance Metrics Working Group (IPPM) of the Transport Area. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ippm-framework-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-ippm-framework-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ippm-framework-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801145716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ippm-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ippm-framework-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801145716.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09931; 2 Aug 97 12:04 EDT Received: from ietf.org by ietf.org id aa08823; 2 Aug 97 11:45 EDT Received: from ietf.ietf.org by ietf.org id aa08289; 2 Aug 97 11:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-pkix@tandem.com X-Orig-Sender:ietf-announce-request@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki-kea-00.txt Date: Sat, 02 Aug 1997 11:39:30 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708021139.aa08289@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Representation of Key Exchange Algorithm (KEA) Keys in Internet Public Key Infrastructure Certificates Author(s) : R. Housley, W. Polk Filename : draft-ietf-pkix-ipki-kea-00.txt Pages : 5 Date : 01-Aug-97 This is the initial draft of a profile for specification of Key Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure X.509 certificates. Please send comments on this document to the ietf-pkix@tandem.com mail list. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ipki-kea-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-kea-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki-kea-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801165223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ipki-kea-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ipki-kea-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801165223.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa05185; 4 Aug 97 9:40 EDT Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA08834 for ; Mon, 4 Aug 1997 09:39:23 -0400 (EDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id GAA26049; Mon, 4 Aug 1997 06:35:20 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id GAA19269; Mon, 4 Aug 1997 06:30:38 -0700 (PDT) Received: (from daemon@localhost) by chicago.nsd.3com.com (8.8.2/8.8.5) id GAA25736 for ptopo-outgoing; Mon, 4 Aug 1997 06:30:18 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id GAA25732 for ; Mon, 4 Aug 1997 06:30:15 -0700 (PDT) Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id GAA19023 for ; Mon, 4 Aug 1997 06:27:29 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by janus.3com.com (8.8.2/8.8.5) with SMTP id GAA25805 for ; Mon, 4 Aug 1997 06:32:08 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa04968; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ptopo@3com.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [ptopo] I-D ACTION:draft-ietf-ptopomib-mib-00.txt Date: Mon, 04 Aug 1997 09:36:21 -0400 Message-ID: <9708040936.aa04968@ietf.org> Sender: owner-ptopo@3com.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Physical Topology MIB Working Group of the IETF. Title : Physical Topology MIB Author(s) : K. Jones, A. Bierman Filename : draft-ietf-ptopomib-mib-00.txt Pages : 30 Date : 02-Aug-97 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ptopomib-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ptopomib-mib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ptopomib-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802144608.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ptopomib-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ptopomib-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802144608.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06626; 4 Aug 97 10:45 EDT Received: from ietf.ietf.org by ietf.org id aa05805; 4 Aug 97 10:03 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-armitage-ion-security-00.txt Date: Mon, 04 Aug 1997 10:03:11 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708041003.aa05805@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security issues for ION protocols Author(s) : G. Armitage Filename : draft-armitage-ion-security-00.txt Pages : 14 Date : 01-Aug-97 This document aims to assist people attempting to understand the security limitations of existing ION working group protocols RFC 1577 (ATMARP), RFC 2022 (MARS), and RFC xxxx (NHRP). As RFC 2022 and RFC xxxx share their basic control message protocol(s), this document also identifies common areas amenable to improvement using additional security TLVs. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-armitage-ion-security-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-armitage-ion-security-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-armitage-ion-security-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970801163412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-armitage-ion-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-armitage-ion-security-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970801163412.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06637; 4 Aug 97 10:45 EDT Received: from ietf.ietf.org by ietf.org id aa04901; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-conta-ipv6-trans-tunnel-00.txt Date: Mon, 04 Aug 1997 09:36:17 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708040936.aa04901@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over IPv6 and IPv4 Tunnels. Author(s) : A. Conta Filename : draft-conta-ipv6-trans-tunnel-00.txt Pages : 5 Date : 02-Aug-97 This memo describes the transmission of IPv6 packets over IPv6 and IPv4 tunnels, and the IPv6 tunnel link local addresses. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-conta-ipv6-trans-tunnel-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-conta-ipv6-trans-tunnel-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-conta-ipv6-trans-tunnel-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802144028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-conta-ipv6-trans-tunnel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-conta-ipv6-trans-tunnel-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802144028.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06636; 4 Aug 97 10:45 EDT Received: from ietf.ietf.org by ietf.org id aa04852; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dns-security@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-as-map-05.txt Date: Mon, 04 Aug 1997 09:36:11 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708040936.aa04852@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Mapping Autonomous Systems Number into the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-as-map-05.txt Pages : 8 Date : 1997-08-02 One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Additions have developed to the Domain Name System to enable it to be used for authenticated public key distribution [RFC 2065]. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS security can be used to distribute their public keys. [Changes from previous version are to accommodate AS numbers larger than 16 bits and to delegate on decimal boundaries rather than binary boundaries.] Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-as-map-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-as-map-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802142643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-as-map-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-as-map-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802142643.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06646; 4 Aug 97 10:45 EDT Received: from ietf.ietf.org by ietf.org id aa05002; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: poised@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-poisson-nomcom-02.txt Date: Mon, 04 Aug 1997 09:36:28 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708040936.aa05002@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Process for Organization of Internet StandardS ONg Working Group of the IETF. Title : IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees Author(s) : J. Galvin Filename : draft-ietf-poisson-nomcom-02.txt Pages : 14 Date : 1997-08-02 The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-poisson-nomcom-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-poisson-nomcom-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-poisson-nomcom-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802141339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-poisson-nomcom-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-poisson-nomcom-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802141339.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06644; 4 Aug 97 10:45 EDT Received: from ietf.ietf.org by ietf.org id aa04910; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: entmib@cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bierman-entmib-compid-00.txt Date: Mon, 04 Aug 1997 09:36:19 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708040936.aa04910@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Entity MIB Working Group of the IETF. Title : Entity MIB Extesions for Persistent Component Identification Author(s) : K. McCloghrie, A. Bierman Filename : draft-bierman-entmib-compid-00.txt Pages : 9 Date : 02-Aug-97 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing physical topology identification and discovery. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bierman-entmib-compid-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-bierman-entmib-compid-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-bierman-entmib-compid-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802144330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bierman-entmib-compid-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bierman-entmib-compid-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802144330.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06645; 4 Aug 97 10:45 EDT Received: from ietf.ietf.org by ietf.org id aa04826; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-mime-vcard-03.txt Date: Mon, 04 Aug 1997 09:36:09 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708040936.aa04826@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : vCard MIME Directory Profile Author(s) : T. Howes, F. Dawson Filename : draft-ietf-asid-mime-vcard-03.txt Pages : 24 Date : 1997-08-02 This memo defines the profile of the MIME Content-Type [MIME-DIR] for directory information for a white-pages person object, based on a vCard electronic business card. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The directory information used by this profile is based on the attributes for the person object defined in the X.520 and X.521 directory services recommendations. The profile also provides the method for including a [VCARD] representation of a white-pages directory entry within the MIME Content-Type defined by the [MIME-DIR] document. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-mime-vcard-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-mime-vcard-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-mime-vcard-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802142301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-mime-vcard-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-mime-vcard-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802142301.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06630; 4 Aug 97 10:45 EDT Received: from ietf.ietf.org by ietf.org id aa04888; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-rat-01.txt Date: Mon, 04 Aug 1997 09:36:14 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708040936.aa04888@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (IPP) Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-01.txt Pages : 7 Date : 1997-08-01 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a high level overview of the architecture and provides the rational for the decisions made in structuring the architecture. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-rat-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-rat-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802143748.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802143748.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa07435; 4 Aug 97 10:56 EDT Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA09212 for ; Mon, 4 Aug 1997 10:54:28 -0400 (EDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id HAA04130; Mon, 4 Aug 1997 07:50:48 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id HAA27373; Mon, 4 Aug 1997 07:46:05 -0700 (PDT) Received: (from daemon@localhost) by chicago.nsd.3com.com (8.8.2/8.8.5) id HAA27010 for ptopo-outgoing; Mon, 4 Aug 1997 07:48:20 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id HAA27005 for ; Mon, 4 Aug 1997 07:48:17 -0700 (PDT) Received: from janus.3com.com (janus.3com.com [129.213.157.10]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id HAA27316 for ; Mon, 4 Aug 1997 07:45:31 -0700 (PDT) Received: from ietf.org (ietf.org [132.151.1.19]) by janus.3com.com (8.8.2/8.8.5) with SMTP id HAA04071 for ; Mon, 4 Aug 1997 07:50:10 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa04969; 4 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ptopo@3com.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [ptopo] I-D ACTION:draft-ietf-ptopomib-pdp-00.txt Date: Mon, 04 Aug 1997 09:36:23 -0400 Message-ID: <9708040936.aa04969@ietf.org> Sender: owner-ptopo@3com.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Physical Topology MIB Working Group of the IETF. Title : Physical Topology Discovery Protocol and MIB Author(s) : K. McCloghrie, A. Bierman Filename : draft-ietf-ptopomib-pdp-00.txt Pages : 21 Date : 02-Aug-97 This memo defines an experimental protocol, and an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a physical topology discovery protocol and managed objects used for managing the protocol. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ptopomib-pdp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ptopomib-pdp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ptopomib-pdp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970802144908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ptopomib-pdp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ptopomib-pdp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970802144908.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09048; 4 Aug 97 11:47 EDT Received: from zephyr.isi.edu by ietf.org id aa08893; 4 Aug 97 11:44 EDT Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 4 Aug 1997 08:40:10 -0700 Message-Id: <199708041540.AA29515@zephyr.isi.edu> To: IETF-Announce: ; Subject: RFC 2181 on Clarifications to the DNS Specification Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 04 Aug 97 08:40:10 PDT Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2181: Title: Clarifications to the DNS Specification Author: R. Elz, R. Bush Date: July 1997 Mailbox: kre@munnari.OZ.AU, randy@psg.com Pages: 15 Characters: 36989 Updates: 1034, 1035, 1123 URL: ftp://ds.internic.net/rfc/rfc2181.txt This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. This document is a product of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. This document is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <970804083218.RFC@ISI.EDU> SEND /rfc/rfc2181.txt --OtherAccess Content-Type: Message/External-body; name="rfc2181.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970804083218.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10116; 4 Aug 97 12:11 EDT Received: from zephyr.isi.edu by ietf.org id aa09157; 4 Aug 97 11:51 EDT Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Mon, 4 Aug 1997 08:46:32 -0700 Message-Id: <199708041546.AA00240@zephyr.isi.edu> To: IETF-Announce: ; Subject: BCP 16, RFC 2182 on Selection and Operation of Secondary DNS Servers Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 04 Aug 97 08:46:31 PDT Sender:ietf-announce-request@ietf.org From: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. BCP 16: RFC 2182: Title: Selection and Operation of Secondary DNS Servers Author: R. Elz, R. Bush, S. Bradner, M. Patton Date: July 1997 Mailbox: kre@munnari.OZ.AU, randy@psg.com, sob@harvard.edu, MAP@POBOX.COM Pages: 12 Characters: 27456 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2182.txt The Domain Name System requires that multiple servers exist for every delegated domain (zone). This document discusses the selection of secondary servers for DNS zones. This document is a product of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <970804084126.RFC@ISI.EDU> SEND /rfc/rfc2182.txt --OtherAccess Content-Type: Message/External-body; name="rfc2182.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970804084126.RFC@ISI.EDU> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa24186; 4 Aug 97 15:56 EDT Received: from ietf.ietf.org by ietf.org id aa23931; 4 Aug 97 15:51 EDT To: IETF-Announce: ; Subject: 39th IETF-MUNICH: SOCIAL EVENT Date: Mon, 04 Aug 1997 15:51:14 -0400 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9708041551.aa23931@ietf.org> Registration for the Social Event has begun. Please check out the web site at: http://www.multinet.de/ietf/ for full details and to register. You can purchase your Social Event tickets at the Sheraton Munich in the Congress Ballroom Foyer on Sunday, August 10 between 1700-1900 and Monday, August 11 between 0800-1200 Place: Lowenbraukeller Date: 12 August 1997 Time: 1900 Cost: DM 50 (Cash Only)   Received: from ietf.org by ietf.org id aa29967; 4 Aug 97 18:10 EDT Received: from ietf.ietf.org by ietf.org id aa29786; 4 Aug 97 18:07 EDT To: IETF-Announce: ; Subject: Re: Call for POC Nominations Sender:ietf-announce-request@ietf.org From: Abel Weinrib Reply-to: pocnom@iab.org Date: Mon, 04 Aug 1997 18:07:37 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708041807.aa29786@ietf.org> The IAB has been asked to appoint two people to the Policy Oversight Committee (POC) established under the recently signed DNS Memorandum of Understanding. The final list of willing nominees has now been determined: Antonio-Blasco Bonito Bill Manning Carl Malamud Christopher Wilkinson Eric Brunner J. Clarke Anderson John Lekashman Laura L. Smith Mark Andrews Olafur Gudmundsson Patrik Faltstrom Paul Vixie Pindar Wong Rick Wesson Rob Austein Stev Knowles The two IAB appointments will be chosen from this list shortly. Confidential comments from the community are still welcome--please send them to pocnom@iab.org. Abel Weinrib, IAB Executive Director   Received: from ietf.org by ietf.org id aa02415; 4 Aug 97 20:30 EDT Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by ietf.org id aa02253; 4 Aug 97 20:26 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA10444; Mon, 4 Aug 97 20:22:06 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id UAA23868; Mon, 4 Aug 1997 20:22:06 -0400 Date: Mon, 4 Aug 1997 20:22:06 -0400 Message-Id: <199708050022.UAA23868@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: IETF@ietf.org Subject: IETF PGP Key Signing Party Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. Once again, we will be holding a PGP Key signing party at the IETF meeting in Montreal. (Note: I will be set up to deal with PGP 5.0 keys; if you have a PGP 5.0 key, feel free to send it in!) We have been scheduled to meet at 10:30pm on the evening of Wednesday, August 13, 1996, in the Galery room. The procedure we will use is the following: o People who wish to participate should email an ASCII extract of their PGP public key to by 6:00pm on Wednesday of the week of the IETF meeting. Please include a subject line of "IETF PGP KEY". Sending your key to me before the IETF meeting is appreciated, since it reduces the number of keys that I have to collect during the meeting. (In fact, why don't you send me your key right now if you know will be attending, so you won't forget?) o By 10pm on Wednesday, you will be able to ftp a complete key ring from tsx-11.mit.edu with all of the keys that were submitted; it will be in the file /pub/tytso/ietf.asc and /pub/tytso/ietf.pgp. o At 10:30pm, come prepared with the PGP Key fingerprint of your PGP public key; we will have handouts with all of the key fingerprints of the keys that people have mailed in. o In turn, readers at the front of the room will recite people's keys; as your key fingerprint is read, stand up, and at the end of reading of your PGP key fingerprint, acknowledge that the fingerprint as read was correct. o Later that evening, or perhaps when you get home, you can sign the keys corresponding to the fingerprints which you were able to verify on the handout; note that it is advisable that you only sign keys of people when you have personal knowledge that the person who stood up during the reading of his/her fingerprint really is the person which he/she claimed to be. o Submit the keys you have signed to the PGP keyservers. A good one to use is the one at MIT: simply send mail containing the ascii armored version of your PGP public key to . Note that you don't have to have a laptop with you; if you don't have any locally trusted computing resources during the key signing party, you can make notes on the handout, and then take the handout home and sign the keys later. - Ted   Received: from ietf.org by ietf.org id aa03012; 4 Aug 97 21:04 EDT Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa02898; 4 Aug 97 21:03 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA20125; Mon, 4 Aug 97 20:58:39 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id UAA23896; Mon, 4 Aug 1997 20:58:39 -0400 Date: Mon, 4 Aug 1997 20:58:39 -0400 Message-Id: <199708050058.UAA23896@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: IETF@ietf.org Subject: IETF PGP Key Signing Party (corrected) Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. [The perceptive among you will have noticed that I screwed up the year and city in my last announcement. This message is those mistakes corrected. Sorry to clutter your mailboxes --- Ted] Once again, we will be holding a PGP Key signing party at the IETF meeting in Munich. (Note: I will be set up to deal with PGP 5.0 keys; if you have a PGP 5.0 key, feel free to send it in!) We have been scheduled to meet at 10:30pm on the evening of Wednesday, August 13, 1997, in the Galery room. The procedure we will use is the following: o People who wish to participate should email an ASCII extract of their PGP public key to by 6:00pm on Wednesday of the week of the IETF meeting. Please include a subject line of "IETF PGP KEY". Sending your key to me before the IETF meeting is appreciated, since it reduces the number of keys that I have to collect during the meeting. (In fact, why don't you send me your key right now if you know will be attending, so you won't forget?) o By 10pm on Wednesday, you will be able to ftp a complete key ring from tsx-11.mit.edu with all of the keys that were submitted; it will be in the file /pub/tytso/ietf.asc and /pub/tytso/ietf.pgp. o At 10:30pm, come prepared with the PGP Key fingerprint of your PGP public key; we will have handouts with all of the key fingerprints of the keys that people have mailed in. o In turn, readers at the front of the room will recite people's keys; as your key fingerprint is read, stand up, and at the end of reading of your PGP key fingerprint, acknowledge that the fingerprint as read was correct. o Later that evening, or perhaps when you get home, you can sign the keys corresponding to the fingerprints which you were able to verify on the handout; note that it is advisable that you only sign keys of people when you have personal knowledge that the person who stood up during the reading of his/her fingerprint really is the person which he/she claimed to be. o Submit the keys you have signed to the PGP keyservers. A good one to use is the one at MIT: simply send mail containing the ascii armored version of your PGP public key to . Note that you don't have to have a laptop with you; if you don't have any locally trusted computing resources during the key signing party, you can make notes on the handout, and then take the handout home and sign the keys later. - Ted   Received: from ietf.org by ietf.org id aa07428; 5 Aug 97 9:37 EDT Received: from ietf.ietf.org by ietf.org id aa07245; 5 Aug 97 9:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-domsrch-00.txt Date: Tue, 05 Aug 1997 09:36:06 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708050936.aa07245@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Domain Search Option for DHCP Author(s) : G. Stump, P. Gupta Filename : draft-ietf-dhc-domsrch-00.txt Pages : 4 Date : 04-Aug-97 The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. This document defines a new option which is passed form the DHCP server to the DHCP Client to configure the domain search list which is used by the clients to resolve hostnames in the Domain Name System. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-domsrch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-domsrch-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-domsrch-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970804154525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-domsrch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-domsrch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970804154525.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07217; 5 Aug 97 9:37 EDT Received: from ietf.ietf.org by ietf.org id aa06886; 5 Aug 97 9:34 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: 2000@nic.surfnet.nl Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-2000-issue-00.txt Date: Tue, 05 Aug 1997 09:34:28 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708050934.aa06886@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the The Internet and the Millennium Problem Working Group of the IETF. Title : The Internet and the Millenium Problem (Year 2000) Author(s) : P. Nesser II Filename : draft-ietf-2000-issue-00.txt Pages : 129 Date : 04-Aug-97 The Year 2000 Working Group(WG) has conducted an investigation into the millenium problem as it regards Internet related protocols. This investigation only targeted the protocols as documented in the Request For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost all Internet protocols were given a clean bill of health. Several cases of 'period' problems were discussed where a time field would 'roll over' as the size of field was reached. In particular, there are several protocols which have 32 bit signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-2000-issue-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-2000-issue-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-2000-issue-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970804113835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-2000-issue-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-2000-issue-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970804113835.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07393; 5 Aug 97 9:37 EDT Received: from ietf.ietf.org by ietf.org id aa07173; 5 Aug 97 9:35 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ospf@gated.cornell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ara-00.txt Date: Tue, 05 Aug 1997 09:35:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708050935.aa07173@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : The OSPF Address Resolution Advertisement Option Author(s) : R. Coltun, J. Heinanen Filename : draft-ietf-ospf-ara-00.txt Pages : 26 Date : 04-Aug-97 This document defines an OSPF option which enables routers to distri- bute IP to link-layer address resolution information. An OSPF Address Resolution Advertisement (ARA) may include link-layer specific func- tionality such as a multipoint-to-point connection identifier along with the address resolution information. The ARA option can be used to support router-to-router inter-subnet shortcut architectures such as those described in [HEIN] Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ara-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-ara-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ara-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970804151331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ara-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ara-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970804151331.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07215; 5 Aug 97 9:37 EDT Received: from ietf.ietf.org by ietf.org id aa06928; 5 Aug 97 9:34 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-clark-diff-svc-alloc-00.txt Date: Tue, 05 Aug 1997 09:34:44 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708050934.aa06928@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Approach to Service Allocation in the Internet Author(s) : D. Clark, J. Wroclawski Filename : draft-clark-diff-svc-alloc-00.txt Pages : 32 Date : 04-Aug-97 This note describes the Service Allocation Profile scheme for differential service allocation within the Internet. The scheme is based on a simple packet drop preference mechanism at interior nodes, and highly flexible service profiles at edges and inter- provider boundary points within the net. The service profiles capture a wide variety of user requirements and expectations, and allow different users to receive different levels of service from the network in a scalable and efficient manner. The note describes the basic form of the mechanism, discusses the range of services that users and providers can obtain by employing it, and gives a more detailed presentation of particular technical, deployment, standardization, and economic issues related to its use. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-clark-diff-svc-alloc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-clark-diff-svc-alloc-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-clark-diff-svc-alloc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970804144814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-clark-diff-svc-alloc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-clark-diff-svc-alloc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970804144814.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07308; 5 Aug 97 9:37 EDT Received: from ietf.ietf.org by ietf.org id aa07129; 5 Aug 97 9:35 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-conta-ipv6-nd_ext_ind-00.txt Date: Tue, 05 Aug 1997 09:35:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708050935.aa07129@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Neighbor Discovery Extensions for Inverse Discovery Specification Author(s) : A. Conta Filename : draft-conta-ipv6-nd_ext_ind-00.txt Pages : 9 Date : 1997-08-04 This memo describes a mechanism that can be seen as an extension to the IPv6 Neighbor Discovery. It allows a node to solicit and be advertized an IPv6 address corresponding to a given link-layer address. Because the known parameter is the link layer address, the mechanism is called Inverse Neighbor Discovery. It specifically applies to Frame Relay nodes that may have a Data Link Connection Identifier (DLCI), the Frame Relay equivalent of a link-layer address, associated with an established Permanent Virtual Circuit (PVC), but do not know the IPv6 address of the node at the other end of the circuit. It may also apply to other networks with similar behavior. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-conta-ipv6-nd_ext_ind-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-conta-ipv6-nd_ext_ind-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-conta-ipv6-nd_ext_ind-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970804150025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-conta-ipv6-nd_ext_ind-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-conta-ipv6-nd_ext_ind-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970804150025.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa07788; 5 Aug 97 9:44 EDT Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA12724 for ; Tue, 5 Aug 1997 09:42:29 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id GAA21940 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id GAA09156 Received: (majordom@localhost) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) id JAA06195; Tue, 5 Aug 1997 09:35:22 -0400 for bmwg-outgoing Received: from mailhost2.BayNetworks.COM (ext-ns1.baynetworks.com [134.177.3.20]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id JAA06180; Tue, 5 Aug 1997 09:35:20 -0400 for Received: from ietf.org (ietf.org [132.151.1.19]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with SMTP id GAA01892; Tue, 5 Aug 1997 06:34:25 -0700 (PDT) for Posted-Date: Tue, 5 Aug 1997 06:34:25 -0700 (PDT) Received: from ietf.ietf.org by ietf.org id aa07019; 5 Aug 97 9:35 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: bmwg@baynetworks.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ippm-delay-02.txt Date: Tue, 05 Aug 1997 09:35:04 -0400 Message-ID: <9708050935.aa07019@ietf.org> Sender: owner-bmwg@baynetworks.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : A One-way Delay Metric for IPPM Author(s) : G. Almes, S. Kalidindi Filename : draft-ietf-bmwg-ippm-delay-02.txt Pages : 12 Date : 1997-08-04 This memo defines a metric for one-way delay of packets across Inter- net paths. It builds on notions introduced and discussed in the IPPM Framework document (currently 'Framework for IP Provider Metrics' ); the reader is assumed to be familiar with that document. This memo is intended to be very parallel in structure to a companion document for Packet Loss ('A Packet Loss Metric for IPPM' ). + A 'singleton' analytic metric, called Type-P-One-way-Delay, will be introduced to measure a single observation of one-way delay. + Using this singleton metric, a 'sample', called Type-P-One-way- Delay-Stream, will be introduced to measure a sequence of single- ton delays measured at times taken from a Poisson process. + Using this sample, several 'statistics' of the sample will be defined and discussed. This progression from singleton to sample to statistics, with clear separation among them, is important. Whenever a technical term from the IPPM Framework document is first used in this memo, it will be tagged with a trailing asterisk, as with >>term*<<. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ippm-delay-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-ippm-delay-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ippm-delay-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970804145252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ippm-delay-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ippm-delay-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970804145252.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08151; 5 Aug 97 9:51 EDT Received: from ietf.ietf.org by ietf.org id aa08020; 5 Aug 97 9:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-widjaja-mpls-vc-merge-00.txt Date: Tue, 05 Aug 1997 09:50:28 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708050950.aa08020@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Performance Issues in VC-Merge Capable MPLS Switches Author(s) : A. Elwalid, I. Widjaja Filename : draft-widjaja-mpls-vc-merge-00.txt Pages : 11 Date : 1997-08-02 VC merging allows many routes to be mapped to the same VC label, thereby providing a scalable mapping method that can support tens of thousands of edge routers. VC merging requires reassembly buffers so that cells belonging to different packets intended for the same destination do not interleave with each other. This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. The main result indicates that VC merging incurs a minimal overhead compared to non-VC merging in terms of additional buffering. Moreover, the overhead decreases as utilization increases, or as the traffic becomes more bursty. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-widjaja-mpls-vc-merge-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-widjaja-mpls-vc-merge-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-widjaja-mpls-vc-merge-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805093944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-widjaja-mpls-vc-merge-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-widjaja-mpls-vc-merge-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805093944.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08322; 5 Aug 97 9:56 EDT Received: from ietf.ietf.org by ietf.org id aa08261; 5 Aug 97 9:55 EDT To: IETF-Announce: ; Subject: Getting Static IP adresses at Munich Terminal Room Sender:ietf-announce-request@ietf.org From: Dave.Morton@ecrc.de Date: Tue, 05 Aug 1997 09:55:20 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708050955.aa08261@ietf.org> There will be 100 10BaseT drops for laptops and few Localtalk drops for those with Macs. All of the laptops will be numbered out of the Class C network 195.27.194.0/23. For those who need to configure one single static IP address, send your request to: Dave.Morton@ecrc.de   Received: from ietf.org by ietf.org id aa08782; 5 Aug 97 10:04 EDT Received: from ietf.ietf.org by ietf.org id aa08654; 5 Aug 97 10:03 EDT To: IETF-Announce: ; Subject: Power Supplies and plugs Sender:ietf-announce-request@ietf.org From: Dave Morton Date: Tue, 05 Aug 1997 10:03:37 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708051003.aa08654@ietf.org> Just to remind everyone who's bringing electric/electronic equipment to the IETF meeting (and this includes laptops): All plugs are two prong with the earth (ground) a spring attachment at both the top and bottom of the socket, not all sockets require the earth from the plus to be connected though. In addition to two prong plugs, the power is all 220v. Folks will have to take adapters with them. PURCHASE THIS EQUIPMENT BEFORE LEAVING FOR GERMANY. It is very unlikely that a substantial supply of adapters/plugs will be available for US/non-German plug devices in Bavaria. Another item to note does not have to do with the plugs or voltage per se. In the past people have had problems fitting their adapters into the power strips. Many laptops use "brick" power supplies -- transformers at the end of the cord, with the plug built in. A typical plug adapter is unstable with that much weight on it. PURCHASE THE EQUIPMENT YOU NEED BEFORE LEAVING FOR GERMANY!   Received: from ietf.org by ietf.org id aa10235; 5 Aug 97 11:00 EDT Received: from ietf.ietf.org by ietf.org id aa10122; 5 Aug 97 10:59 EDT To: IETF-Announce: ; Subject: 39th IETF: MUNICH, GERMANY Date: Tue, 05 Aug 1997 10:59:20 -0400 Sender:ietf-announce-request@ietf.org From: Marcia Beaulieu Message-ID: <9708051059.aa10122@ietf.org> We will once again have pre-paid packet pickup on Sunday, August 10 from 12:00 noon until 3:00pm. The location of packet pickup is Congress Ballroom Foyer at the Sheraton. You can pick up your IETF meeting packet at this time if you have pre-registered and pre-paid. Social Event tickets will be on sale until 12:00 noon on Tuesday, August 12. A separate table will be located near the IETF registration desk (Sunday evening in the Congress Ballroom; Monday and Tuesday in the Congress Ballroom Foyer). Please send in your social registration form prior to the meeting. Social information can be obtained on the web at: http://www.multinet.de/ietf/ If you have questions about whether you are registered and paid for the IETF meeting, please check our web page, an updated list of registered attendees has been posted there: ftp://ftp.ietf.org/ietf/0mtg-registered-attendees-97aug.txt   Received: from ietf.org by ietf.org id aa16178; 5 Aug 97 14:23 EDT Received: from ietf.ietf.org by ietf.org id aa15816; 5 Aug 97 14:16 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-apple-schema-rqmts-list-00.txt Date: Tue, 05 Aug 1997 14:16:35 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051416.aa15816@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Directory Schema Listing Requirements Author(s) : C. Apple Filename : draft-apple-schema-rqmts-list-00.txt Pages : 5 Date : 07/28/1997 This memo documents requirements for listing directory services schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-apple-schema-rqmts-list-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-apple-schema-rqmts-list-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-apple-schema-rqmts-list-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970728141847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-apple-schema-rqmts-list-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-apple-schema-rqmts-list-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970728141847.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16179; 5 Aug 97 14:23 EDT Received: from ietf.ietf.org by ietf.org id aa16085; 5 Aug 97 14:22 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-newman-protocol-design-01.txt Date: Tue, 05 Aug 1997 14:22:06 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051422.aa16085@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application Protocol Design Principles Author(s) : C. Newman Filename : draft-newman-protocol-design-01.txt Pages : 10 Date : 07/29/1997 There are a number of design principles which come into play over and over again when designing application protocols. Many of these are entrenched in IETF lore and spread by word of mouth. Most have been learned the hard way many times. This is an attempt to codify some of these principles so they can be referenced rather than spread by word of mouth. The author has not invented any of these ideas and while the exercise of finding the originator of the ideas would be interesting, it is not deemed necessary for this project. Many of these principles have a much wider scope than application protocol design. However, the author's primary experience is with application protocols and examples provided usually involve application protocols or elements. [Disclaimer: this is a preliminary draft. Some of the case studies and exceptions need tuning. Suggestions welcome.] Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-newman-protocol-design-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-protocol-design-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-newman-protocol-design-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970729142113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-newman-protocol-design-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-newman-protocol-design-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970729142113.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17682; 5 Aug 97 15:08 EDT Received: from ietf.ietf.org by ietf.org id aa17505; 5 Aug 97 15:06 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-malkin-pnsmip-00.txt Date: Tue, 05 Aug 1997 15:06:58 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051506.aa17505@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Portable Node Support Using Mobile IP Protocol Author(s) : G. Malkin, P. Raison, N. Kossack Filename : draft-malkin-pnsmip-00.txt Pages : 12 Date : 1997-08-02 This document describes an extension to the Mobile IP protocol [1] which allows portable nodes to tunnel, through a Service Provider's network, to their home networks without the need to implement any special code on the portable nodes. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-malkin-pnsmip-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-malkin-pnsmip-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-malkin-pnsmip-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805145354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-malkin-pnsmip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-malkin-pnsmip-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805145354.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17681; 5 Aug 97 15:08 EDT Received: from ietf.ietf.org by ietf.org id aa17476; 5 Aug 97 15:06 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-inetorgperson-01.txt Date: Tue, 05 Aug 1997 15:06:56 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051506.aa17476@ietf.org> --NextPart Note: This is a resend with corrections made. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : Definition of the inetOrgPerson Object Class Author(s) : M. Smith Filename : draft-ietf-asid-inetorgperson-01.txt Pages : 17 Date : 1997-08-05 While the X.500 standards [X500] define many useful attribute types and object classes, they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson that extends the X.521 standard organizationalPerson class to meet these needs. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-inetorgperson-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-inetorgperson-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-inetorgperson-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805144905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-inetorgperson-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-inetorgperson-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805144905.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18081; 5 Aug 97 15:17 EDT Received: from gorilla.mchh.siemens.de by ietf.org id aa18016; 5 Aug 97 15:15 EDT Received: from moody.mchh.siemens.de (moody-i.mchh.siemens.de [194.138.158.26]) by gorilla.mchh.siemens.de (8.8.5/8.8.5) with SMTP id VAA04180 for ; Tue, 5 Aug 1997 21:11:13 +0200 (MET DST) Received: from descn121.oen.siemens.de (descn121 [218.20.3.82]) by moody.mchh.siemens.de (8.6.12/8.6.12) with ESMTP id VAA04415 for ; Tue, 5 Aug 1997 21:14:22 +0200 Received: from Microsoft Mail (PU Serial #1895) by descn121.oen.siemens.de (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm)) id AA-1997Aug05.210615.1895.255209; Tue, 05 Aug 1997 21:09:34 +0200 Sender:ietf-request@ietf.org From: "Scholl, Reinhard" To: ietf mailing list Message-ID: <1997Aug05.210615.1895.255209@descn121.oen.siemens.de> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Organization: Siemens AG Date: Tue, 05 Aug 1997 21:09:34 +0200 Subject: Power supplies and plugs contd Source-Info: From (or Sender) name not authenticated. A follow-up on Dave's note re power supplies and plugs for the people comin= g to the IETF meeting who want to connect a laptop in their hotel room: - The German telephone system doesn't use RJ11-modular jacks but sth calle= d = a TAE jack. So in addition to a power adapter you also need a modem adapter = for the German phone system. - Hotels do not always have all their rooms equipped with TAE jacks but ha= ve an older system where the wire comes directly out of the wall and connects = = to the phone. E.g., the Sheraton has only a limited number of rooms with TAE jacks. So if you think you need to connect your laptop in your room, ask fo= r a room with a TAE jack when you check in. - The Sheraton has a (limited) supply of modem and power adaptors. They al= so have a systems manager (Mr. Sonntag) who can provide assistance in case you= need help configuring your modem. But as Dave said: it is prudent to = PURCHASE THE EQUIPMENT YOU NEED BEFORE LEAVING FOR GERMANY=21 - In Germany, local calls are metered. There is no such thing as a flat = rate. Reinhard Scholl   Received: from ietf.org by ietf.org id aa18380; 5 Aug 97 15:21 EDT Received: from ietf.ietf.org by ietf.org id aa18146; 5 Aug 97 15:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-floyd-incr-init-win-00.txt Date: Tue, 05 Aug 1997 15:18:23 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051518.aa18146@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Increasing TCP's Initial Window Author(s) : C. Partridge, S. Floyd, M. Allman Filename : draft-floyd-incr-init-win-00.txt Pages : 8 Date : 1997-08-02 This is a note to suggest changing the permitted initial window in TCP from 1 segment to roughly 4K bytes. This draft considers the advantages and disadvantages of such a changes, as well as outlining some experimental results that indicate the costs and benefits of making such a change to TCP, and pointing out remaining research questions. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-floyd-incr-init-win-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-floyd-incr-init-win-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-floyd-incr-init-win-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805150806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-floyd-incr-init-win-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-floyd-incr-init-win-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805150806.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18381; 5 Aug 97 15:21 EDT Received: from ietf.ietf.org by ietf.org id aa18174; 5 Aug 97 15:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: namedroppers@internic.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsind-test-tlds-01.txt Date: Tue, 05 Aug 1997 15:18:27 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051518.aa18174@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS IXFR, Notification, and Dynamic Update Working Group of the IETF. Title : Test and Example Top Level Domain Names Author(s) : D. Eastlake Filename : draft-ietf-dnsind-test-tlds-01.txt Pages : 5 Date : 1997-08-02 To reduce the likelihood of conflict and confusion, four top level domain names are reserved for use in testing and as examples in documentation. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsind-test-tlds-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-test-tlds-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnsind-test-tlds-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805150659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsind-test-tlds-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsind-test-tlds-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805150659.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18785; 5 Aug 97 15:27 EDT Received: from ietf.ietf.org by ietf.org id aa18640; 5 Aug 97 15:25 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-multopt-01.txt Date: Tue, 05 Aug 1997 15:25:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051525.aa18640@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Multicast address allocation extensions options Author(s) : B. Patel, M. Shah Filename : draft-ietf-dhc-multopt-01.txt Pages : 5 Date : 1997-08-01 This document describes host configuration options that may be used by multicast address allocation protocols[3]. The options include critical information such as the IP address (unicast or multicast) of the multicast address allocation server(s) and a list of multicast scopes supported by respective servers. These options are designed to work with the extensions to DHCP [1] servers to support multicast address allocation (described in a separate draft), however, their use may not be limited to the above protocol. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-multopt-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-multopt-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-multopt-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805151330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-multopt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-multopt-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805151330.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa18783; 5 Aug 97 15:27 EDT Received: from ietf.ietf.org by ietf.org id aa18587; 5 Aug 97 15:25 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-pkix@tandem.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ipki-part1-05.txt Date: Tue, 05 Aug 1997 15:25:45 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051525.aa18587@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet Public Key Infrastructure Part I: X.509 Certificate and CRL Profile Author(s) : D. Solo, R. Housley, W. Ford, T. Polk Filename : draft-ietf-pkix-ipki-part1-05.txt Pages : 107 Date : 1997-08-01 This is the fifth draft of the Internet Public Key Infrastructure X.509 Certificate and CRL Profile. This draft is a complete specification. This text adds a new ISO-defined certificate extension, extended key usage, and clarifies the semantics of the validity fields. Other modifications and enhancements which appear in this draft include a reduced set of private extensions, conformance requirements for CAs and clients, and new examples of certificates and a CRL. This draft also defines object identifiers for use with the extended key usage certificate extension. Please send comments on this document to the ietf-pkix@tandem.com mail list. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ipki-part1-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki-part1-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ipki-part1-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805151106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ipki-part1-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ipki-part1-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805151106.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19618; 5 Aug 97 15:40 EDT Received: from mayan.empiretech.com by ietf.org id aa19504; 5 Aug 97 15:40 EDT Received: from celestial (cheryl@celestial [198.17.251.11]) by mayan.empiretech.com (8.7.5/8.6.12) with SMTP id PAA25288 for ; Tue, 5 Aug 1997 15:35:22 -0400 (EDT) Received: (from cheryl@localhost) by celestial (8.6.12/8.6.12) id PAA10172; Tue, 5 Aug 1997 15:35:21 -0400 Sender:ietf-request@ietf.org From: Cheryl Krupczak Message-Id: <199708051935.PAA10172@celestial> Subject: Renting cell phone in Munich? To: ietf@ietf.org Date: Tue, 5 Aug 1997 15:35:21 -0400 (EDT) Cc: "Cheryl.Krupczak" X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Since Europe uses GSM, my cell phone won't work in Europe. Does anyone know if you can rent GSM900 cell phones? Who would I contact to do so? Any idea of cost? Thank you!!! Cheryl +--------------------------------------------------------------------+ + Check us out! http://www.empiretech.com + +--------------------------------------------------------------------+ + Cheryl Krupczak Empire Technologies, Inc. + + cheryl@empiretech.com 541 Tenth Street NW + + PH : +1 (770)384-0184 Suite 169 + + FAX: +1 (770)384-0183 Atlanta, GA 30318 + +--------------------------------------------------------------------+   Received: from ietf.org by ietf.org id aa19641; 5 Aug 97 15:40 EDT Received: from ietf.ietf.org by ietf.org id aa19377; 5 Aug 97 15:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-mdhcp-01.txt Date: Tue, 05 Aug 1997 15:39:55 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051539.aa19377@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Multicast address allocation extensions to the Dynamic Host Configuration Protocol Author(s) : B. Patel, M. Shah Filename : draft-ietf-dhc-mdhcp-01.txt Pages : 16 Date : 1997-08-01 The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. The multicast extensions to DHCP add additional capability of dynamic allocation of the multicast addresses and additional configuration options. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-mdhcp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-mdhcp-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-mdhcp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805151922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-mdhcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-mdhcp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805151922.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19639; 5 Aug 97 15:40 EDT Received: from ietf.ietf.org by ietf.org id aa19339; 5 Aug 97 15:39 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-harada-http-xconnfrom-00.txt Date: Tue, 05 Aug 1997 15:39:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051539.aa19339@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : HTTP X-Connfrom header Author(s) : J. Mogul, P. Leach, L. Harada, H. Hendren Filename : draft-harada-http-xconnfrom-00.txt Pages : 5 Date : 1997-07-30 HTTP/1.1 defines a Connection header, allowing 'the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.' Because HTTP/1.0 proxies would normally forward the Connection header without obeying its specification, a Connection header received in an HTTP/1.0 message must normally be treated as if it had been forwarded in error. This document defines an X-Connfrom header that identifies the sending host, and so is safe to use in HTTP/1.0 messages. This might be useful in experimenting with HTTP/1.0 implementations of applications of the HTTP/1.1 Connection mechanism. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-harada-http-xconnfrom-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-harada-http-xconnfrom-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-harada-http-xconnfrom-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805152559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-harada-http-xconnfrom-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-harada-http-xconnfrom-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805152559.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19778; 5 Aug 97 15:43 EDT Received: from ietf.ietf.org by ietf.org id aa18613; 5 Aug 97 15:25 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: madman@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-madman-dsa-mib-1-04.txt Date: Tue, 05 Aug 1997 15:25:47 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051525.aa18613@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mail and Directory Management Working Group of the IETF. Title : Directory Server Monitoring MIB Author(s) : S. Kille, G. Mansfield Filename : draft-ietf-madman-dsa-mib-1-04.txt Pages : 25 Date : 1997-08-02 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [9] to allow monitoring of Directory Servers. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-madman-dsa-mib-1-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-madman-dsa-mib-1-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-madman-dsa-mib-1-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805151218.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-madman-dsa-mib-1-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-madman-dsa-mib-1-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805151218.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab19778; 5 Aug 97 15:43 EDT Received: from ietf.ietf.org by ietf.org id aa19511; 5 Aug 97 15:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-laubach-ip-over-802d14-00.txt Date: Tue, 05 Aug 1997 15:40:09 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051540.aa19511@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Logical IP Subnetworks over IEEE 802.14 Services Author(s) : M. Laubach Filename : draft-laubach-ip-over-802d14-00.txt Pages : 13 Date : 1997-08-01 This memo defines an initial application of classical IP and ARP in an IEEE 802.14 Community Access Television (CATV) Residential Access Network environment. IEEE 802.14 services provide two independent link layer service interfaces which are available to support IP residential access networking services: traditional Ethernet bridging (via IEEE 802.1D layer services) and residential ATM networking services. In this memo, the term Logical IP Subnetwork (LIS) is defined to apply to Classical IP over ATM LIS's operating over IEEE 802.14 services as well as traditional IP over Ethernet operating over IEEE 802.14 services. The recommendations in this draft rely on existing IETF standards for the family of Classical IP and ARP over ATM (IPOA) services and for IP and ARP over Broadcast Ethernet networks. The tree-based hierarchic nature of the IEEE 802.14 MAC subnetwork permits convenient extensions to Classical IPOA model for broadcast and multicast in the downstream direction of the CATV plant. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-laubach-ip-over-802d14-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-laubach-ip-over-802d14-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-laubach-ip-over-802d14-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805152418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-laubach-ip-over-802d14-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-laubach-ip-over-802d14-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805152418.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20438; 5 Aug 97 15:56 EDT Received: from ietf.ietf.org by ietf.org id aa20282; 5 Aug 97 15:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rps@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rps-rpsl-03.txt,.ps Date: Tue, 05 Aug 1997 15:55:32 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051555.aa20282@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Policy System Working Group of the IETF. Title : Routing Policy Specification Language (RPSL) Author(s) : D. Karrenberg, D. M. Terpstra, C. Villamizar, C. Alaettinoglu, T. Bates Filename : draft-ietf-rps-rpsl-03.txt,.ps Pages : 50 Date : 1997-08-02 This Internet Draft is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rps-rpsl-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rps-rpsl-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rps-rpsl-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805154033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rps-rpsl-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rps-rpsl-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805154033.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20437; 5 Aug 97 15:56 EDT Received: from ietf.ietf.org by ietf.org id aa20263; 5 Aug 97 15:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-duerst-query-i18n-00.txt Date: Tue, 05 Aug 1997 15:55:30 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051555.aa20263@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Handling Internationalized Query Components in URLs Author(s) : M. Duerst Filename : draft-duerst-query-i18n-00.txt Pages : 7 Date : 1997-07-30 HTTP and HTML provide the facility to query the user and return the results. This is usually done in the query component of an URL. This mechanisms works with full satisfaction for characters of the us- ascii repertoire. Due to the lack of an agreed encoding for other characters, the situation is much less satisfactory for characters outside the us-ascii repertoire. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-duerst-query-i18n-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-duerst-query-i18n-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-duerst-query-i18n-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805153920.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-duerst-query-i18n-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-duerst-query-i18n-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805153920.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20439; 5 Aug 97 15:56 EDT Received: from ietf.ietf.org by ietf.org id aa20237; 5 Aug 97 15:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-schulzrinne-http-status-00.txt,.ps Date: Tue, 05 Aug 1997 15:55:28 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051555.aa20237@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Assignment of Status Codes for HTTP and HTTP-Derived Protocols Author(s) : H. Schulzrinne Filename : draft-schulzrinne-http-status-00.txt,.ps Pages : 3 Date : 1997-08-01 A number of other protocols may make use of HTTP syntax and facilities; this memo defines a mechanism for IANA to allocate status codes. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-http-status-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-schulzrinne-http-status-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-schulzrinne-http-status-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805153224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schulzrinne-http-status-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schulzrinne-http-status-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805153224.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa20670; 5 Aug 97 16:03 EDT Received: from ietf.ietf.org by ietf.org id aa19473; 5 Aug 97 15:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: cat-ietf@mit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-cat-kerberos-pk-cross-02.txt Date: Tue, 05 Aug 1997 15:40:04 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051540.aa19473@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Working Group of the IETF. Title : Public Key Cryptography for Cross-Realm Authentication in Kerberos Author(s) : G. Tsudik, C. Neuman, B. Sommerfeld, B. Tung, M. Hur, T. Ryutov, A. Medvinsky Filename : draft-ietf-cat-kerberos-pk-cross-02.txt Pages : 4 Date : 1997-08-01 This document defines extensions to the Kerberos protocol specification (RFC 1510, 'The Kerberos Network Authentication Service (V5)', September 1993) to provide a method for using public key cryptography during cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-cat-kerberos-pk-cross-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerberos-pk-cross-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-cat-kerberos-pk-cross-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805152205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-cat-kerberos-pk-cross-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-cat-kerberos-pk-cross-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805152205.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21663; 5 Aug 97 16:21 EDT Received: from ietf.ietf.org by ietf.org id aa21302; 5 Aug 97 16:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-watson-dhc-serv-verify-00.txt Date: Tue, 05 Aug 1997 16:19:35 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051619.aa21302@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Server Verification by Client Via DNSSEC Author(s) : O. Gudmundsson Filename : draft-watson-dhc-serv-verify-00.txt Pages : 6 Date : 1997-07-30 The document defines a mechanism to allow a DHCP client to verify the authenticity of a DHCP server configuration offer using DNSSEC. Currently DHCP clients have no way to assess which of DHCP OFFERS are from valid DHCP servers, and which are not. Malicious DHCP servers can cause various network problems for unsuspecting clients. In order to support DHCP server authorization a new DNS Resource Record type (ALLOC) is added. Using the ALLOC record in combination with the servers KEY record the client can authoritatively assess if the server is authorized. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-watson-dhc-serv-verify-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-watson-dhc-serv-verify-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-watson-dhc-serv-verify-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805160234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-watson-dhc-serv-verify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-watson-dhc-serv-verify-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805160234.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21664; 5 Aug 97 16:21 EDT Received: from ietf.ietf.org by ietf.org id aa21330; 5 Aug 97 16:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: confctrl@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mmusic-rtsp-03.txt,.ps Date: Tue, 05 Aug 1997 16:19:38 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051619.aa21330@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne, A. Rao, R. Lanphier Filename : draft-ietf-mmusic-rtsp-03.txt,.ps Pages : 71 Date : 1997-08-02 The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and delivery mechanisms based upon RTP (RFC 1889). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rtsp-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mmusic-rtsp-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rtsp-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805160042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805160042.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21662; 5 Aug 97 16:21 EDT Received: from ietf.ietf.org by ietf.org id aa21419; 5 Aug 97 16:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-securing-dhc-00.txt Date: Tue, 05 Aug 1997 16:19:47 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051619.aa21419@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Securing DHCP Author(s) : B. Patel Filename : draft-ietf-dhc-securing-dhc-00.txt Pages : 5 Date : 1997-07-30 This proposal describes methods of securing DHCP based on IETF DHCP and IPSEC protocols. This protocol achieves security goals for DHCP client and servers without having to define a new security protocol. Instead, it first bootstraps the DHCP client in un-trusted mode using existing DHCP protocol and then proceeds to secure configuration of the client using existing DHCP and IP protocol features. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-securing-dhc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-securing-dhc-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-securing-dhc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805155306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-securing-dhc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-securing-dhc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805155306.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21658; 5 Aug 97 16:21 EDT Received: from ietf.ietf.org by ietf.org id aa21449; 5 Aug 97 16:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-duerst-i18n-norm-00.txt Date: Tue, 05 Aug 1997 16:19:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051619.aa21449@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Normalization of Internationalized Identifiers Author(s) : M. Duerst Filename : draft-duerst-i18n-norm-00.txt Pages : 12 Date : 1997-07-30 The Universal Character Set (UCS) makes it possible to extend the repertoire of characters used in non-local identifiers beyond US- ASCII. The UCS contains a large overall number of characters, many codepoints for backwards compatibility, and various mechanisms to cope with the features of the writing systems of the world. All this together can lead to ambiguities in representation. Such ambiguities are not a problem when representing running text. Therefore existing standards have only defined equivalences. For the use in identi- fiers, which are compared using their binary representation, this is not sufficient. This document defines a normalization algorithm and gives usage guidelines to avoid such ambiguities. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-duerst-i18n-norm-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-duerst-i18n-norm-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-duerst-i18n-norm-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805153813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-duerst-i18n-norm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-duerst-i18n-norm-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805153813.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa21667; 5 Aug 97 16:21 EDT Received: from ietf.ietf.org by ietf.org id aa21386; 5 Aug 97 16:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-model-04.txt Date: Tue, 05 Aug 1997 16:19:42 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051619.aa21386@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol/1.0: Model and Semantics Author(s) : P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry Filename : draft-ietf-ipp-model-04.txt Pages : 92 Date : 1997-08-02 This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technology. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and administrative features, IPP version 1.0 is focused only on end user functionality. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-model-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-model-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-model-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805155643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-model-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-model-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805155643.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27308; 5 Aug 97 16:38 EDT Received: from ietf.ietf.org by ietf.org id aa26667; 5 Aug 97 16:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: pmp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-printmib-job-monitor-04.txt Date: Tue, 05 Aug 1997 16:37:01 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051637.aa26667@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Title : Job Monitoring MIB - V0.83 Author(s) : T. Hasting, H. Lewis, S. Isaacson, R. Bergman Filename : draft-ietf-printmib-job-monitor-04.txt Pages : 98 Date : 1997-08-02 This Internet-Draft specifies a set of 18 SNMP MIB objects for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-monitor-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-monitor-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805162209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-printmib-job-monitor-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-printmib-job-monitor-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805162209.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab27308; 5 Aug 97 16:38 EDT Received: from ietf.ietf.org by ietf.org id aa26822; 5 Aug 97 16:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hopmann-mimedirxml-00.txt Date: Tue, 05 Aug 1997 16:37:14 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051637.aa26822@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Conversion of MIMEDIR content into XML Author(s) : A. Hopmann Filename : draft-hopmann-mimedirxml-00.txt Pages : Date : 1997-07-30 This document specifies how to translate information which is represented in the MIMEDIR format into a representation of the identical information using the XML syntax. Using this specification, applications which have been designed to understand MIMEDIR formatted data should be able to interoperate using XML representations of the same schemas. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hopmann-mimedirxml-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-hopmann-mimedirxml-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-hopmann-mimedirxml-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805161810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hopmann-mimedirxml-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hopmann-mimedirxml-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805161810.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27458; 5 Aug 97 16:38 EDT Received: from ietf.ietf.org by ietf.org id aa26903; 5 Aug 97 16:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-conta-ipv6-trans-fr-00.txt Date: Tue, 05 Aug 1997 16:37:23 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051637.aa26903@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Transmission of IPv6 Packets over Frame Relay Author(s) : A. Conta, M. Mueller Filename : draft-conta-ipv6-trans-fr-00.txt Pages : 10 Date : 1997-07-30 This memo describes the transmission of IPv6 packets over Frame Relay, the IPv6 Frame Relay interface token, the IPv6 Frame Relay link local addresses, the IPv6 Frame Relay link layer Information formatting for Neighbor Discovery. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-conta-ipv6-trans-fr-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-conta-ipv6-trans-fr-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-conta-ipv6-trans-fr-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805161439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-conta-ipv6-trans-fr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-conta-ipv6-trans-fr-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805161439.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27450; 5 Aug 97 16:38 EDT Received: from ietf.ietf.org by ietf.org id aa26870; 5 Aug 97 16:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: bmwg@baynetworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-mcast-02.txt Date: Tue, 05 Aug 1997 16:37:19 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051637.aa26870@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Terminology for IP Multicast Benchmarking Author(s) : K. Dubray Filename : draft-ietf-bmwg-mcast-02.txt Pages : 9 Date : 1997-08-02 The purpose of this draft is to add terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 1944, and other IETF Benchmarking Methodology Working Group (BMWG) effort and extends them to the multicast paradigm. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-mcast-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-mcast-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-mcast-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805161624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-mcast-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-mcast-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805161624.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27452; 5 Aug 97 16:38 EDT Received: from ietf.ietf.org by ietf.org id aa26585; 5 Aug 97 16:36 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: http-wg@cuckoo.hpl.hp.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-http-digest-aa-rev-00.txt Date: Tue, 05 Aug 1997 16:36:52 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051636.aa26585@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the HyperText Transfer Protocol Working Group of the IETF. Title : An Extension to HTTP : Digest Access Authentication Author(s) : J. Franks, A. Luotonen, P. Leach, J. Hostetler, P. Hallam-Baker Filename : draft-ietf-http-digest-aa-rev-00.txt Pages : 18 Date : 1997-07-30 The protocol referred to as 'HTTP/1.0' includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as 'Digest Access Authentication'. Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. This is the final draft of any document under this name. Digest and Basic Authentication from the HTTP/1.1 specification will be combined and issued as a document titled 'Authentication in HTTP'.Our intent is that RFC 2068 and RFC 2069 will go to draft standard as a pair of documents, but with all authentication schemes (Digest and Basic) documented together in a single place. This transition has not yet taken place. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-http-digest-aa-rev-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-http-digest-aa-rev-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-http-digest-aa-rev-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805161250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-http-digest-aa-rev-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-http-digest-aa-rev-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805161250.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27460; 5 Aug 97 16:38 EDT Received: from ietf.ietf.org by ietf.org id aa26769; 5 Aug 97 16:37 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-masinter-form-data-01.txt Date: Tue, 05 Aug 1997 16:37:10 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051637.aa26769@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Returning Values from Forms: multipart/form-data Author(s) : L. Masinter Filename : draft-masinter-form-data-01.txt Pages : Date : 1997-08-02 This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-masinter-form-data-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-masinter-form-data-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-masinter-form-data-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805161927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-masinter-form-data-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-masinter-form-data-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805161927.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa29960; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29396; 5 Aug 97 17:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipp-rat-01.txt Date: Tue, 05 Aug 1997 17:07:25 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051707.aa29396@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (IPP) Author(s) : S. Zilles Filename : draft-ietf-ipp-rat-01.txt Pages : 7 Date : 1997-08-01 This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol and an interface to Directory Services. This document provides a high level overview of the architecture and provides the rational for the decisions made in structuring the architecture. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipp-rat-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipp-rat-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipp-rat-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805165142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-rat-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipp-rat-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805165142.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa29945; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29422; 5 Aug 97 17:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-radius@livingston.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radius-tunnel-auth-02.txt Date: Tue, 05 Aug 1997 17:07:31 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051707.aa29422@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Attributes for Tunnel Protocol Support Author(s) : J. Shriver, D. Leifer, G. Zorn Filename : draft-ietf-radius-tunnel-auth-02.txt Pages : 10 Date : 1997-08-05 This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. RADIUS attributes for both authorization and accounting are specified. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-tunnel-auth-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-radius-tunnel-auth-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-radius-tunnel-auth-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805164954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-tunnel-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-tunnel-auth-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805164954.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00048; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29582; 5 Aug 97 17:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rps@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rps-transition-01.txt Date: Tue, 05 Aug 1997 17:07:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051707.aa29582@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Policy System Working Group of the IETF. Title : A strategy for the transition from RIPE-181 to RPSL Author(s) : D. Kessens Filename : draft-ietf-rps-transition-01.txt Pages : 4 Date : 1997-08-02 This document describes a transition strategy for the Internet routing registries from the RIPE181 [1] routing language to RPSL [2]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rps-transition-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rps-transition-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rps-transition-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805164243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rps-transition-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rps-transition-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805164243.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00050; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29530; 5 Aug 97 17:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rem-conf@es.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-fec-00.txt Date: Tue, 05 Aug 1997 17:07:43 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051707.aa29530@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : An A/V Profile Extension for Generic Forward Error Correction in RTP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fec-00.txt Pages : 12 Date : 1997-08-04 This document specifies an extension to RFC 1890 which allows for forward correction (FEC) of continuous media encapsulated in RTP. The profile is engineered for FEC algorithms based on the exclusive or (parity) operation, although it can be used with other techniques. The profile extension allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. It is backwards com- patible with existing RFC 1890 implementations, so that receivers which do not wish to implement FEC can just ignore the extensions. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-fec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-fec-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-fec-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805164600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805164600.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00046; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29548; 5 Aug 97 17:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ippcp@external.cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippcp-arch-00.txt Date: Tue, 05 Aug 1997 17:07:46 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051707.aa29548@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Protocol Architecture Author(s) : R. Monsour, A. Shacham Filename : draft-ietf-ippcp-arch-00.txt Pages : 14 Date : 1997-07-30 This memo describes an architecture for applying lossless compression to Internet Protocol datagrams. It defines several of the key architectural elements of a compression protocol and describes alternatives for each element. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippcp-arch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-arch-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ippcp-arch-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805164402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-arch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805164402.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00066; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29639; 5 Aug 97 17:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-vpn-00.txt Date: Tue, 05 Aug 1997 17:07:52 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051707.aa29639@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Implementation of Virtual Private Network (VPNs) with IP Security Author(s) : N. Doraswamy Filename : draft-ietf-ipsec-vpn-00.txt Pages : 5 Date : 1997-03-14 This document discusses methods for implementing Virtural Private Networks (VPN) with IP Security (IPSec). We discuss different scenarios in which VPN is implemented and the security implications for each of these scenarios. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-vpn-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-vpn-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805164119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-vpn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-vpn-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805164119.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00096; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29714; 5 Aug 97 17:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-policy-oops-01.txt,.ps Date: Tue, 05 Aug 1997 17:08:01 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051708.aa29714@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : Open Outsourcing Policy Service (OOPS) for RSVP Author(s) : R. Guerin, S. Herzog, R. Rajan, D. Pendarakis Filename : draft-ietf-rsvp-policy-oops-01.txt,.ps Pages : 38 Date : 1997-08-05 This document describes a protocol for exchanging policy information and decisions between an RSVP-capable router (client) and a policy server. The OOPS protocol supports a wide range of router configurations and RSVP implementations, and is compatible with the RSVP Extensions for Policy Control [Ext]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-policy-oops-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-policy-oops-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-policy-oops-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805163254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-policy-oops-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-policy-oops-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805163254.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00111; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29667; 5 Aug 97 17:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-thaler-tunnel-mib-00.txt Date: Tue, 05 Aug 1997 17:07:57 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051708.aa29667@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Tunnel MIB Author(s) : D. Thaler Filename : draft-thaler-tunnel-mib-00.txt Pages : 10 Date : 1997-08-04 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type in IP networks, including GRE [5,6], IP- in-IP [7], Minimal Encapsulation [8], L2TP [9], and PPTP [10] tunnels. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-thaler-tunnel-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-thaler-tunnel-mib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-thaler-tunnel-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805163436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-thaler-tunnel-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-thaler-tunnel-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805163436.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00137; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29785; 5 Aug 97 17:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-degermark-ipv6-hc-03.txt Date: Tue, 05 Aug 1997 17:08:12 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051708.aa29785@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Header Compression for IPv6 Author(s) : S. Pink, M. Degermark, B. Nordgren Filename : draft-degermark-ipv6-hc-03.txt Pages : 45 Date : 1997-08-04 This document describes how to compress IP headers per-hop over point-to-point links. The methods can be applied to IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 byte UDP or TCP checksum. This largely removes the negative impact of large headers and allows efficient use of bandwidth on low- and medium-speed links. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-degermark-ipv6-hc-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-degermark-ipv6-hc-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-degermark-ipv6-hc-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805163029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-degermark-ipv6-hc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-degermark-ipv6-hc-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805163029.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa00136; 5 Aug 97 17:09 EDT Received: from ietf.ietf.org by ietf.org id aa29766; 5 Aug 97 17:08 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-v6exts-07.txt Date: Tue, 05 Aug 1997 17:08:08 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051708.aa29766@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Extensions for the Dynamic Host Configuration Protocol for IPv6 Author(s) : C. Perkins Filename : draft-ietf-dhc-v6exts-07.txt Pages : 31 Date : 1997-08-04 The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in typed data items that are stored in the 'extensions' field of the DHCPv6 message. The data items themselves are also called 'extensions.' This document specifies the current set of DHCPv6 extensions. This document will be periodically updated as new extensions are defined. Each superseding document will include the entire current list of valid extensions. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-v6exts-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-v6exts-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-v6exts-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805163140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-v6exts-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-v6exts-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805163140.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01041; 5 Aug 97 17:28 EDT Received: from ietf.ietf.org by ietf.org id aa00786; 5 Aug 97 17:27 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-spec-v2-00.txt Date: Tue, 05 Aug 1997 17:27:28 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051727.aa00786@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Protocol, Version 6 (IPv6) Specification Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-ipv6-spec-v2-00.txt Pages : 41 Date : 1997-07-30 This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-spec-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805171406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-spec-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-spec-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805171406.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01079; 5 Aug 97 17:29 EDT Received: from ietf.ietf.org by ietf.org id aa00819; 5 Aug 97 17:27 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-shepard-tcp-4-packets-3-buff-00.txt Date: Tue, 05 Aug 1997 17:27:32 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051727.aa00819@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : When TCP Starts Up With Four Packets Into Only Three Buffers Author(s) : C. Partridge, T. Shepard Filename : draft-shepard-tcp-4-packets-3-buff-00.txt Pages : 5 Date : 1997-08-01 Sally Floyd has proposed that TCPs start their initial slow start by sending as many as four packets (instead of the usual one packet) as a means of getting TCP up-to-speed faster. (Slow starts instigated due to timeouts would still start with just one packet.) Starting with more than one packet might reduce the start-up latency over long-fat pipes by two round-trip times. This proposal is documented further in [1] and in [2] and we assume the reader is familiar with the details of this proposal. On the end2end-interest mailing list, concern was raised that in the (allegedly common) case where a slow modem is served by a router which only allocates three buffers per modem (one buffer being transmitted while two packets are waiting), that starting with four packets would not be good because the fourth packet is sure to be dropped. Vern Paxson replied with the comment (among other things) that the four-packet start is no worse than what happens after two round trip times in normal slow start, hence no new problem is introduced by starting with as many as four packets. If there is a problem with a four-packet start, then the problem already exists in a normal slow- start startup after two round trip times when the slow-start algorithm will release into the net four closely spaced packets. This memo is to document that in the case of a 9600 bps modem at the edges of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced with a four-packet start when compared with a normal slow start (which starts with one packet). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shepard-tcp-4-packets-3-buff-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-shepard-tcp-4-packets-3-buff-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-shepard-tcp-4-packets-3-buff-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805171709.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shepard-tcp-4-packets-3-buff-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shepard-tcp-4-packets-3-buff-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805171709.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01082; 5 Aug 97 17:29 EDT Received: from ietf.ietf.org by ietf.org id aa00805; 5 Aug 97 17:27 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: srvloc@corp.home.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-svrloc-template-conversion-00.txt Date: Tue, 05 Aug 1997 17:27:30 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708051727.aa00805@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Location Protocol Working Group of the IETF. Title : Conversion of LDAP Schemas to and from SLP Templates Author(s) : P. St. Pierre Filename : draft-ietf-svrloc-template-conversion-00.txt Pages : 11 Date : 1997-08-01 LDAP and SLP are both useful mechanisms for locating service related information on a network. While they do perform similar functions, the way in which the information they provide is formated is very different. This document describes a set of rules and mappings for translating between the ASN.1 based LDAP schema and an SLP Template as described in the ``Service Template and service: Scheme'' draft.[1] Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-svrloc-template-conversion-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-template-conversion-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-svrloc-template-conversion-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805171540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-svrloc-template-conversion-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-svrloc-template-conversion-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805171540.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa02139; 5 Aug 97 18:02 EDT Received: from gate2.sprintlink.net by ietf.org id aa02055; 5 Aug 97 18:01 EDT Received: from iscserv.res.sprintlink.net by gate2.sprintlink.net via smtpd (for ietf.org [132.151.1.19]) with SMTP; 5 Aug 1997 21:56:38 UT Received: from localhost (vgoel@localhost) by iscserv.res.sprintlink.net (8.8.5/8.6.12) with SMTP id RAA25433; Tue, 5 Aug 1997 17:55:37 -0400 (EDT) X-Authentication-Warning: iscserv.res.sprintlink.net: vgoel owned process doing -bs Date: Tue, 5 Aug 1997 17:55:37 -0400 (EDT) Sender:ietf-request@ietf.org From: Vab Goel X-Sender: vgoel@iscserv.res.sprintlink.net To: Cheryl Krupczak cc: ietf@ietf.org Subject: Re: Renting cell phone in Munich? In-Reply-To: <199708051935.PAA10172@celestial> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. try http://www.worldcell.com/ vab.. On Tue, 5 Aug 1997, Cheryl Krupczak wrote: > > Since Europe uses GSM, my cell phone won't work in Europe. > > Does anyone know if you can rent GSM900 cell phones? > > Who would I contact to do so? Any idea of cost? > > Thank you!!! > Cheryl > > > +--------------------------------------------------------------------+ > + Check us out! http://www.empiretech.com + > +--------------------------------------------------------------------+ > + Cheryl Krupczak Empire Technologies, Inc. + > + cheryl@empiretech.com 541 Tenth Street NW + > + PH : +1 (770)384-0184 Suite 169 + > + FAX: +1 (770)384-0183 Atlanta, GA 30318 + > +--------------------------------------------------------------------+ >   Received: from ietf.org by ietf.org id aa02836; 5 Aug 97 18:23 EDT Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa01502; 5 Aug 97 17:43 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA14824; Tue, 5 Aug 97 17:38:28 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id RAA24310; Tue, 5 Aug 1997 17:38:28 -0400 Date: Tue, 5 Aug 1997 17:38:28 -0400 Message-Id: <199708052138.RAA24310@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: "Scholl, Reinhard" Cc: ietf mailing list In-Reply-To: Scholl, Reinhard's message of Tue, 05 Aug 1997 21:09:34 +0200, <1997Aug05.210615.1895.255209@descn121.oen.siemens.de> Subject: Re: Power supplies and plugs contd Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. From: "Scholl, Reinhard" Date: Tue, 05 Aug 1997 21:09:34 +0200 - In Germany, local calls are metered. There is no such thing as a flat rate. More followup for (mostly North Americans) who use AT&T, MCI, or Sprint: For those people who have an AT&T credit card, a useful number to keep in mind is AT&T's direct access number: 0130 0010 This is a (German) toll-free number which will allow you to make phone calls at a substantial discount than if you have to pay the hotel and Duetch Telecom markup. (AT&T claims a savings of 60% from Frankfort, Germany to Boston, MA --- your mileage may vary.) For MCI, the access number is 0130-0012; and for Sprint, the access number is 0130-0013. - Ted   Received: from ietf.org by ietf.org id aa03316; 5 Aug 97 18:35 EDT Received: from rover.cygnus.com by ietf.org id aa03175; 5 Aug 97 18:32 EDT Received: (from marc@localhost) by rover.cygnus.com (8.8.5/8.6.12) id SAA00960; Tue, 5 Aug 1997 18:27:59 -0400 (EDT) To: "Theodore Y. Ts'o" Cc: "Scholl, Reinhard" , ietf mailing list Subject: Re: Power supplies and plugs contd References: <199708052138.RAA24310@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: Marc Horowitz Date: 05 Aug 1997 18:27:58 -0400 In-Reply-To: "Theodore Y. Ts'o"'s message of Tue, 5 Aug 1997 17:38:28 -0400 Message-ID: Lines: 22 X-Mailer: Gnus v5.3/Emacs 19.34 Source-Info: From (or Sender) name not authenticated. "Theodore Y. Ts'o" writes: >> For those people who have an AT&T credit card, a useful number to keep >> in mind is AT&T's direct access number: >> >> 0130 0010 >> >> This is a (German) toll-free number which will allow you to make phone >> calls at a substantial discount than if you have to pay the hotel and >> Duetch Telecom markup. (AT&T claims a savings of 60% from Frankfort, >> Germany to Boston, MA --- your mileage may vary.) 60% savings over what? I called AT&T to ask what the calling card rates are. $2.50 calling card surcharge + $1.86 first minute + $1.32 additional minute. Discount plans except True Reach International don't apply. Not Cheap. Has anybody used one of the callback services? How well does it work? Marc   Received: from achtung.sp.TRW.COM by ietf.org id aa03345; 5 Aug 97 18:35 EDT Received: by achtung.sp.trw.com (4.1/SMI-4.1) id AA07297; Tue, 5 Aug 97 13:48:41 PDT Received: from mailsrv1 (mailsrv1.TRW.COM) by achtung.sp.trw.com (4.1/SMI-4.1) id AA07292; Tue, 5 Aug 97 13:48:38 PDT Received: from afalk by mailsrv1 (SMI-8.6/SMI-SVR4) id NAA14241; Tue, 5 Aug 1997 13:55:19 -0700 Message-Id: <33E792C2.FFA824EA@trw.com> Date: Tue, 05 Aug 1997 13:53:22 -0700 From: Aaron Falk Reply-To: afalk@mailsrv1.trw.com Organization: TRW, Electronics Systems & Technology Division X-Mailer: Mozilla 4.0 [en] (WinNT; U) Mime-Version: 1.0 To: tcp-over-satellite , ietf-announce-post@CNRI.Reston.VA.US, iesg-secretary@ietf.org Subject: TCPSAT Agenda for Munich X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-over-satellite@achtung.sp.trw.com Precedence: bulk Agenda for TCPSAT Working Group Meeting @ Munich IETF Chair: Aaron Falk Doc Editor: Eric Travis Meeting Date: Monday, August 11 Meeting Time: 1530 - 1730 Meeting Room: Congress C -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= AGENDA: Agenda Item 1: Discussion on Applicable Environments (15 minutes) Agenda Item 2: Issues and Potential Mitigations Related to TCP (60 minutes) Agenda Item 3: Infrastructure and Application Issues and Mitigations (15 minutes) Agenda Item 4: Adminstrivia (5 minutes) Agenda Item 5: Floor Discussion (25 minutes) The working group discussion will focus on a review of the outline and content that will go into the TCP over Satellite Internet Draft. Agenda Items 1, 2, and 3 will brief the concepts to be included in the draft. Pre-release copies are available from ftp://foghorn.ie.org/pub/scps/TCPOS/.   Received: from ietf.org by ietf.org id aa06551; 5 Aug 97 20:32 EDT Received: from ihgw2.lucent.com by ietf.org id aa06419; 5 Aug 97 20:30 EDT Cc: "Scholl, Reinhard" , ietf mailing list Received: from mvjok.mv.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id TAA15834; Tue, 5 Aug 1997 19:18:42 -0500 Received: by mvjok.mv.lucent.com (5.x/EMS-L sol2) id AA06394; Tue, 5 Aug 1997 20:26:13 -0400 Original-Cc: "Scholl, Reinhard" , ietf mailing list Received: from ftfls.mv.lucent.com by mvjok.mv.lucent.com (5.x/EMS-L sol2) id AA06389; Tue, 5 Aug 1997 20:26:12 -0400 Received: from ftfls by ftfls.mv.lucent.com (SMI-8.6/EMS-L sol2) id UAA20083; Tue, 5 Aug 1997 20:21:07 -0400 X-Orig-Sender: ewgray@mvjok.mv.lucent.com Message-Id: <33E7C373.343D@lucent.com> Date: Tue, 05 Aug 1997 20:21:07 -0400 Sender:ietf-request@ietf.org From: Eric W Gray Organization: Lucent Technologies X-Mailer: Mozilla 3.01 (X11; U; SunOS 5.5 sun4u) Mime-Version: 1.0 To: "Theodore Y. Ts'o" Original-Cc: "Scholl, Reinhard" , ietf mailing list Subject: Re: Power supplies and plugs contd References: <199708052138.RAA24310@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Thanks Ted... -- Eric Gray Email: ewgray@lucent.com Voice: (508)960-6162 Fax: (508)960-6095 In Person:MV 21-2E33 1600 Osgood St., N. Andover, MA 01845   Received: from ietf.org by ietf.org id aa08867; 5 Aug 97 22:08 EDT Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by ietf.org id aa08747; 5 Aug 97 22:07 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA20463; Tue, 5 Aug 97 22:01:03 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id WAA27018; Tue, 5 Aug 1997 22:01:03 -0400 Date: Tue, 5 Aug 1997 22:01:03 -0400 Message-Id: <199708060201.WAA27018@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: Marc Horowitz Cc: "Theodore Y. Ts'o" , "Scholl, Reinhard" , ietf mailing list In-Reply-To: Marc Horowitz's message of 05 Aug 1997 18:27:58 -0400, Subject: Re: Power supplies and plugs contd Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. From: Marc Horowitz Date: 05 Aug 1997 18:27:58 -0400 60% savings over what? I called AT&T to ask what the calling card rates are. $2.50 calling card surcharge + $1.86 first minute + $1.32 additional minute. Discount plans except True Reach International don't apply. Not Cheap. Has anybody used one of the callback services? How well does it work? 60% savings over what it costs to dial a direct call from Germany to the U.S. using Deutch Telecom, plus an "average" hotel markup. See the various North American long distance providers' web pages for the exact details of what they're comparing. It's no secret that a U.S -> Germany call is far cheaper than the equivalent Germany -> U.S. call. The direct access numbers make it cheaper to call the U.S. from Germany, although not as cheaper as simply originating the call from the U.S. (So if you can arrange to have your family members call you at predetermined times, that's the cheapest way to go about things.) This rate assymetry is likely to change once the European PTT's are opened up to face real competition, but at that point we're really far off-topic.... By the way, the direct dial numbers I sent out are *not* callback services. That's a completely different kettle of fish. - Ted   Received: from ietf.org by ietf.org id aa25128; 6 Aug 97 5:05 EDT Received: from ecrc.de by ietf.org id aa24890; 6 Aug 97 4:58 EDT Received: (qmail 17691 invoked from network); 6 Aug 1997 08:53:31 -0000 Received: from scorpio.ecrc.de (141.1.4.100) by ecrc.de with SMTP; 6 Aug 1997 08:53:31 -0000 Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125]) by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP id KAA26297; Wed, 6 Aug 1997 10:53:30 +0200 (MET DST) Sender:ietf-request@ietf.org From: Dave Morton Received: (from dave@localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id KAA22434; Wed, 6 Aug 1997 10:53:28 +0200 (MET DST) Date: Wed, 6 Aug 1997 10:53:28 +0200 (MET DST) Message-Id: <199708060853.KAA22434@acrab25.ecrc.de> To: cheryl@empiretech.com, ietf@ietf.org Subject: Re: Renting cell phone in Munich? Source-Info: From (or Sender) name not authenticated. >Since Europe uses GSM, my cell phone won't work in Europe. Correct, >Does anyone know if you can rent GSM900 cell phones? Here a few pointers near the Sheraton that I found: TUT GmbH - +49 89 470 2080 - Einsteinstr. 50, 81675 Munich (a few minutes away per bus) MTG Telekom Center - +49 89 996 33-0 Fax: +49 89 9287 0820 Denningerstr. 116, 81925 Munich, a few hundred metres away from the Sheraton. or if you are renting a car at the airport then ask if they can also supply you with a handy at an inclusive rate (Sixt is a good bet). Hope this helps. >Who would I contact to do so? Any idea of cost? No idea about the cost, there are various tariffs. Dave >Thank you!!! > Cheryl > > >+--------------------------------------------------------------------+ >+ Check us out! http://www.empiretech.com + >+--------------------------------------------------------------------+ >+ Cheryl Krupczak Empire Technologies, Inc. + >+ cheryl@empiretech.com 541 Tenth Street NW + >+ PH : +1 (770)384-0184 Suite 169 + >+ FAX: +1 (770)384-0183 Atlanta, GA 30318 + >+--------------------------------------------------------------------+ >   Received: from ietf.org by ietf.org id aa27048; 6 Aug 97 6:37 EDT Received: from ecrc.de by ietf.org id aa26927; 6 Aug 97 6:35 EDT Received: (qmail 21072 invoked from network); 6 Aug 1997 10:30:17 -0000 Received: from scorpio.ecrc.de (141.1.4.100) by ecrc.de with SMTP; 6 Aug 1997 10:30:17 -0000 Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125]) by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP id MAA27654 for ; Wed, 6 Aug 1997 12:30:16 +0200 (MET DST) Sender:ietf-request@ietf.org From: Dave Morton Received: (from dave@localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id MAA22782 for ietf@ietf.org; Wed, 6 Aug 1997 12:30:14 +0200 (MET DST) Date: Wed, 6 Aug 1997 12:30:14 +0200 (MET DST) Message-Id: <199708061030.MAA22782@acrab25.ecrc.de> To: ietf@ietf.org Subject: Re: Renting cell phone in Munich? Source-Info: From (or Sender) name not authenticated. >Here a few pointers near the Sheraton that I found: > >TUT GmbH - +49 89 470 2080 - Einsteinstr. 50, >81675 Munich (a few minutes away per bus) Damn, Randy just tells me they are out of phones so don't bother calling. >MTG Telekom Center - +49 89 996 33-0 Fax: +49 89 9287 0820 >Denningerstr. 116, 81925 Munich, a few hundred metres away from >the Sheraton. This number has changed, instead use +49 89 451-120 Also try S.E. GmbH, +49 89 59 77 88. MobilTel, Poccistr. +49 89 746 1690 Hope it helps. Dave   Received: from ietf.org by ietf.org id aa02641; 6 Aug 97 9:39 EDT Received: from mail1.eni.net by ietf.org id aa01982; 6 Aug 97 9:23 EDT Received: from ddunbar.eni.net (ddunbar.atl.eni.net [155.229.2.123]) by mail1.eni.net (8.7.5/8.7.3) with ESMTP id GAA09777 for ; Wed, 6 Aug 1997 06:19:31 -0700 (PDT) Message-ID: <33E879C2.9211EA47@eni.net> Date: Wed, 06 Aug 1997 09:18:58 -0400 Sender:ietf-request@ietf.org From: "Daryl W. Dunbar" Organization: Epoch Internet X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Renting cell phone in Munich? X-Priority: 3 (Normal) References: <199708061030.MAA22782@acrab25.ecrc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. WorldCell, here in the US rents GSM Phones for $75 for the first week and $50 for the second week. The FedEx the phone to you (good luck with the UPS strike). +1 888 WORLD CELL +1 888 967 5323 or www.worldcell.com Regards, DwD -- Daryl W. Dunbar Voice: (404)898-2500 x123 Director of Sales Engineering Fax: (404)898-2505 EPOCH Internet http://www.eni.net mailto:daryl@eni.net   Received: from ietf.org by ietf.org id aa10094; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09282; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ids-inp-02.txt Date: Wed, 06 Aug 1997 10:50:15 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09282@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Directory Services Working Group of the IETF. Title : Internet Nomenclator Project Author(s) : J. Ordille Filename : draft-ietf-ids-inp-02.txt Pages : 14 Date : 1997-08-06 The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world. Each CCSO server has a database schema that is tailored to the needs of the organization that owns it. The project is integrating the different database schema into one query service. The Internet Nomenclator Project will provide fast cross-server searches for locating people on the Internet. It augments existing CCSO services by supplying schema integration, more extensive indexing, and two kinds of caching -- all this in a system that scales as the number of CCSO servers grows. One of the best things about the system is that administrators can incorporate their CCSO servers into Nomenclator without changing the servers. All Nomenclator needs is basic information about the server. This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet Nomenclator Project, and how to use the Nomenclator search engine to find people on the Internet. Distribution of this document is unlimited. Comments should be sent to the author. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ids-inp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ids-inp-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ids-inp-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806103023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ids-inp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ids-inp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806103023.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10095; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09048; 6 Aug 97 10:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-laviano-srtp-02.txt Date: Wed, 06 Aug 1997 10:49:51 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061049.aa09048@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Selectively Reliable Transport Protocol Author(s) : M. Pullen, V. Laviano Filename : draft-laviano-srtp-02.txt Pages : Date : 1997-08-04 This memo describes a protocol for selectively reliable transmission of Distributed Interactive Simulation (DIS) data in a wide-area multicast environment. The Selectively Reliable Transmission Protocol (SRTP) operates in three distinct modes: best-effort multicast, reliable multicast using negative acknowledgements with a NAK suppression mechanism to avoid congestion at the sender, and lightweight reliable transaction-oriented unicast. SRTP is designed to run in user space and form a sublayer between applications and the kernel-level Internet protocol stack. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-laviano-srtp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-laviano-srtp-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-laviano-srtp-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806100620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-laviano-srtp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-laviano-srtp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806100620.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10100; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09447; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ippcp@external.cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippcp-arch-00.txt Date: Wed, 06 Aug 1997 10:50:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09447@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Payload Compression Protocol Working Group of the IETF. Title : IP Payload Compression Protocol Architecture Author(s) : R. Monsour, A. Shacham Filename : draft-ietf-ippcp-arch-00.txt Pages : 14 Date : 1997-07-30 This memo describes an architecture for applying lossless compression to Internet Protocol datagrams. It defines several of the key architectural elements of a compression protocol and describes alternatives for each element. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippcp-arch-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ippcp-arch-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ippcp-arch-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806102104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippcp-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippcp-arch-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806102104.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10097; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa08995; 6 Aug 97 10:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-security-arch-01.txt Date: Wed, 06 Aug 1997 10:49:41 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061049.aa08995@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Security Architecture for DHCP Author(s) : O. Gudmundsson Filename : draft-ietf-dhc-security-arch-01.txt Pages : 14 Date : 1997-08-04 This document addresses the general security requirements of both v4 and v6 versions of DHCP. This document lists security requirements and proposes as security model, which meets scaling requirements, security requirements and efficiency requirements. The proposed security model uses public key cryptography and a proposed trusted key distribution mechanism to authenticate clients and servers. The authentication protocol can also exchange keying material for more efficiently protecting successive communication between client and server. The security model also addresses securing relay agents. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-security-arch-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-security-arch-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-security-arch-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806101028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-security-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-security-arch-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806101028.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10092; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09211; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kaukonen-cipher-arcfour-01.txt Date: Wed, 06 Aug 1997 10:50:08 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09211@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Stream Cipher Encryption Algorithm 'Arcfour' Author(s) : R. Thayer, K. Kaukonen Filename : draft-kaukonen-cipher-arcfour-01.txt Pages : 11 Date : 1997-07-30 This document describes an algorithm here called Arcfour that is believed to be fully interoperable with the RC4 algoritm. RC4 is trademark of RSA Data Security, Inc. There is a need in the Internet community for an encryption algorithm that provides interoperable operation with existing deployed commercial cryptographic applications. This interoperability will allow for a smoother transition to protocols that have been developed through the IETF standards process. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kaukonen-cipher-arcfour-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kaukonen-cipher-arcfour-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kaukonen-cipher-arcfour-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806093443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kaukonen-cipher-arcfour-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kaukonen-cipher-arcfour-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806093443.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10079; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09577; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: applmib@emi-summit.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-applmib-mib-04.txt Date: Wed, 06 Aug 1997 10:50:52 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09577@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application MIB Working Group of the IETF. Title : Application Management MIB Author(s) : J. Saperia, C. Krupczak, R. Presuhn, C. Kalbfleisch Filename : draft-ietf-applmib-mib-04.txt Pages : 61 Date : 1997-08-04 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the System Application MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-applmib-mib-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-mib-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-applmib-mib-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806101503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-applmib-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-applmib-mib-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806101503.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10096; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09182; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mealling-rwhoisurl-01.txt Date: Wed, 06 Aug 1997 10:50:04 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09182@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The RWhois Version 1.x Uniform Resource Locator Author(s) : S. Williamson, M. Mealling Filename : draft-mealling-rwhoisurl-01.txt Pages : 3 Date : 1997-08-02 RWhois is an Internet directory access protocol, defined in RFC1714 [1] and RFC2167 [3]. This document describes a format for an RWhois Uniform Resource Locator (URL) that will allow Internet clients to have direct access to the RWhois protocol. An RWhois URL will represent a single query to an RWhois server. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mealling-rwhoisurl-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mealling-rwhoisurl-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mealling-rwhoisurl-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806093100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mealling-rwhoisurl-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-mealling-rwhoisurl-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806093100.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10101; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09022; 6 Aug 97 10:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-conta-ipv6-inv-nd-tun-00.txt Date: Wed, 06 Aug 1997 10:49:46 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061049.aa09022@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Inverse Neighbor Discovery for IPv6 and IPv4 Tunnels Author(s) : A. Conta Filename : draft-conta-ipv6-inv-nd-tun-00.txt Pages : 9 Date : 1997-07-30 This memo describes an extension mechanism to the IPv6 Neighbor Discovery and IPv6 Inverse Neighbor Discovery [IND] that applies to IPv6 and IPv4 tunnels. The mechanism can be used to advertise the parameters of a tunnel to its exit point node, and to create a reverse tunnel path between the exit point and entry point nodes of a unidirectional tunnel. If such a bidirectional tunnel already exists, the mechanism can be used to learn the IPv6 address of the tunnel pseudointerface of the exit-point node, as well as the reverse tunnel path parameters. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-conta-ipv6-inv-nd-tun-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-conta-ipv6-inv-nd-tun-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-conta-ipv6-inv-nd-tun-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806100822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-conta-ipv6-inv-nd-tun-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-conta-ipv6-inv-nd-tun-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806100822.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10093; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09528; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: bmwg@baynetworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ippm-treno-btc-01.txt Date: Wed, 06 Aug 1997 10:50:45 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09528@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Empirical Bulk Transfer Capacity Author(s) : M. Mathis Filename : draft-ietf-bmwg-ippm-treno-btc-01.txt Pages : 5 Date : 1997-08-04 Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g. state-of-the-art TCP). For many applications the BTC of the underlying network dominates the the overall elapsed time for the application, and thus dominates the performance as perceived by a user. The BTC is a property of an IP cloud (links, routers, switches, etc) between a pair of hosts. It does not include the hosts themselves (or their transport-layer software). However, congestion control is crucial to the BTC metric because the Internet depends on the end systems to fairly divide the available bandwidth on the basis of common congestion behavior. The BTC metric is based on the performance of a reference congestion control algorithm that has particularly uniform and stable behavior. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ippm-treno-btc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-bmwg-ippm-treno-btc-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ippm-treno-btc-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806101643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ippm-treno-btc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ippm-treno-btc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806101643.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10098; 6 Aug 97 10:58 EDT Received: from ietf.ietf.org by ietf.org id aa09385; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipsec@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-revised-enc-mode-01.txt Date: Wed, 06 Aug 1997 10:50:31 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09385@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : A revised encryption mode for ISAKMP/Oakley Author(s) : H. Krawczyk, P. Cheng, R. Canetti Filename : draft-ietf-ipsec-revised-enc-mode-01.txt Pages : 6 Date : 1997-08-05 The ISAKMP/Oakley document [HC97] describes a proposed standard for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated and secret keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. The public-key encryption method of carrying out Phase 1 of the key exchange in the ISAKMP/Oakley document provides significant security advantages over the other alternatives and should be the method of choice in many implementations. Unfortunately, as currently described in [HC97] the method requires two public key encryption and decryption operations from both the Initiator and the Responder. The present document describes a small modification to this method. The resulting scheme requires only one public key encryption and decryption operation from each party, while maintaining (and even improving on) the strong security properties of the ISAKMP/Oakley public-key encryption mode. Remark: This document is NOT self-contained, it is intended as an addendum to the authentication methods defined in [HC97]. In particular, it uses notation and definitions of [HC97]. Thus, it is best read in conjunction with [HC97]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-revised-enc-mode-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806102459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-revised-enc-mode-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-revised-enc-mode-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806102459.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa10369; 6 Aug 97 10:59 EDT Received: from ietf.ietf.org by ietf.org id aa10137; 6 Aug 97 10:58 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: drums@cs.utk.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-drums-smtpupd-06.txt Date: Wed, 06 Aug 1997 10:58:05 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061058.aa10137@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detailed Revision/Update of Message Standards Working Group of the IETF. Title : Simple Mail Transfer Protocol Author(s) : J. Klensin Filename : draft-ietf-drums-smtpupd-06.txt Pages : 61 Date : 1997-08-05 This document is a self-contained specification of the basic protocol for the Internet electronic mail transport, consolidating and updating * the original SMTP specification of RFC 821 [RFC-821], * Domain name system requirements and implications for mail transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974], * the clarifications and applicability statements in RFC 1123 [RFC-1123], and * material drawn from the SMTP Extension mechanisms [SMTPEXT]. It replaces RFC 821, RFC 974, and the mail transport materials of RFC 1123. However, RFC 821 specifies some features that are not in significant use in the Internet of the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821. It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on the header-people list [HEADER-PEOPLE] and problems of unusual readings or interpretations that have turned up as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail posting' protocol, as recommended for POP [RFC-POP2, RFC-POP3] and IMAP [RFC-IMAP4]. Section ##2.3 provides definitions of terms specific to this document. Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively. A companion document discusses message bodies and formats RFC 822, MIME, and their relationship - [MSGFMT]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-drums-smtpupd-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-drums-smtpupd-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-drums-smtpupd-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970805113524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-drums-smtpupd-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-drums-smtpupd-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970805113524.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11143; 6 Aug 97 11:18 EDT Received: from ietf.ietf.org by ietf.org id aa09119; 6 Aug 97 10:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-rwhois-00.txt Date: Wed, 06 Aug 1997 10:50:01 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061050.aa09119@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : Referral Whois Protocol (RWhois) 2.0 Author(s) : S. Williamson, M. Mealling, M. Kosters, J. Singh, G. Pierce, D. Blacka, K. Zeilstra, M. Lu, L. Meador Filename : draft-ietf-asid-rwhois-00.txt Pages : Date : 1997-07-30 This memo describes Version 2.0 of the client/server interaction of RWhois. RWhois provides a distributed system for the display of hierarchical and non-hierarchical information. This system is primarily hierarchical by design, allowing for the deterministic reduction of a query and the referral of the user closer to the maintainer of the information. It also identifies the attributes that are non-hierarchical so that they may be indexed into a mesh. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-rwhois-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-rwhois-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-rwhois-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806094602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-rwhois-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-rwhois-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806094602.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11567; 6 Aug 97 11:29 EDT Received: from [208.142.74.81] by ietf.org id aa11424; 6 Aug 97 11:28 EDT Received: by mail.mindsharecorp.com with Internet Mail Service (5.0.1457.3) id ; Wed, 6 Aug 1997 10:26:00 -0500 Message-ID: <21B806A6F4A4D01183470060970521A255F4@mail.mindsharecorp.com> Sender:ietf-request@ietf.org From: Dan Erler To: ietf@ietf.org Subject: REMOVE Date: Wed, 6 Aug 1997 10:25:59 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa15693; 6 Aug 97 13:26 EDT Received: from ietf.ietf.org by ietf.org id aa15543; 6 Aug 97 13:24 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rem-conf@es.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-payload-04.txt Date: Wed, 06 Aug 1997 13:24:11 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061324.aa15543@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.263 Video Streams Author(s) : C. Zhu Filename : draft-ietf-avt-rtp-payload-04.txt Pages : 11 Date : 1997-08-05 This document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-payload-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-payload-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-payload-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806113927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-payload-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-payload-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806113927.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16632; 6 Aug 97 13:52 EDT Received: from ietf.ietf.org by ietf.org id aa16430; 6 Aug 97 13:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-calendar@imc.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-calsch-ical-02.txt Date: Wed, 06 Aug 1997 13:50:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061350.aa16430@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring and Scheduling Working Group of the IETF. Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Author(s) : F. Dawson, D. Stenerson Filename : draft-ietf-calsch-ical-02.txt Pages : 73 Date : 1997-08-02 There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This document has been defined to provide the a definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per [RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is 'TEXT/CALENDAR'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event and to-do information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems or using HTTP. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. This document is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information. In order to avoid confusion with this referenced work, this document is to be known as the iCalendar specification. This document is based on the calendaring and scheduling model defined in [ICMS]. The document is also the basis for the calendaring and scheduling interoperability protocol defined in [ITIP-1], [ITIP-2] and [ITIP-3]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-calsch-ical-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-calsch-ical-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-calsch-ical-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806133816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-calsch-ical-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-calsch-ical-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806133816.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16623; 6 Aug 97 13:52 EDT Received: from ietf.ietf.org by ietf.org id aa16466; 6 Aug 97 13:51 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: mpls@external.cisco.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-framework-01.txt Date: Wed, 06 Aug 1997 13:51:01 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708061351.aa16466@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Framework for Multiprotocol Label Switching Author(s) : R. Callon, G. Swallow, N. Feldman, A. Viswanathan, P. Doolan, A. Fredette Filename : draft-ietf-mpls-framework-01.txt Pages : 52 Date : 1997-08-02 This document discusses technical issues and requirements for the Multiprotocol Label Switching working group. This is an initial draft document, which will evolve and expand over time. It is the intent of this document to produce a coherent description of all significant approaches which were and are being considered by the working group. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. Note that this document is at an early stage, and that most of the detailed technical discussion is only in a rough form. Additional text will be provided over time from a number of sources. A small amount of the text in this document may be redundant with the proposed protocol architecture for MPLS. This redundancy will be reduced over time, with the overall discussion of issues moved to be in this document, and the selection of specific approaches and specification of the protocol contained in the protocol architecture and other related documents. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-framework-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mpls-framework-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mpls-framework-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970806133125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-framework-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970806133125.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa17021; 6 Aug 97 14:00 EDT Received: from relay4.UU.NET by ietf.org id aa16930; 6 Aug 97 13:59 EDT Received: from gen1.uu.net by relay4.UU.NET with ESMTP (peer crosschecked as: gen1.uu.net [153.39.49.138]) id QQdbln27115; Wed, 6 Aug 1997 13:55:09 -0400 (EDT) Received: from tenebrous.uu.net by gen1.uu.net with ESMTP (peer crosschecked as: tenebrous.UU.NET [153.39.253.123]) id QQdbln21162; Wed, 6 Aug 1997 13:55:00 -0400 (EDT) Received: by tenebrous.uu.net id QQdbln06884; Wed, 6 Aug 1997 13:55:00 -0400 (EDT) Date: Wed, 6 Aug 1997 13:55:00 -0400 (EDT) Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender:ietf-request@ietf.org From: Joseph Malcolm To: "Daryl W. Dunbar" Cc: ietf@ietf.org Subject: Re: Renting cell phone in Munich? In-Reply-To: <33E879C2.9211EA47@eni.net> References: <199708061030.MAA22782@acrab25.ecrc.de> <33E879C2.9211EA47@eni.net> X-Mailer: VM 6.33 under Emacs 19.34.1 Source-Info: From (or Sender) name not authenticated. Does theseDaryl W. Dunbar writes: >WorldCell, here in the US rents GSM Phones for $75 for the first week >and $50 for the second week. The FedEx the phone to you (good luck with >the UPS strike). Do these guys also just rent the phone? I already have a SIM.   Received: from ietf.org by ietf.org id aa23007; 6 Aug 97 16:41 EDT Received: from pop1.netway.at by ietf.org id aa22839; 6 Aug 97 16:38 EDT Received: from suleiman (l222t8p28.netway.at [195.96.1.92]) by pop1.netway.at (8.7.5/8.7.3) with ESMTP id WAA01181 for ; Wed, 6 Aug 1997 22:33:31 +0200 (MET DST) Message-ID: <33E8DF61.F3F7D730@netway.at> Date: Wed, 06 Aug 1997 22:32:33 +0200 Sender:ietf-request@ietf.org From: Chadi Suheil Suleiman Organization: none X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ietf@ietf.org Subject: REMOVE X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa27782; 6 Aug 97 19:07 EDT Received: from zephyr.isi.edu by ietf.org id aa27667; 6 Aug 97 19:06 EDT Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Wed, 6 Aug 1997 16:01:20 -0700 Message-Id: <199708062301.AA04651@zephyr.isi.edu> To: ietf@ietf.org, imr@isi.edu Subject: Internet Monthly Report for June, 1997 Cc: imr-ed@isi.edu Date: Wed, 06 Aug 97 16:01:19 PDT Sender:ietf-request@ietf.org From: IMR Editor Source-Info: From (or Sender) name not authenticated. June 1997 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. Each organization is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via network mail to "IMR-ED@ISI.EDU". ````````````````````````````````````````````````````````````````````` The Internet Monthly Report mailing list is now managed by MajorDomo at ISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be ADDED or DELETED from the Internet Monthly report list should be sent to "majordomo@isi.edu" with the message body either "subscribe imr" or "unsubscribe imr". Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_imrs". For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs or URL: http://www.isi.edu/in-notes/imr/ IMR Editor [Page 1] Internet Monthly Report June 1997 TABLE OF CONTENTS INTERNET ARCHITECTURE BOARD IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3 INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3 Internet Projects INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 16 Registration Services . . . . . . . . . . . . . . . . . page 16 Directory Services. . . . . . . . . . . . . . . . . . . page 17 US Domain Registry. . . . . . . . . . . . . . . . . . . page 18 MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 21 INET97 TRIP REPORT. . . . . . . . . . . . . . . . . . . . page 20 IANA REPORT . . . . . . . . . . . . . . . . . . . . . . . page 20 RFC EDITOR REPORT . . . . . . . . . . . . . . . . . . . . page 20 CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 24 TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 29 SOFTBANK Forums Future Events Calendar . . . . . . . . . . page 27 IMR Editor [Page 2] Internet Monthly Report June 1997 INTERNET ARCHITECTURE BOARD The minutes of the IAB back to 1990 are available for anonymous ftp access on host ftp.isi.edu, directory /pub/IAB, or via the IAB World-Wide Web page with URL http://www.iab.org/iab/. Brian Carpenter IAB Chair INTERNET ENGINEERING REPORTS ---------------------------- Internet Monthly Report for June, 1997 1. Let me remind everyone that the IETF returns to Europe for the summer meeting in Munich, Germany from August 11-15, 1997. Our hosts for this meeting will be Digi/ISOC.DE. The final meeting of the year will be held in Washington, DC from December 8-12, 1997. Our local host is Newbridge Networks. The IETF will meet in Los Angeles from March 30 - April, 3, 1998 and then in Chicago August 24-28, but the Secretariat is still working out some details, albeit the final stage. Once all arrangements have been made, notifications will be sent to the IETF Announcement list. Remember that information on future meetng sites can always be found in the file 0mtg-sites.txt, located on the IETF shadow directories. Of course, this information is provided on the Web. The IETF's URL is: http://www.ietf.org/ 2. The minutes of the IESG teleconferences be found on all the IETF shadow directories in the iesg directory. The following IESG minutes have been added: May 22, 1997 (iesg.97-05-22) 3. The IESG approved or recommended the following five Protocol Actions during the month of June, 1997: o Core Based Trees (CBT version 2) Multicast Routing Protocol Specification for publication as an Experimental Protocol. IMR Editor [Page 3] Internet Monthly Report June 1997 o Core Based Trees (CBT) Multicast Routing Architecture for publication as an Experimental Protocol. o IMAP4 IDLE command for publication as a Proposed Standard. o RTP Payload Format for H.263 Video Streams for publication as a Proposed Standard. o Internet Cache Protocol (ICP), version 2 for publication as an Informational RFC. 4. Nine Last Calls were issued by the IESG during the month of June, 1997: o IMAP4 Namespace for consideration as a Proposed Standard. o IMAP4 Mailbox Referrals for consideration as a Proposed Standard. o RPCSEC_GSS Protocol Specification for consideration as a Proposed Standard. o Use of an X.500/LDAP directory to support MIXER address mapping for consideration as a Proposed Standard. o Administratively Scoped IP Multicast for consideration as a Best Current Practices RFC. o Routing Policy Specification Language (RPSL) for consideration as a Proposed Standard. o Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) for consideration as a Proposed Standard. o IMAP4 Login Referrals for consideration as a Proposed Standard. o Authentication Mechanisms for ONC RPC for consideration as an Informational RFC. IMR Editor [Page 4] Internet Monthly Report June 1997 5. Two new working groups were created during the month: Virtual Router Redundancy Protocol (vrrp) Mobile Ad-hoc Networks (manet) 6. There were 131 Internet-Draft actions during the month of June, 1997: (rsvp) o Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification (dnssec) o Mapping Autonomous Systems Number into the Domain Name System (idr) o A Border Gateway Protocol 4 (BGP-4) (none) o Mobility Support in IPv6 (ion) o IP Broadcast over ATM Networks (receipt) o An Extensible Message Format for Message Disposition Notifications (trunkmib) o Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types (trunkmib) o Definitions of Managed Objects for the DS3/E3 Interface Type (ids) o A Common Schema for the Internet White Pages Service (intserv) o Integrated Services Management Information Base (rsvp) o RSVP Management Information Base (ipngwg) o Generic Packet Tunneling in IPv6 Specification (atommib) o Definitions of Tests for ATM Management (trunkmib) o Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type (atommib) o Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks (asid) o Lightweight Directory Access Protocol (v3) IMR Editor [Page 5] Internet Monthly Report June 1997 (asid) o Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions (avt) o RTP usage with Layered Multimedia Streams (none) o A Clarification of the STATUS Clause in SNMP MIB Modules (ifmib) o Definitions of Managed Objects for System and Interface Testing (svrloc) o Finding Stuff (How to discover services) (none) o The Domestication of the Opaque Type for SNMP (acap) o ACAP -- Application Configuration Access Protocol (avt) + RTP Payload for Redundant Audio Data (ipngwg) o IPv6 Router Alert Option (roamops) o Dialup Roaming Requirements (pkix) o Internet Public Key Infrastructure Part III: Certificate Management Protocols (agentx) o Agent Extensibility (AgentX) Protocol Version 1 (none) o VENUS - Very Extensive Non-Unicast Service (oncrpc) o RPCSEC_GSS Protocol Specification (atommib) o Accounting Information for ATM Networks (roamops) o Review of Roaming Implementations (pppext) o Layer Two Tunneling Protocol "L2TP" (none) o MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations (ipngwg) o IPv6 Multicast Address Assignments (none) o Advanced Sockets API for IPv6 (mboned) o Administratively Scoped IP Multicast (none) o The Multicast Dissemination Protocol (MDP) Framework IMR Editor [Page 6] Internet Monthly Report June 1997 (roamops) o The Network Access Identifier (asid) o Use of Language Codes in LDAPv3 (ftpext) o Extended Directory Listing and Restart Mechanism for FTP (none) o Label Switching: Label Stack Encodings (ftpext) o Internationalization of the File Transfer Protocol (svrloc) o Service Templates and service: Schemes (webdav) + HTTP-based Distributed Content Editing Scenarios (none) o The Weak Authentication and Tracing Option (urn) o Guidelines and a Framework for URN Resolution Systems (none) o Representing the Dublin Core within X.500, LDAP and CLDAP (ion) o Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks (atommib) + Managed Objects for Recording ATM Performance History Data Based on 15 Minute Intervals (vrrp) + Virtual Router Redundancy Protocol (applmib) o Definitions of Managed Objects for WWW Services (asid) o The LDAP Data Interchange Format (LDIF) - Technical Specification (drums) o Message Format Standard (dhc) o DHCP Relay Agent Information Option (issll) o Integrated Services over IEEE 802.1D/802.1p Networks (none) o Telnet Comport Control Option (none) o Multiprotocol Extensions for BGP-4 (ipngwg) o Management Information Base for IP Version 6: Textual Conventions and General Group (svrloc) o Advertising Services (Providing information to support service discovery) IMR Editor [Page 7] Internet Monthly Report June 1997 (rsvp) o RSVP Extensions for CIDR Aggregated Data Flows (mboned) o Some Issues for an Inter-domain Multicast Routing Protocol (webdav) + Requirements for Distributed Authoring and Versioning on the World Wide Web (none) o Definitions of Managed Objects for IEEE 802.1q Virtual LAN Bridges (http) o HTTP State Management Mechanism (Rev1) (none) o SMTP Service Extension for Secure SMTP over TLS (none) o Simple Integrated Media Access (SIMA) (ospf) o The OSPF NSSA Option (asid) o The LDAP URL Format (ngtrans) o A proposal for an IPv6 site database object (roamops) o Guidelines for the Secure Operation of RADIUS Proxies in Roaming (ipp) o Internet Printing Protocol/1.0: Model and Semantics (ipp) o Internet Printing Protocol/1.0: Directory Schema (none) o Directory Entries From Email Address (urn) o URI Resolution Services Necessary for URN Resolution (asid) o An Approach for Using LDAP as a Network Information Service (none) o Network Security For Trade Shows (none) o IPSEC Policy Import/Export Format (none) o Sieve: A Mail Filtering Language (disman) o Expression MIB (snmpv3) o An Architecture for Describing Internet Management Frameworks (printmib) o Job Monitoring MIB - V0.82 IMR Editor [Page 8] Internet Monthly Report June 1997 (avt) o RTP Payload Format for MPEG1/MPEG2 Video (none) o IMAP4 Namespace (none) o A Protocol for the Transmission of Net News Articles over IP multicast. (none) o PKCS 1: RSA Encryption Version 1.5 (none) o PKCS 7: Cryptographic Message Syntax Version 1.5 (none) o PKCS 10: Certification Request Syntax Version 1.5 (snmpv3) o Message Processing and Control Model for version 3 of the Simple Network Management Protocol (snmpv3) (snmpv3) o User-based Security Model for version 3 of the Simple Network Management Protocol (SNMPv3) (urn) o A URN Namespace for IETF Documents (ipngwg) o An IPv6 Aggregatable Global Unicast Address Format (none) o IP Version 6 Addressing Architecture (dnssec) + Storage of Diffie-Hellman Keys in the Domain Name System (none) + Media-independent Error Correction using RTP (acap) o Multi-Lingual String Format (MLSF) (tn3270e) o Base Definitions of Managed Objects for TN3270E Using SMIv2 (asid) o Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security (none) o Plaintext Password SASL Mechanism and Transition Codes (webdav) + HTTP-based Distributed Content Editing Scenarios (none) o The IP Network Address Translator (NAT) (none) + Interoperation Between Distinct Types of Label Switched Paths (none) + Hot Standby Router Protocol (HSRP) IMR Editor [Page 9] Internet Monthly Report June 1997 (ipngwg) + IP Version 6 Management Information Base for the Transmission Control Protocol (none) + Uniform Resource Locators for Television Broadcasts (ipngwg) + IP Version 6 Management Information Base for the User Datagram Protocol (find) + CIP Transport Protocols (ftpext) + Feature negotiation mechanism for the File Transfer Protocol (find) + MIME Object Definitions for the Common Indexing Protocol (CIP) (find) + The Architecture of the Common Indexing Protocol (CIP) (none) + A Clarification for Textual Conventions in SMIv2 (none) + Support for Floating-Point in SNMP (none) + Support for Large Integers in SNMP (none) + The BITS Pseudotype (none) + Firewall Traversal authorization system (http) + Scenarios for the Delivery of Negotiated Content using HTTP (http) + HTTP/1.1 305 and 306 Response Codes (none) + Description of the EP2 Cipher (none) + Virtual Server Protocol (rsvp) + RAPI -- An RSVP Application Programming Interface (ipngwg) + Transmission of IPv6 Packets over Token Ring Networks (snmpv3) + Access Control Model for version 3 of the Simple Network Management Protocol (SNMPv3) (none) + Anonymous SASL Mechanism (none) + Application Protocol Design Principles (acap) + Two Alternative Proposals for Language Taging in ACAP IMR Editor [Page 10] Internet Monthly Report June 1997 (none) + Internet Security Label (ISL) (none) + A Description of the RC2(r) Encryption Algorithm (none) + PACE(TM) Technology's Ethernet Interactive Access Algorithm (none) + IETF Policy on Character Sets and Languages (ipp) + Internet Printing Protocol/1.0: Security (none) + Telnet Authentication: SRP 7. 18 RFCs were published during this period RFC2117 E (idmr) Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification RFC2151 I (none) A Primer On Internet and TCP/IP Tools and Utilities RFC2152 I (none) A Mail-Safe Transformation Format of Unicode RFC2153 I (pppext) PPP Vendor Extensions RFC2154 E (none) OSPF with Digital Signatures RFC2155 PS (snanau) Definitions of Managed Objects for APPN using SMIv2 RFC2165 PS (svrloc) Service Location Protocol RFC2166 I (none) APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements RFC2167 I (none) Referral Whois (RWhois) Protocol V1.5 RFC2168 E (urn) Resolution of Uniform Resource Identifiers using the Domain Name System RFC2169 E (urn) A Trivial Convention for using HTTP in URN Resolution RFC2171 I (none) MAPOS - Multiple Access Protocol over SONET/SDH Version 1 RFC2172 I (none) MAPOS Version 1 Assigned Numbers RFC2173 I (none) A MAPOS version 1 Extension - Node Switch Protocol RFC2174 I (none) A MAPOS version 1 Extension - Switch-Switch Protocol RFC2175 I (none) MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing RFC2176 I (none) IPv4 over MAPOS Version 1 RFC2200 S (none) INTERNET OFFICIAL PROTOCOL STANDARDS IMR Editor [Page 11] Internet Monthly Report June 1997 INTERNET PROJECTS ----------------- INTERNIC -------- REGISTRATION SERVICES June InterNIC Stats Monthly Registrations: 112,661 Gopher Sessions: 37,164 Retrievals: 5616 WAIS Sessions: 18312 Retrievals: 5920 FTP Sessions: 66,074 Retrievals: 112,711 Telnet Sessions: 39,455 HTTP: 6,256,351 Whois Client Queries: 3,007,156 Whois Server Queries: 13,186,747 Updates: 219,772 Rich Landers INTERNIC DIRECTORY AND DATABASE SERVICES The June Seed Database for Netfind has 1.62 million entries. For full searching of this database, you should be using version 5.0.2 of the Netfind source code. Both the seed database and the Netfind source code are available at: http://www.internic.net/wp/netfind-seeddb.html Work is proceeding on a new version of Netfind, version 5.1. We expect an alpha version to be available in July. Netfind 5.1 will have the following features: - More complex Boolean queries - Use of DNS SRV records to help find directory resources - Direct LDAP interface - Cleaned up architecture that better distributes functions among modules IMR Editor [Page 12] Internet Monthly Report June 1997 A reminder - if you would like to help the Internet community find a resource that you offer, send mail to admin@ds.internic.net and we will send information about listing your resource in the Directory of Directories. If you prefer, you can enter information about your resource in our WWW suggestion form. The form can be reached through our Directory of Directories Web page at: http://ds.internic.net:80/ds/dsdirofdirs.html by Rick Huber THE US DOMAIN REGISTRY A new policy has been added regarding the locality delegation. As of 1-Jul-97, it is assumed by the US Domain Administrator that every applicant for the delegation (or redelegation) of a locality name has the written agreement of the legitimate government for that locality for the applicant to manage the domain name of that locality. Evidience of such an agreement does not need to be presented at the time of delegation (except that the administrative contact on the application template must be the government representative). However, if the delegation is later challenged or contested, the manager of the locality domain must produce the agreement. Failure to do so will most likely result in the transfer of the management of the locality domain to another manager that does have such an agreement. If there is a dispute as to what is the legitimate government for a locality is and who may act for it, the league of cities or association of municipalities that each state (as recognized by the National League of Cities) may be asked to assist in resolving such disputes. In some places there are overlapping jurisdictions with the same name (for example, the city of Los Angeles and the county of Los Angeles). In such cases, the higher level government should have priority. The US Domain registration form is now available online at http://www.isi.edu/us-domain. The US Domain has the maps of all the delegated special domains online at http://www.isi.edu/us-domain. IMR Editor [Page 13] Internet Monthly Report June 1997 The US Domain administrator no longer makes direct registrations of hosts, and only makes delegations of third or fourth level domain names (such as localities). Some of the processing of the requests to the third level domain name is now automated. In particular, most requests to register names in localities already delegated are automatically forwarded to the administrator of that locality. A new policy has been added regarding the charges for the domain name passed on during delegation. The administrator of the locality has to notify one year in advance before charging for those domains. US DOMAIN ADMINISTRATIVE INFORMATION ==================================== EMAIL/FAX 3139 PHONE 525 ---------------------------- Total Contacts 3664 DELEGATIONS 70 FORWARDED REQUESTS: 1211 OTHER US DOMAIN MSGS:2383 --------------------------- Total 3664 OTHER US DOMAIN MESSAGES include referrals to other subdomains or to/from the InterNic, phone calls, modifications, application requests, discussion and clarification of the requests, questions about names, resolving technical problems with zone files and name servers, and whois listings. MAJOR SUBDOMAINS DELEGATED ========================== K12 CC TEC STATE LIB MUS GEN DST COG =================================================================== 52 39 36 47 41 26 27 10 6 =================================================================== IMR Editor [Page 14] Internet Monthly Report June 1997 THIRD LEVEL DELEGATIONS ======================== CC.TN.US. Community Colleges, Tennessee. TEC.TN.US. Technical and Vocational Schools, Tennessee. LOCALITIES ========== ST-BERNARD.LA.US. WILLISTOWN.PA.US. ROSS.PA.US. SAINT-LOUIS.MO.US. OSWEGO.OR.US. WOODSIDE.CA.US. MADISON.NH.US. LA-PINE.OR.US. WARM-SPRINGS.OR.US. CAROLINE.VA.US. MAYVILLE.WI.US. CHICHESTER.NH.US. EATON.NH.US. EFFINGHAM.NH.US. FREEDOM.NH.US. GOSHEN.NH.US. GRANTHAM.NH.US. MADBURY.NH.US. MILAN.NH.US. NELSON.NH.US. NEWBURY.NH.US. PERKINS.OK.US. KINGSHILL.VI.US. DEWITT.MI.US. EATON-RAPIDS.MI.US. GRAND-LEDGE.MI.US. CHARLOTTE.MI.US. MASON.MI.US. HOLD.MI.US. WILLIAMSTON.MI.US. HASLETT.MI.US. PROTLAND.MI.US. MULLAN.ID.US. KELLOGG.ID.US. HALF-MOON-BAY.CA.US. SAINT-MICHAELS.MD.US. MILAN.IL.US. FLEISCHMANNS.NY.US. VININGS.GA.US. MONTICELLO.KY.US. MORLEY.NY.US. JOPLIN.MT.US. HEALY.AK.US. TOK.AK.US. SPRINGDALE.OH.US. We delegated 1 Native Soverign Nations - COWCREEK.NSN.US. IMR Editor [Page 15] Internet Monthly Report June 1997 OTHER US DOMAIN DELEGATIONS THIS MONTH ====================================== CI.GLENDORA.CA.US. GARDNER.PERRY.MI.US. PORTSMOUTH.LIB.NH.US. STONERIDGE.TARZANA.CA.US. ELEPHANT.ALEXANDER.NC.US. PREUNINGER.HUGHES-SPRINGS.TX.US. HAAS.KENSINGTON.CA.US. CI.WOODLAKE.CA.US. GLENDORA.LIB.CA.US. CI.SHASTA-LAKE.CA.US. WEBMASTER.RESEDA.CA.US. NGAUS.GEN.NM.US. WCV77.NEWPORT.NY.US. CI.ELBRIDGE.NY.US. LAWD.DST.CA.US. CI.RANCHO-MIRAGE.CA.US. FUTURE.GOESSEL.KS.US. CO.ALEXANDER.NC.US. SMPL.LIB.CA.US. CI.COLFAX.WA.US. SHENANDOAHCO.LIB.VA.US. WWW.ROCKINGHAM.LIB.VA.US. ----------------------------------------------------------- URL: http://www.isi.edu/us-domain/ Shanthi Ranganathan (US-Domain@ISI.EDU) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MERIT INTERNET ENGINEERING -------------------------- This report summarizes June 1997 activities of Merit's Internet Engineering group on behalf of the Routing Arbiter (RA) service and other projects. Merit is pleased to announce a new initiative, the Policy Analysis of Internet Routing (PAIR) project. A collaboration among staff from the Routing Arbiter Database and Route Server Next Generation (RSng) projects, PAIR is developing tools that will help ISPs, network operators, and end users troubleshoot routing and policy problems in the Internet. The tools were developed in response to requests from organizations peering with the RSng Route Servers, and greatly improve the peers' ability to track internal routing processes in the Route Server systems. Using PAIR, you can answer questions such as: - Why isn't Provider A seeing any of my routes? - What routes am I exporting to Provider B? - According to the policy that Provider C registered in the IRR, what routes should it be exporting to my AS? IMR Editor [Page 16] Internet Monthly Report June 1997 PAIR makes it possible to compare prescribed policy, i.e., policy registered in the Internet Routing Registry, with policy actually being configured in the Internet. You can use the PAIR tools to: - Learn how the policy in IRR AS Objects is processed and used to generate Route Server configuration files - Gain an understanding of internal Route Server processes, such as policy configurations and state tables - Pinpoint discrepancies between registered policy and actual routing announcements - Troubleshoot global routing problems - Identify stale or inaccurate data in the Internet Routing Registry Members of Merit's PAIR team are Jake Khuon, Jerry Winters, Abha Ahuja, and Tom Spindler. For more information about the project, see: http://www.rsng.net/pair/ ------------------------------------------------------------ With the final release of Scion, the popular network monitoring package, work is now complete on the one-year NetSCARF (Network Statistics Collection And Reporting Facility) Project. Funded by a grant from the Resource Allocation Committee, the project has been extremely successful; to date, more than 1700 users in 70 countries have downloaded the Scion code. Merit's NetSCARF team includes Bill Norton, project director, Andy Adams, lead software architect, and programmer Bill Siadak. Scion can be used by ISPs to collect network statistics and display performance reports on the World Wide Web. The code, derived from the initial NSFNET project's statistics collection and reporting activities, is easy to install and run. Every ten minutes, Scion's optimized SNMP library queries ISP routers for the values of variables such as sysUpTim and ifLastChange. The library uses SNMP Version 1, and can be configured to use SNMPv2u, the User-based Security model for SNMPv2. Scion's SNMP API is unique, in that it allows the developer to specify a list of nodes, a community string (or userid/authentication password/privacy password in the case of SNMPv2u), and a list of management objects to retrieve. All queries are then transmitted back- to-back, without waiting for any replies. The data collection activity is thus very fast, and the results highly synchronized. Other publicly available SNMP libraries force applications to wait for a response (or timeout) for a given query before the next query can be issued to a different node. IMR Editor [Page 17] Internet Monthly Report June 1997 The raw SNMP statistics are pre-processed each evening, and the processed data delivered to CGI scripts, using what the developers believe to be the first public domain implementation of the OpStats (RFC 1856) client/server model. Finally, ISP performance reports based on the 'cooked' data are displayed on the Web via the CGI scripts. ISPs can use the Scion code to automatically produce HTML graphs showing system uptime, interface uptime, and total network traffic measured in packets. An advanced statistics Web page allows users to specify customized graphing parameters. Some of the new features contained in version 3.0 are: - A moving strip chart that can be used to monitor traffic and display network data in real-time. - A new graphical tool, scadmin, which allows you to associate nodes with arbitrary names instead of hard-to-remember IP addresses. The tool can also be used to control access to each node on a per-user basis. - Interfaces can be marked as internal or external to the network. - Clickable graphs make it possible to zoom in on traffic graphs to display greater detail. Source and binaries are available for Solaris, SunOS, BSDI, AIX, and Windows NT. For information on downloading version 3.0, see: http://www.merit.edu/~netscarf/ ------------------------------------------------------------ Merit continues to expand its Web collection of "Internet Resources for ISPs". The site now contains information on: - Outage Notification Services - Routing and Exchange Points - Routing Tools and Analysis - CIDR - Statistics and Network Management - Internet Organizations - Ethics - Other ISP Web Pages - Other Useful References See: http://www.merit.edu/ipma/docs/isp.html ------------------------------------------------------------ IMR Editor [Page 18] Internet Monthly Report June 1997 IBM Global Services hosted the tenth North American Network Operators' Group (NANOG) meeting in Tampa on June 6-7. Stan Barber of Academ Consulting Services has kindly made available a complete set of notes and slides from the meeting; they are available through the NANOG Web site (http://www.nanog.org). Bill Norton of Merit moderated the meeting. which featured the following presentations: - Introduction to Network Performance Measurement (Daniel McRobb, ANS) - Performance Measures for Multimedia Applications (Randy Bloomfield, Institute for Telecommunication Sciences) - Practical Aspects of Wireless Networking (Stephen Stuart, Digital) - Current Issues in Inter-Provider Multicasting (Dave Meyer, Univ. of Oregon) - The Zebra Distributed Routing Software (Kunihiro Ishiguro, Digital Magic Labs) - International Exchange Points: Growth & Trends (Bill Manning, ISI) - Large & Small Exchange Points: Advantages, Tradeoffs, Futures (Bill Manning) - Limiting Use of MEDs at the Exchange Points (Randy Bush, Verio, Inc.) - Draining the Swamp: Summary of Renumbering Efforts (Bill Manning) - InterNIC Update (Mark Kosters, InterNIC) - ARIN Update (Kim Hubbard, InterNIC) - Challenges of Creating Ubiquitous Global Internets - the Teledesic Example (Hans-Werner Braun, Teledesic) - Applications of Routing Policy System Language (RPSL) (Dave Meyer, Univ. of Oregon) - Report on Inter-Provider Cooperation (Randy Bush) - BGP Community Support in GateD (Sue Hares, Merit) - CAIDA (Cooperative Association for Internet Data Analysis) and ISMA (Internet Statistics and Metrics Analysis) (K. Claffy, NLANR) - Australian National NAP Fabric (Thomas Koltai, Australian Internet Exchange Fabric - AUIX) A highlight of the "Open Issues Forum" was a discussion of ISP-to- telco operational issues, which included a presentation by PacBell NAP manager Fran Clairmont. The meeting also featured a tutorial titled "Review of Internet Resources for ISPs," presented by Michael Dillon of Priori Networks Inc., as well as demonstrations of freely available tools for troubleshooting network problems and registering policy in the Internet Routing Registry. ------------------------------------------------------------ IMR Editor [Page 19] Internet Monthly Report June 1997 Sue Hares taught sessions on Backbone Internetworking Technology at the Internet Society's Workshop on Network Technology for Countries in the Early Stages of Internetworking, presented in conjunction with the INET'97 conference. The workshop was held in Kuala Lumpur, Malaysia. Susan R. Harris (srh@merit.edu) INET97 REPORT ------------- Trip Report INET97 - Kuala Lumpur, Malaysia June 1997 Joyce K. Reynolds USC/Information Sciences Institute The Internet Society's INET 97 was held in June 1997, in Kuala, Lumpur, Malaysia, with approximately 2500 attendees. Joyce K. Reynolds was the User co-track leader of INET97, along with Mark Prior, connect.com.au pty ltd, Australia. Joyce and Mark worked with John Hine (INET97 Program Chair) and the rest of the invited program committee members to produce the agenda and proceedings for the conference. The INET97 User Track had seven sessions: - Electronic Publishing - Using Technology - Art and the Internet - Impact of the Internet - Disabilities - Community Networking - Disabilitites Panel For further information on the User Track presentations, presenters and panelists, please see: http://www.isoc.org/inet97/proceedings/INDEX.HTM IMR Editor [Page 20] Internet Monthly Report June 1997 IANA REPORT ----------- Here is the June Report on IANA activity and assignments: Country Codes 2 DHCP Options 3 Domain System Parameters 2 Media Types 11 Multicast Addresses: Individual Assignments 4 Novell SAP Numbers 2 Private Enterprise Numbers 59 Port Numbers 34 SMI Numbers 3 Josh Elliott RFC EDITOR REPORT ----------------- This is a summary of Request for Comments Editor activity for the month of June, 1997: TIME IN QUEUE DOCUMENTS New* 30 days 60 days 90 days TOTAL ------------------------------------------------------------------ | Beginning of 0 25 4 7 | 36 month | | New 11 0 0 0 | 11 | | Processed 3 12 4 1 | 20 ------------------------------------------------------------------ | End of month 8 13 0 6 | 27 * New RFCs added to queue throughout the month IMR Editor [Page 21] Internet Monthly Report June 1997 The Requests for Comments (RFCs) are a series of notes, started in 1969, about the Internet (originally the ARPANET). The notes discuss many aspects of computing and computer communication focusing in networking protocols, procedures, programs, and concepts, but also including meeting notes, opinion, and sometimes humor. The specification documents of the Internet protocol suite, as defined by the Internet Engineering Task Force (IETF) and its steering group (the IESG), are published as RFCs. RFCs-to-be are edited by the RFC Editor. RFCs enter the RFC Editor's work queue either by an action of the IESG or by independent submission. Most independent submissions are referred to the IESG to check for overlap with IETF work. The IESG might put a hold on a document to gather more input from its members. The wait for an RFC to be published varies as there can be unforeseen complications (typically editorial matters that need clarification from the author). Documents can be removed from the publication queue if they are found to be insufficient or incorrect or if the IESG asks the author to join work already in progress in the IETF. Mary Kennedy IMR Editor [Page 22] Internet Monthly Report June 1997 CALENDAR -------- Last update 07/10/97 The information below has been submitted to the IETF Secretariat as a means of notifying readers of future events. Readers are requested to send in dates of events that are appropriate for this calendar section. Please send submissions, corrections, etc., to: Please note: The Secretariat does not maintain on-line information for the events listed below. A copy of this calendar is available as follows: VIA FTP ------- IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) Africa Address: ftp.is.co.za (196.4.160.12) cd ietf ls *0mtg* WWW ------- Click on the link for "meetings" and you should find an entry "listing of other Internet related events". ************************************************************************ 1997 ----------- Jul. 14-17 5th TCL/TK Workshop Boston, MA Jul. 14-18 ANSI X3T10 '97 Jul. 14-17 APPN Implementers Workshop San Jose, CA Jul. 17-19 VTIC-97 San Jose CA Jul. 20-25 ATM Forum Montreal, CANADA IMR Editor [Page 23] Internet Monthly Report June 1997 Jul. 23-26 ACM DL '97 2nd ACM Int'l Conf. on Digital Libraries Philadelphia, PA Jul. 24-25 DMS '97 Vancouver, CANADA Aug. 4-8 ANSI X3T11 (host by Hitachi) Honolulu, HI Aug. 11-15 39th IETF (host by German ISOC) Munich, Germany Aug. 12-14 DCI's Internet Expo Boston, MA Aug. 13-15 IEEE 25th Annual Int'l Computer Software and Application Conference Washington, DC Sep. RIPE28 TBD Sep 2-5 1997 Int'l Conference Intelligent Networks and Intelligence in Networks Paris, France Sep. 5 TERENA Technical Committee Amsterdam Sep. 5 TERENA Executive Committee Amsterdam Sep. 7-11 5th European Conf. on Computer Supported Coop. Work Lancaster University U.K. Sep. 8-12 ANSI X3T10 '97 Sep. 8-12 OIW (Firm) Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland Sep. 10-12 IDMS '97 w/ ACM SIGMM, GMD, IEEE Darmstadt, Germany Sep. 11-12 4th Int'l Workshop on Community Networking (IEEE) Atlanta, Georgia Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France Sep. 16-17 EWOS Assembly Brussels Sep. 21-26 ATM Forum Paris, France Sep. 26-30 3rd ACM/IEEE on Mobile Computing & Networking 1997 (MobiCom'97) Budapest, Hungary Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ Oct. 7-10 COMDEX Internet '97 and Object World '97 Internet Forum Europe (IFE) & Object World Frankfurt (OWF) Frankfurt, Germany Oct. 15-17 ACM SIGPLAN - Conf. on Domain-Specific Languages Santa Barbara, CA Oct. 23-24 TERENA General Assembly Madrid Oct. 24-26 1st Int'l Enterprise Distributed Objected Computing Wrkshop EDOC '97 Gold Coast, Australia Oct. 23-25 ETSI Nice, France Oct. 26-31 LISA '97 - 11th Systems Administration Conference San Diego, CA Oct. 27-31 EWOS Workshops Brussels Oct. 28-31 IEEE Int'l Conf. on Network Protocols Atlanta, GA Nov. 3-5 Int'l Test Conference 1997 Sheraton Washington Hotel Washington, DC Nov. 3-7 ANSI X3T10 '97 IMR Editor [Page 24] Internet Monthly Report June 1997 Nov. 3-7 SPIE Int'l Symposium Voice, Video & Data Communications Conf. on Performance & Control of Network System - Special Session on Switching & Traffic Mgmt in High Speed Networks Dallas, TX Nov. 3-7 2nd French/Brazilian Symposium on Distributed System Architectures: Telecommunication Multimedia Architectures Ceara, Brazil Nov. 8-14 ACM MULTIMEDIA '97 Seattle, WA Nov. 10-14 IEEE 802 Plenary Queen Elizabeth, Montreal Nov. 12-13 CEN/CENELEC/ETSI Brussels Nov. 19-21 ICCC'97 Cannes, France Nov. 24-26 PROMSMmNet '97 Multimedia Networking Santiago, Chile Nov. 30-Dec 5 ATM Forum Singapore Dec. 1-3 30th IEEE/ACM Int'l Symposium on Microarchitecture RTC, NCA Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL Dec. 2-3 EWOS Assembly Brussels Dec. 8-12 40th IETF (Host: Newbridge) Washington, DC Dec. 8-12 OIW (Firm) Dec. 8-12 USENIX Symposium on Internet Technology and Systems) Monterey, CA Dec. 17-19 97 Int'l Sym. on Communications Hsinchu, Taiwan TBA TELECOM '97 Asia TBA 1998 ----------- Jan 6-8 W3C Interest Group Mtg TBA Jan. RIPE29 Amsterdam (tbd) Jan 26-29 7th Security Symposium San Antonio, TX Feb. 8-13 ATM Forum Anaheim, CA Feb 7-9 DCI'S Internet Expo San Jose, CA Mar. 9-11 2nd Euromicro Working Conf. on Soft. Maint. & Reeng. Florence, Italy Mar. 9-13 IEEE 802 Plenary Irvine, CA Mar. 29-Apr 2 IEEE INFOCOM '98 - Hotel Nikko San Francisco, CA Mar. 30-Apr. 3 41st IETF (Tentative) Los Angeles, CA Apr. 3-4 IEEE "OPENARCH '98" San Francisco, CA Apr. 12-17 WWW7 Brisbane, Australia Apr. 18-23 CHI '98 (ACM SIGCHI) Los Angeles, CA Apr. 19-24 ATM Forum Berlin, Germany Apr 20-22 W3C Interest Group Mtg TBA May RIPE30 Stockholm (tbd) May 5-8 Networld+Interop '98 Las Vegas, NV IMR Editor [Page 25] Internet Monthly Report June 1997 SPRING 1998 TELECOM '97 Africa Midrand, South Africa Jun 13-17 USENIX '98 Technical Conf. New Orleans, LA Jun 16-18 DCI's Internet Expo Chicago, IL Jul. 6-10 IEEE 802 Plenary San Diego, CA Jul. 20-24 INET '98 TBA Jul. 26-31 ATM Forum Portland, OR Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and Budapest, Hungary Aug. 23-28 42nd IETF (Tentative) Chicago, IL Aug. 29-Sep 4 SIGCOMM '98 Vancouver, CANADA Sep 1-3 DCI's Internet Expo Boston, MA Oct. 4-9 ATM Forum Gold Coast, Australia Oct 20-22 W3C Interest Group Mtg TBA Oct 21-23 Networld+Interop '98 Atlanta, GA Oct. 26-29 TERENA (host by DFN) Dresden, Germany Nov. 9-13 IEEE 802 Plenary Albuquerque, NM Nov. 29-Dec 4 ATM Forum Nashville, TN Dec. 6-11 12th Systems Administration Conf. (LISA '98) Boston, MA Dec. 7-11 43rd IETF (Tentative) TBA 1999 ----- Feb. 7-13 ATM Forum (tentative) TBA Feb 23-25 W3C Interest Group Mtg TBA Apr. 18-24 ATM Forum (tentative) TBA May 11-14 Networld+Interop '99 Las Vegas, NV May 31-Jun 4 WWW8 Toronto, CANADA Jun 4-6 W3C Interest Group Mtg TBA Jul. 18-24 ATM Forum (tentative) TBA late Aug SIGCOMM '99 (West Coast US) TBA Sep. 21-23 W3C Interest Group Mtg TBA Sep. 26-Oct 2 ATM Forum (tentative) TBA Oct. 8-14 TELECOM '99 Geneva, Switzerland Oct. 13-17 Networld+Interop '99 Atlanta, GA Nov. 28-Dec 4 ATM Forum (tentative) TBA 2000 ---- May 9-11 Networld+Interop '00 Las Vegas, NV late Aug SIGCOMM 2000 Europe (tentative) Sep 25-29 Networld+Interop '00 Atlanta, GA IMR Editor [Page 26] Internet Monthly Report June 1997 TERENA LIST OF MEETINGS ----------------------- The current TERENA Calendar may be found on URL: http://www.terena.nl/news/calendar.html +++++++++++++++++++++++++++++++++++++++++++++ + + + TERENA Secretariat + + Singel 466-468 + + 1017 AW Amsterdam + + the Netherlands + + + + email + + + + tel: +31 20 639 1131 + + fax: +31 20 639 3289 + + + +++++++++++++++++++++++++++++++++++++++++++++ IMR Editor [Page 27] Internet Monthly Report June 1997 SOFTBANK Forums =============== 1997 Future Event Calendar All dates are subject to change Revision Date: 7/9/97 * Indicates an addition or correction Business Conferences & Expositions Support Services Conference & Expo West * San Jose Convention Center Conference: August 6-8, 1997 San Jose, CA Exposition: August 5-7, 1997 Registration (SOFTBANK Knowledge Interact) (800) 801-1354 (719) 531-6522 Housing (800) 754-8378 (415) 378-6643 Windows NT Intranet Solutions Moscone Convention Center Conference: August 11-15, 1997 San Francisco, CA Exposition: August 13-15, 1997 Housing and Registration (888) 800-8920 (415) 372-7071 Java Internet Business Expo Jacob K. Javits Convention Center Conference: August 25-28, 1997 New York, NY Exposition: August 26-28, 1997 Housing and Registration (888) 528-2397 (415) 372-7069 IMR Editor [Page 28] Internet Monthly Report June 1997 Technology Performance Management Conference and Expo Opryland Hotel Conference: Sept 14-17, 1997 Nashville, TN Exposition: Sept 14-17, 1997 Registration (SOFTBANK Knowledge Interact) (800) 909-9848 (719) 531-6522 Housing (888) 282-0807 (415) 378-7079 Seybold San Francisco Moscone Convention Center Conference: Sept 29-Oct 3, 1997 San Francisco, CA Exposition: Oct 1-3, 1997 Housing and Registration (888) 473-9265 (415) 372-7078 Networld+Interop 97 Atlanta Georgia World Congress Center Conference: Oct 6-10, 1997 Atlanta, GA Exhibition: Oct 8-10, 1997 Housing and Registration (800) 962-6513 (415) 372-7079 Networld+Interop 97 Paris Porte de Versailles Conference: Oct 20-23, 1997 Paris, France Exhibition: Oct 21-23, 1997 Information 011 (33) 1 46 39 5656 Networld+Interop 97 London Earls Court 2 Conference: Oct 27-30, 1997 London, England Exhibition: Oct 28-30, 1997 Information 011 (44) 0181 261 4415 Windows NT Intranet Solutions Japan Makuhari Messe Conference: Nov 12-14, 1997 Tokyo, Japan Exhibition: Nov 12-14, 1997 Information 011 (81) 3 5642 8433 Networld+Interop 97 Sydney Sydney Convention Center Conference: Nov 24-28, 1997 Sydney, Australia Exposition: Nov 26-28, 1997 Information 011 (61) 2 9369 1242 IMR Editor [Page 29] Internet Monthly Report June 1997 Seybold Seminars Tokyo Makuhari Messe Conference: Dec 9-12, 1997 Tokyo, Japan Exposition: Dec 10-12, 1997 Information 011 (81) 3 5642 8433 Strategic Networks Seminars * Strategic Networks offers one-day seminars for Interop Remote Access, Interop NetSwitch, Interop WAN, and Interop Secure ManageNet periodically throughout the year in various locations in the United States. For registration information, please call Strategic Networks at 800-875-9108. For sponsor opportunities, please call Strategic Networks at 800-999-7624. Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Minneapolis, MN Seminar: Sept 4, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Washington DC Seminar: Sept 11, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Toronto, Canada Seminar: Sept 30, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Denver, CO Seminar: Oct 16, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Hartford, CT Seminar: Oct 21, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Los Angeles, CA Seminar: Oct 23, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Pittsburgh, PA Seminar: Oct 30, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology Newark, NJ Seminar: Nov 6, 1997 IMR Editor [Page 30] Internet Monthly Report June 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Washington DC Seminar: Sept 4, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Newark, NJ Seminar: Sept 9, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Chicago, IL Seminar: Sept 11, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Boston, MA Seminar: Sept 30, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Los Angeles, CA Seminar: Oct 16, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Minneapolis, MN Seminar: Oct 21, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through San Francisco, CA Seminar: Oct 28, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Atlanta, GA Seminar: Nov 6, 1997 Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through Philadelphia, PA Seminar: Nov 13, 1997 Interop Secure ManageNet 97 Tour San Francisco, CA Seminar: Sept 9, 1997 Interop Secure ManageNet 97 Tour Los Angeles, CA Seminar: Sept 11, 1997 Interop Secure ManageNet 97 Tour Washington DC Seminar: Oct 16, 1997 Interop Secure ManageNet 97 Tour Newark, NJ Seminar: Oct 21, 1997 IMR Editor [Page 31] Internet Monthly Report June 1997 Interop Secure ManageNet 97 Tour Chicago, IL Seminar: Oct 23, 1997 Interop Secure ManageNet 97 Tour Boston, MA Seminar: Oct 28, 1997 Interop Secure ManageNet 97 Tour Toronto, Canada Seminar: Oct 30, 1997 Interop Secure ManageNet 97 Tour Minneapolis, MN Seminar: Nov 6, 1997 Help Desk Institute Regional Seminar and Expo Series Help Desk Institute offers several seminar series periodically throughout the year in various locations across the United States. For registration information, please call 800-248-5667. Regional Seminar & Expo Series Sheraton Washington Seminar: July 14-18, 1997 Washington DC Expo: July 16, 1997 Regional Seminar & Expo Series Town & Country Resort Seminar: Oct 6-10, 1997 San Diego, CA Expo: Oct 8, 1997 Software Support Professionals Association (SSPA) SSPA offers a variety of support programs throughout the year which include executive forums, software support conferences, and monthly online roundtable and executive sessions. For a description of the events and for registration information, please call SSPA at (800) 552-3058 or (619) 674-4864. Virtual Roundtable - "Staffing and Scheduling Tools for Software Support" Held Online Roundtable: July 16, 1997 http://www.sspa-online.com 10:00 A.M. PST Executive Session Held Online Session: July 22, 1997 http://www.sspa-online.com 10:00 A.M. PST Virtual Roundtable - "Building Supportability into Products" Held Online Roundtable: August 20, 1997 http://www.sspa-online.com 10:00 A.M. PST IMR Editor [Page 32] Internet Monthly Report June 1997 Executive Session Held Online Session: August 26, 1997 http://www.sspa-online.com 10:00 A.M. PST Virtual Roundtable - "Harnessing the WWW as a Support Resource" Held Online Roundtable: Sept 17, 1997 http://www.sspa-online.com 10:00 A.M. PST Executive Session Held Online Session: Sept 23, 1997 http://www.sspa-online.com 10:00 A.M. PST SSPA's Electronic Customer Support Conference San Diego, CA Conference: Oct 15-17, 1997 (800) 552-3058 (619) 674-4864 Virtual Roundtable - "The Virtual Support Center" Held Online Roundtable: Oct 22, 1997 http://www.sspa-online.com 10:00 A.M. PST Executive Session Held Online Session: Oct 28, 1997 http://www.sspa-online.com 10:00 A.M. PST Virtual Roundtable - "Justifying the Benefits of CTI, IVR, and ACD Systems" Held Online Roundtable: Nov 19, 1997 http://www.sspa-online.com 10:00 A.M. PST Executive Session Held Online Session: Nov 25, 1997 http://www.sspa-online.com 10:00 A.M. PST Executive Forum Palm Springs, CA Forum: Dec 4-5, 1997 (800) 552-3058 (619) 674-4864 SSPA Stars Awards and Membership Meeting San Jose, CA Meeting: Dec 3, 1997 (800) 552-3058 (619) 674-4864 Virtual Roundtable - "A New Training Paradigm for Software Support" Held Online Roundtable: Dec , 1997 (TBA) http://www.sspa-online.com 10:00 A.M. PST IMR Editor [Page 33] Internet Monthly Report June 1997 Executive Session Held Online Session: Dec 23, 1997 http://www.sspa-online.com 10:00 A.M. PST SOFTBANK Knowledge Interact Seminars SOFTBANK Knowledge Interact offers SkillTech Professional Seminars periodically throughout the year in various locations throughout the United States. For a calendar of 1997 events and registration information, please call SOFTBANK Knowledge Interact at 800-34-TRAIN. SOFTBANK Forums 303 Vintage Park Drive Foster City, CA 94404 (415) 578-6900 Fax: (415) 525-0194 http://www.sbforums.com IMR Editor [Page 34]   Received: from ietf.org by ietf.org id aa27757; 6 Aug 97 19:07 EDT Received: from zephyr.isi.edu by ietf.org id aa27456; 6 Aug 97 19:03 EDT Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Wed, 6 Aug 1997 15:59:07 -0700 Message-Id: <199708062259.AA04523@zephyr.isi.edu> To: IETF-Announce: ; To: Internet-Monthly-Report-People: ; Subject: Internet Monthly Report for June, 1997 Cc: imr-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Wed, 06 Aug 97 15:59:07 PDT Sender:ietf-announce-request@ietf.org From: IMR Editor --NextPart The Internet Monthly Report for June, 1997 is now available at the following location: URL= ftp://ftp.isi.edu/in-notes/imr/imr9706.txt The Internet Monthly Report (IMR) is normally distributed via EMail to the IMR list and the IETF list. For most readers this is the most convenient way to receive the report. However, there are some mail systems or mail gateways that do not accommodate large messages (some issues of the IMR are more than 100,000 characters). Readers that do not receive the IMR via the normal distribution may obtain copies via FTP or EMail retrieval. Requests to be added or deleted from the IMR report list: The Internet Monthly Report list is managed by MajorDomo atISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be added or deleted from the Internet Monthly report list should be sent to majordomo@isi.edu with the message body either subscribe imr or unsubscribe imr. Requests to be added or deleted from the IETF list should be sent to ietf-request@ietf.org. Internet Monthly Report availability via WWW, FTP and EMAIL: IMR Retrieval using WWW ----------------------- The URL below may be used in web browsers to access the IMRs. You will see a list of names in the form IMR9706.TXT. For example, IMR9706.TXT is the report for June 1997. URL: ftp://ftp.isi.edu/in-notes/imr IMR Retrieval using EMAIL via the RFC-INFO Service -------------------------------------------------- The EMail retrieval system RFC-Info will send a large report in segments in separate EMail messages not exceeding 50,000 characters each. Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_imrs. For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs IMR Retrieval using FTP ----------------------- IMRs are available via anonymous FTP from FTP.ISI.EDU, with the pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of the IMR. For example IMR9706.TXT is the report for June 1997). Login with FTP username anonymous and password ftp. IMR retrieval using MIME ------------------------ Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retreive the current IMR. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="rfc-info@isi.edu" Content-Type: text/plain Retrieve: imr Doc-ID: imr9706 --OtherAccess Content-Type: Message/External-body; name="imr9706.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes/imr" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa27976; 6 Aug 97 19:09 EDT Received: from gatekeeper.eop.gov by ietf.org id aa27916; 6 Aug 97 19:09 EDT Received: from pmdf.eop.gov by gatekeeper.eop.gov; (5.65v3.2/1.1.8.2/17Oct95-0424PM) id AA16691; Wed, 6 Aug 1997 19:04:28 -0400 Received: from mr.eop.gov by PMDF.EOP.GOV (PMDF V5.0-4 #6879) id <01IM4OXTJ2U8005EP1@PMDF.EOP.GOV> for ietf@ietf.org; Wed, 06 Aug 1997 19:02:57 -0400 (EDT) Received: with PMDF-MR; Wed, 06 Aug 1997 19:02:47 -0400 (EDT) Mr-Received: by mta EOPMRX; Relayed; Wed, 06 Aug 1997 19:02:47 -0400 Alternate-Recipient: prohibited Disclose-Recipients: prohibited Date: Wed, 06 Aug 1997 19:00:00 -0400 (EDT) Sender:ietf-request@ietf.org From: Thomas_A._Kalil@oa.eop.gov Subject: Next Generation Internet To: ietf@ietf.org Message-Id: <01IM4OXV32NQ005EP1@mr.eop.gov> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Ua-Content-Id: MBLINKAA X400-Mts-Identifier: [;74209160807991/153270@EOPMRX] Hop-Count: 1 Source-Info: From (or Sender) name not authenticated. Message Creation Date was at 6-AUG-1997 19:00:00 IETFers might be interested in reading the draft Next Generation Internet implementation plan -- which is at http://www.ccic.gov [or directly at http://www.ccic.gov/ngi/implementation-Jul97/] Comments are welcome -- send them to ngi@ccic.gov. - Tom Kalil The White House kalil_t@a1.eop.gov   Received: from ietf.org by ietf.org id aa00269; 6 Aug 97 20:53 EDT Received: from vcgate3.mei.co.jp by ietf.org id aa00105; 6 Aug 97 20:51 EDT Received: by vcgate3.mei.co.jp (8.6.10h/5.9:4.9:vcgate01:970710) id JAA28754; Thu, 7 Aug 1997 09:45:37 +0900 Sender:ietf-request@ietf.org From: Amos.JEN.Kim.Fei@ams.panasonic.com.sg Received: by vcmei.vanc.mei.co.jp (5.65mei1.1/5.9:4.9:vacation:970805) id AA25363; Thu, 7 Aug 97 09:45:52 +0900 Received: from ccMail by ccsmtp.ams.panasonic.com.sg id AA870968856; Thu, 07 Aug 97 08:45:02 ZE8 Date: Thu, 07 Aug 97 08:45:02 ZE8 Encoding: 0 Text Message-Id: <9708078709.AA870968856@ccsmtp.ams.panasonic.com.sg> To: ietf@ietf.org Return-Receipt-To: Amos.JEN.Kim.Fei@ams.panasonic.com.sg Subject: remove Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa12351; 7 Aug 97 12:00 EDT Received: from ietf.ietf.org by ietf.org id aa12097; 7 Aug 97 11:57 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ids-snqp-01.txt Date: Thu, 07 Aug 1997 11:57:20 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708071157.aa12097@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Directory Services Working Group of the IETF. Title : Simple Nomenclator Query Protocol (SNQP) Author(s) : J. Ordille, J. Elliott Filename : draft-ietf-ids-snqp-01.txt Pages : 30 Date : 1997-08-04 The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. The protocol is useful to services that search many data repositories for query responses. Clients can pose queries on relations, list descriptions of relations, and obtain advice on reducing the search time and cost of their queries. Clients are informed of the age of information in caches, and may request more recent information. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so services can use SNQP with a variety of back-end servers, e.g. relational database servers, CCSO servers, and servers providing relational views of X.500. SNQP is an ASCII protocol in the request-reply style of SMTP. It was specifically designed for use with the Nomenclator name and information service, and has been useful elsewhere. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ids-snqp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ids-snqp-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ids-snqp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970807114501.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ids-snqp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ids-snqp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970807114501.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12341; 7 Aug 97 12:00 EDT Received: from ietf.ietf.org by ietf.org id aa12071; 7 Aug 97 11:57 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: mboned@ns.uoregon.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mboned-pruning-02.txt Date: Thu, 07 Aug 1997 11:57:18 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708071157.aa12071@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MBONE Deployment Working Group of the IETF. Title : Multicast pruning a necessity Author(s) : J. Hawkinson Filename : draft-ietf-mboned-pruning-02.txt Pages : 3 Date : 1997-08-04 This document calls for the MBone to be free of non-pruning multicast as soon as possible, due to the high cost to the Internet of the traffic resulting from them. Consensus is that [DATE 1 month from RFC publication] is the goal date for elimating non-pruning multicast routers. It cites several ways to eliminate non-pruning multicast from a network, allowing per-site flexibility. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mboned-pruning-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-pruning-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mboned-pruning-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970807114700.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mboned-pruning-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mboned-pruning-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970807114700.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12365; 7 Aug 97 12:00 EDT Received: from ietf.ietf.org by ietf.org id aa11587; 7 Aug 97 11:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: mobile-ip@smallworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mobileip-optim-06.txt Date: Thu, 07 Aug 1997 11:40:50 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708071140.aa11587@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Route Optimization in Mobile IP Author(s) : C. Perkins, D. Johnson Filename : draft-ietf-mobileip-optim-06.txt Pages : 44 Date : 1997-08-04 This document defines extensions to the operation of the base Mobile IP protocol to allow for optimization of datagram routing from a correspondent node to a mobile node. Without Route Optimization, all datagrams destined to a mobile node are routed through that mobile node's home agent, which then tunnels each datagram to the mobile node's current location. The protocol extensions described here provide a means for correspondent nodes that implement them to cache the binding of a mobile node and to then tunnel their own datagrams for the mobile node directly to that location, bypassing the possibly lengthy route for each datagram to and from the mobile node's home agent. Extensions are also provided to allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-optim-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-optim-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-optim-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970807112843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-optim-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-optim-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970807112843.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa12882; 8 Aug 97 15:09 EDT Received: from alpha1.Reston.mci.net by ietf.org id aa12668; 8 Aug 97 14:56 EDT Received: from tp7.Jck.com ([206.99.215.42]) by ALPHA1.RESTON.MCI.NET (PMDF V5.1-8 #8388) with SMTP id <01IM78QJQN9W003A03@ALPHA1.RESTON.MCI.NET> for ietf@ietf.org; Fri, 8 Aug 1997 14:51:18 EDT Date: Fri, 08 Aug 1997 14:51:36 -0400 (EDT) Sender:ietf-request@ietf.org From: John C Klensin Subject: Supplement on Munich logistics To: ietf@ietf.org Reply-to: John C Klensin Message-id: MIME-version: 1.0 X-Mailer: Simeon for Win32 Version 4.1.2 Build (22a) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Priority: NORMAL X-Authentication: none Source-Info: From (or Sender) name not authenticated. We know this is late, but for those who can still benefit, Dave Morton and I have teased out a little more info... The following represents very hasty editing of notes he and I sent back and forth, so excuse changes of person, tense, etc. In addition to the shuttle mentioned on the web page, etc., it is possible (and cheaper) to get to the Sheraton and vicinity (actually to almost anywhere in Munich) by public transport. The system is the following (easier than it sounds, but time-consuming)... Try to bring some DM cash with you. The trolleys for a start cost (if Dave remembers correctly) one DM to hire. Note this is *before* you leave customs and immigration/pass control so there are no banks where one can change *until* you are outside - pretty braindamaged but..... Proceed to the Central Area (marked by a Z or Bereich Z). Either use the automatic machine (will be labelled "MVV-Fahrausweise) to obtain tickets or go to the MVV counter if you've no change or no 10/20 DM notes. The machines take DM 10/20 notes as well. * a "single trip" ticket (Einzelfahrkarte) (8 zones) * an unlimited day ticket (Tageskarte). The day ticket is often a better deal if you are going to do anything else on the train system that day. * A Strip ticket (Mehrfahrtenkarte) (15DM. The ride from the airport "costs" 8 strips; you can use the others during the week. The striped ticket is the best best - from the airport to most all hotels they'll need at most to stamp 8 stripes. Those tickets now cost DM 15 for 11 stripes. The other prices you mentioned are old indeed so stick to the stripes solution. There are also partner, 3 day tickets and all sorts of combinations (its not a joke that the SDZ (largest daily newspaper in Germany) once had an article on their satirical page of the Sat. edition offering a 6 day course in understanding the MVV tariff system. The 6th day included a practice session :-) We've a bunch of stuff in English to hand out with all of this info. on it. The first priority will be getting from the airport. * A weekly pass is also a reasonable idea if you are going to be using the system during IETF, but you may find it cheaper to get in from the airport and then obtain an "inner zone" (MVV-Innenraum) weekly pass-- most of the relevant sights, restaurants, etc., are within that area. Correct. There are also partner daily tickets now and partner three day tickets - ask a the MVV desk for information and pricing. If folks are in pairs this is probably the best value. Find the train platform for the "S8" (see below). On the platform, you will find ticket-stamping machines labelled "E". Insert the ticket arrow end first and get it stamped. If you are using a strip-card, fold down the number of zones you are using and stamp the next one. Munich is very nasty about people travelling on the system without properly-stamped tickets, and they do check. There are also stamping machines at the entrace to the escaltor going to to the platform. Take the "S8" train (probably the only one you can find) to the main rail station (Hauptbahnhof). The airport is the end of the line, so there is only one direction. All S8 trains leaving the airport go to the Hauptbahnhof. At the Hauptbahnhof, transfer from the S8 to the U4 (this is two different systems, but they aren't far apart -- follow the signs). Take the U4 toward Arabellapark (the last stop in the northeasterly direction). Get off at the back and take the read (red?) entrance. The Sheraton is not exactly within sight but proceed in the direction of Rosenkavalierplatz and at the Spar supermarket take a right - the Sheraton is 150 m straight ahead of you. Note that the above is the longest way to the Sheraton/Arabella Hotels. Best would be to get off the S8 at Daglfing and get either a bus or a taxi to Arabellapark/Arabellastr. happy travels, john   Received: from ietf.org by ietf.org id aa02191; 9 Aug 97 5:00 EDT Received: from ecrc.de by ietf.org id aa01953; 9 Aug 97 4:42 EDT Received: (qmail 386 invoked from network); 9 Aug 1997 08:31:25 -0000 Received: from scorpio.ecrc.de (141.1.4.100) by ecrc.de with SMTP; 9 Aug 1997 08:31:25 -0000 Received: from acrab25.ecrc.de (acrab25.ecrc.de [141.1.6.125]) by scorpio.ecrc.de (8.8.3/8.8.4/$Revision: 1.4 $) with ESMTP id KAA08309; Sat, 9 Aug 1997 10:31:24 +0200 (MET DST) Sender:ietf-request@ietf.org From: Dave Morton Received: (from dave@localhost) by acrab25.ecrc.de (8.8.2/8.8.2/$Revision: 1.1 $) id KAA24714; Sat, 9 Aug 1997 10:31:22 +0200 (MET DST) Date: Sat, 9 Aug 1997 10:31:22 +0200 (MET DST) Message-Id: <199708090831.KAA24714@acrab25.ecrc.de> To: ietf@ietf.org, klensin@mci.net Subject: Re: Supplement on Munich logistics Source-Info: From (or Sender) name not authenticated. >At the Hauptbahnhof, transfer from the S8 to the U4 (this >is two different systems, but they aren't far apart -- >follow the signs). Take the U4 toward Arabellapark (the >last stop in the northeasterly direction). > >Get off at the back and take the read (red?) entrance. The rear entrance.... (Thanks John). Dave   Received: from ietf.org by ietf.org id aa05755; 9 Aug 97 10:18 EDT Received: from milo.cfw.com by ietf.org id aa05681; 9 Aug 97 10:14 EDT Received: from RA26wb12.cfw.com by milo.cfw.com; (5.65v3.2/1.1.8.2/12Dec95-0403PM) id AA24129; Sat, 9 Aug 1997 10:11:05 -0400 X-Sender: unit@box.nl (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 9 Aug 1997 10:09:20 -0500 To: ietf@ietf.org Sender:ietf-request@ietf.org From: michael_roetto Subject: Internet Governance Cc: gtld-discuss@gtld-mou.org Source-Info: From (or Sender) name not authenticated. An interesting thought struck me when reading about the brew-ha-ha over the gTLD-MoU. Clearly, the Internet is becoming a political matter. That means not only are politicians now aware of the net, but the discussion within the technical community itself is now largely taking place in political terms. Witness the fight over the domain-name space as an example of this. If this 'politicization' continues can anything but DNS fragmentation result? My thought is this: in our system of government it is accepted that the military (another potent force) should be subject to civilian oversight. Would the Internet community also be willing to accept 'civilian' oversight in order to avert the DNS crisis? i.e., benevolent oversight from outside the technical community? Does the new POC really represent all the stakeholders in the DNS and the larger governance debate? (I don't buy the argument that the gTLD-MoU is purely an operational concern) Would some combination of technical and non-technical oversight better provide for the future of the network? Maybe if governance and operational issues were de-linked and delegated to the proper organizations, the Internet could progress in a more controlled fashion. -michael ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tube Based Media - www.box.nl/~unit/tbm Personal Page - www.box.nl/~unit/mike e-mail - tbm@box.nl *internet consultancy & web designs* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   Received: from ietf.org by ietf.org id aa06212; 9 Aug 97 10:57 EDT Received: from newdev.harvard.edu by ietf.org id aa06164; 9 Aug 97 10:56 EDT Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id KAA03067; Sat, 9 Aug 1997 10:50:59 -0400 (EDT) Date: Sat, 9 Aug 1997 10:50:59 -0400 (EDT) Sender:ietf-request@ietf.org From: Scott Bradner Message-Id: <199708091450.KAA03067@newdev.harvard.edu> To: ietf@ietf.org, mike@box.nl Subject: Re: Internet Governance Cc: gtld-discuss@gtld-mou.org Source-Info: From (or Sender) name not authenticated. > Would the Internet community also be willing to accept 'civilian' oversight just for my info - what would be the "right" international 'civilian' oversight group? Scott   Received: from ietf.org by ietf.org id aa07419; 9 Aug 97 12:20 EDT Received: from dfw-ix12.ix.netcom.com by ietf.org id aa07344; 9 Aug 97 12:17 EDT Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id LAA11016; Sat, 9 Aug 1997 11:12:11 -0500 (CDT) Received: from kcx-ks6-02.ix.netcom.com(204.30.70.194) by dfw-ix12.ix.netcom.com via smap (V1.3) id sma010947; Sat Aug 9 11:11:59 1997 Message-ID: <33EC40CB.1450@ix.netcom.com> Date: Sat, 09 Aug 1997 11:04:59 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: michael_roetto CC: ietf@ietf.org, gtld-discuss@gtld-mou.org Subject: Re: Internet Governance References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Michael and all, Good points here. I wonder what Rick Wesson's view is here. But I suppose he will say the same thing to you as he has others. You don't have a stake in these issues. This would be a typical response from him. It is such a dam shame! :( But I like your points here. They have been made in diffrent terms several times befor however, to little avail. michael_roetto wrote: > > An interesting thought struck me when reading about the brew-ha-ha over > the gTLD-MoU. Clearly, the Internet is becoming a political matter. That > means not only are politicians now aware of the net, but the discussion > within the technical community itself is now largely taking place in > political terms. Witness the fight over the domain-name space as an > example of this. > > If this 'politicization' continues can anything but DNS fragmentation result? > > My thought is this: in our system of government it is accepted that the > military (another potent force) should be subject to civilian oversight. > Would the Internet community also be willing to accept 'civilian' oversight > in order to avert the DNS crisis? i.e., benevolent oversight from outside > the technical community? > > Does the new POC really represent all the stakeholders in the DNS and the > larger governance debate? (I don't buy the argument that the gTLD-MoU is > purely an operational concern) Would some combination of technical and > non-technical oversight better provide for the future of the network? Maybe > if governance and operational issues were de-linked and delegated to the > proper organizations, the Internet could progress in a more controlled > fashion. > > -michael > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Tube Based Media - www.box.nl/~unit/tbm > Personal Page - www.box.nl/~unit/mike > e-mail - tbm@box.nl > *internet consultancy & web designs* > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa11165; 9 Aug 97 16:37 EDT Received: from sigma.itu.ch by ietf.org id aa11093; 9 Aug 97 16:34 EDT Received: from ties.itu.ch (ties.itu.ch) by ITU.CH (PMDF V5.0-6 #16074) id <01IM930JK1LG9X3NYQ@ITU.CH>; Sat, 09 Aug 1997 22:29:08 +0200 Received: from ibm560 (dlpy40b.itu.ch [156.106.192.161]) by ties.itu.ch (8.8.5/8.8.5) with ESMTP id WAA19951; Sat, 09 Aug 1997 22:29:10 +0200 (MET DST) Date: Sat, 09 Aug 1997 22:26:13 +0200 Sender:ietf-request@ietf.org From: Robert Shaw Subject: Re: Internet Governance To: michael_roetto Cc: ietf@ietf.org, gtld-discuss@gtld-mou.org Message-id: <33ECD265.39F82A6C@itu.int> Organization: ITU MIME-version: 1.0 X-Mailer: Mozilla 4.01 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Priority: 3 (Normal) References: Source-Info: From (or Sender) name not authenticated. michael_roetto wrote: > > An interesting thought struck me when reading about the brew-ha-ha over > the gTLD-MoU. Clearly, the Internet is becoming a political matter. That > means not only are politicians now aware of the net, but the discussion > within the technical community itself is now largely taking place in > political terms. Witness the fight over the domain-name space as an > example of this. > Michael, First I should say I'm loath to cc: the IETF list who are probably totally fed up with hearing about this topic. Out of respect for those who certainly have more important things to do, I'll make this only one post to the main IETF mailing list on this topic. Anyway, your take that the DNS administration issues are totally politicized is right on the mark. The IAHC/iPOC has traveled incessantly during the last 10 months speaking with dozens of regulatory bodies, major companies, government bodies, etc - technology is almost never a topic (although this has changed recently since the gTLD registrar selection process has started and folks have realized that this is actually going to happen). For those interested, see www.gtld-mou.org. Unfortunately, the desire for commercial control over parts of the Internet name space has driven much of the debate. As any 2-year old can tell you, sharing is not part of human nature. But the IAHC strongly believed that this was fundamentally the right approach drawing its conclusions from other parallels such as 800 numbers in the US and the example of national registries such as in the UK where there are over *375 registrars* for .uk. Sharing avoids the problems of private ownership, and arguably private abuse of the Internet TLD name space. It offers domain name portability for users so registrars must compete on price and service and not because they have a lock on a valuable TLD. We have tried to put into place a set of checks and balances that seek to promote the principle of open and fair competition while preserving stability. We have tried to develop an equitable system for the protection of intellectual property rights but also respecting the rights of domain name holders. Since *both* domain name holders and trademark holders don't like it, I'll take that to mean that we are finding the middle road. > If this 'politicization' continues can anything but DNS fragmentation result? > The DNS will not fragment. The major governmental and industry forces now involved will assure (through regulatory intervention) that this will *not happen*. You might as well argue that the global telephone numbering system could fragment. The Net is so strategic for electronic commerce and DNS identifiers are such an integral part of commerce, this will simply not be tolerated. And here we find an irony - those who can only see their own commercial self-interest think that governmental intervention will somehow weigh in on their side - with all due respect, keep dreaming. In every conversation with governmental, industry and regulatory agency, I have seen 0% support for private ownership of the TLD name space. > Does the new POC really represent all the stakeholders in the DNS and the > larger governance debate? (I don't buy the argument that the gTLD-MoU is > purely an operational concern) Would some combination of technical and We don't buy the argument either. The gTLD-MoU includes both policy and operational issues but puts the operational issues squarely in the realm of CORE where it belongs. We have attempted to provide representation of many stakeholders through the gTLD-Mou Policy Advisory Body and after CORE is firmly established, I expect the PAB to evolve more fully in its role. Concerning your comments on the makeup of the POC - you are absolutely right. Of course, it does not represent all stakeholders in the DNS. We know it. Everybody knows it. But the challenge for you or any critic is to move from the general desire to a specific proposal. How do you define a real working committee with quote/unquote "all stakeholders represented" without having the mother of all committees? Heck, every week, we flush out a new "stakeholder body". We admit we haven't solve this problem -- and we admit we've punted on the issue. We have spent hundreds of hours debating this topic with no resolution. In any case, we're going to go through a public request for comments on this issue and maybe there are some greater minds than ours who can suggest a solution. > non-technical oversight better provide for the future of the network? Maybe > if governance and operational issues were de-linked and delegated to the > proper organizations, the Internet could progress in a more controlled > fashion. On the surface, sounds wonderful but the problem is, from our experience, nobody agrees on what are the *proper organizations*. Bob   Received: from ietf.org by ietf.org id aa11851; 9 Aug 97 17:31 EDT Received: from dfw-ix6.ix.netcom.com by ietf.org id aa11797; 9 Aug 97 17:29 EDT Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id QAA21860; Sat, 9 Aug 1997 16:24:45 -0500 (CDT) Received: from kcx-ks9-57.ix.netcom.com(198.211.69.121) by dfw-ix6.ix.netcom.com via smap (V1.3) id sma021843; Sat Aug 9 16:24:42 1997 Message-ID: <33EC8ABF.6BC8@ix.netcom.com> Date: Sat, 09 Aug 1997 16:20:31 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Robert Shaw CC: michael_roetto , ietf@ietf.org, gtld-discuss@gtld-mou.org Subject: Re: Internet Governance References: <33ECD265.39F82A6C@itu.int> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Robert, Robert Shaw wrote: > > michael_roetto wrote: > > > > An interesting thought struck me when reading about the brew-ha-ha over > > the gTLD-MoU. Clearly, the Internet is becoming a political matter. That > > means not only are politicians now aware of the net, but the discussion > > within the technical community itself is now largely taking place in > > political terms. Witness the fight over the domain-name space as an > > example of this. > > > > Michael, > > First I should say I'm loath to cc: the IETF list who are probably > totally fed up with hearing about this topic. Out of respect for those who > certainly have more important things to do, I'll make this only one post to > the main IETF mailing list on this topic. I am not sure why you loath the cc: to the IETF list, but that is of little matter in the grander scope of things I feel. > > Anyway, your take that the DNS administration issues are totally politicized > is right on the mark. The IAHC/iPOC has traveled incessantly during the > last 10 months speaking with dozens of regulatory bodies, major companies, > government bodies, etc - technology is almost never a topic (although this > has changed recently since the gTLD registrar selection process has started > and folks have realized that this is actually going to happen). For those > interested, see www.gtld-mou.org. I believe that it will happen as well, but not under the current draft of the gTLD-MoU. All be it a good start. Much work is yet to be done. Getting a working root up and running is just one very important one. Without inclusion of ALL stake holders, that current MoU will not prevail. > > Unfortunately, the desire for commercial control over parts of the Internet > name space has driven much of the debate. As any 2-year old can tell you, sharing > is not part of human nature. But the IAHC strongly believed that this was > fundamentally the right approach drawing its conclusions from other parallels > such as 800 numbers in the US and the example of national registries such as > in the UK where there are over *375 registrars* for .uk. I agree that sharing is necessary for their to be continuity within the root structure, I don't agree that all TLD's must be shared in the manner that the gTLD-MoU suggests or requires. Some can be managed independantly but shared within the root server structure. > > Sharing avoids the problems of private ownership, and arguably private abuse > of the Internet TLD name space. It offers domain name portability for users > so registrars must compete on price and service and not because they have a > lock on a valuable TLD. We have tried to put into place a set of checks and > balances that seek to promote the principle of open and fair competition while > preserving stability. We have tried to develop an equitable system for the > protection of intellectual property rights but also respecting the rights of > domain name holders. Since *both* domain name holders and trademark holders > don't like it, I'll take that to mean that we are finding the middle road. Private ownership of some specilized TLD's like .US. and .gov, can be managed withing a shared root structure. The managment of those type, and other possible TLD's within a shared structure is definatly possible. I don't fine the argument oaf a totaly shared root structure valid for that reason. Yet I applaud the efforts of many towards a shared root structure. > > > If this 'politicization' continues can anything but DNS fragmentation result? > > > > The DNS will not fragment. The major governmental and industry forces now > involved will assure (through regulatory intervention) that this will *not > happen*. You might as well argue that the global telephone numbering system > could fragment. The Net is so strategic for electronic commerce and DNS > identifiers are such an integral part of commerce, this will simply not be > tolerated. And here we find an irony - those who can only see their own commercial > self-interest think that governmental intervention will somehow weigh in on > their side - with all due respect, keep dreaming. In every conversation with > governmental, industry and regulatory agency, I have seen 0% support for > private ownership of the TLD name space. > > > Does the new POC really represent all the stakeholders in the DNS and the > > larger governance debate? (I don't buy the argument that the gTLD-MoU is > > purely an operational concern) Would some combination of technical and > > We don't buy the argument either. The gTLD-MoU includes both policy and > operational issues but puts the operational issues squarely in the realm of > CORE where it belongs. We have attempted to provide representation of many > stakeholders through the gTLD-Mou Policy Advisory Body and after CORE is > firmly established, I expect the PAB to evolve more fully in its role. > > Concerning your comments on the makeup of the POC - you are absolutely right. > Of course, it does not represent all stakeholders in the DNS. We know it. > Everybody knows it. But the challenge for you or any critic is to move from > the general desire to a specific proposal. How do you define a real working > committee with quote/unquote "all stakeholders represented" without having > the mother of all committees? Heck, every week, we flush out a new > "stakeholder body". We admit we haven't solve this problem -- and we admit > we've punted on the issue. We have spent hundreds of hours debating this topic > with no resolution. In any case, we're going to go through a public request for > comments on this issue and maybe there are some greater minds than ours who > can suggest a solution. Yes POC doesn't represent all the stakeholders but it easly can. I have outlined several times several diffrent methods that could be explored to achieve this. But with the current political structure, it has been made much more difficult to do so. Hence the orgnizational structure must change, along with the responsibilities of PAB/POC/CORE in your vision for ALL stakeholders to participate on an equal footing. > > > non-technical oversight better provide for the future of the network? Maybe > > if governance and operational issues were de-linked and delegated to the > > proper organizations, the Internet could progress in a more controlled > > fashion. > > On the surface, sounds wonderful but the problem is, from our experience, nobody > agrees on what are the *proper organizations*. How true! > > Bob Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa20712; 9 Aug 97 23:03 EDT Received: from ginger.lcs.mit.edu by ietf.org id aa18305; 9 Aug 97 23:00 EDT Received: by ginger.lcs.mit.edu id AA05467; Sat, 9 Aug 97 22:55:09 -0400 Date: Sat, 9 Aug 97 22:55:09 -0400 Sender:ietf-request@ietf.org From: Noel Chiappa Message-Id: <9708100255.AA05467@ginger.lcs.mit.edu> To: jwkckid1@ix.netcom.com, robert.shaw@itu.int Subject: Re: Internet Governance Cc: ietf@ietf.org, jnc@ginger.lcs.mit.edu Source-Info: From (or Sender) name not authenticated. From: Jeff Williams > Robert Shaw wrote: > > First I should say I'm loath to cc: the IETF list who are probably > totally fed up with hearing about this topic. I am not sure why you loath the cc: to the IETF list Because we're tired of hearing critics, often self-appointed public-interest mavens, flame witlessly about policy issues - issues which usually only exist because of the myopic self-interest all too apparent in some quarters. > Out of respect for those who certainly have more important things to > do, I'll make this only one post to the main IETF mailing list on this > topic. Thank you. Noel   Received: from ietf.org by ietf.org id aa04175; 10 Aug 97 7:00 EDT Received: from bells.cs.ucl.ac.uk by ietf.org id aa03876; 10 Aug 97 6:41 EDT Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 10 Aug 1997 11:35:14 +0100 To: Noel Chiappa cc: ietf@ietf.org Subject: Re: Internet Governance In-reply-to: Your message of "Sat, 09 Aug 1997 22:55:09 EDT." <9708100255.AA05467@ginger.lcs.mit.edu> Date: Sun, 10 Aug 1997 11:35:14 +0100 Message-ID: <2381.871209314@cs.ucl.ac.uk> Sender:ietf-request@ietf.org From: Jon Crowcroft Source-Info: From (or Sender) name not authenticated. few observations on the namespace 1/ there is no inherent value in the name space - but it is essential infastructure - a key difference between US and European attitudes to the role of those looking after the name space is that the US have parties to whom it is culturally accepted to (try to) make money out of something like this (or make law suits out of it) where in europe we just get on with running things like this as a government service or at least not for profit quango in general - while this is not the precise sate of affairs with respect to DNS in europe, i feel it represents most attitudes commonly this side of the pond (i won't dare to say elsewhere too:-) - it is unseemly, basically, to make money out such an essential, but essentially marginal business.... 2/ another cultural divide (abyss) is that between the Internet Community, and the treaty organisations normally assigned these types of roles (e.g. ITU, Intl. Trademark and Copyright and Patent orgs. etc) - the lack of _trust_ (largely one way now: of the ITU, by the IETF) fuels the lack of solution.....this is, however, a improving situation.... hey maybe isoc could become a UN offshoot too.....? personally, the sooner webtv and other technology makes URLs and their embedded DNS names vanish behind clickable icons, the sooner people will stop seeing a way to make a fast buck out of registering "bowing.com" and "nicrosoft.com" and selling them at a profit to the first sucker.....its all such a sad waste of resource (as is this email:-) cheers jon   Received: from ietf.org by ietf.org id aa10051; 10 Aug 97 14:23 EDT Received: from merit.edu by ietf.org id aa09984; 10 Aug 97 14:19 EDT Received: from Bill.Simpson.DialUp.Mich.Net (pm002-21.dialip.mich.net [141.211.7.157]) by merit.edu (8.8.6/8.8.5) with SMTP id OAA25378; Sun, 10 Aug 1997 14:15:13 -0400 (EDT) Date: Sun, 10 Aug 97 17:14:41 GMT Sender:ietf-request@ietf.org From: William Allen Simpson Message-ID: <6430.wsimpson@greendragon.com> To: ietf@ietf.org CC: gtld-discuss@gtld-mou.org Subject: Re: Internet Governance Source-Info: From (or Sender) name not authenticated. > From: Jeff Williams > I am not sure why you loath the cc: to the IETF list, but that is of > little matter in the grander scope of things I feel. Because the IETF list is about governing the IETF (and to a certain extent, the IAB and IRTF), not the Internet. Because the DNS is not the Internet, it is only one small part of the technical and operational problems of the Internet. Because we have already appointed very capable representatives to the IAHC nee PoC, who individually showed dedication, honor and integrity, and made one of the most incredible personal sacrifices of any effort that I have seen in a decade of Internet experience. Because, even while we may disagree with some of the specific results, we know and trust our representatives, and are profoundly grateful that they took up the burden on our behalf. Because we know enough not to trust anyone who clearly doesn't yet have a clue about the tao of the IETF. Because we hate clueless off-topic multi-list posting. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from ietf.org by ietf.org id aa11461; 10 Aug 97 16:06 EDT Received: from dfw-ix4.ix.netcom.com by ietf.org id aa11389; 10 Aug 97 16:04 EDT Received: (from smap@localhost) by dfw-ix4.ix.netcom.com (8.8.4/8.8.4) id OAA11482; Sun, 10 Aug 1997 14:59:23 -0500 (CDT) Received: from kcx-ks4-04.ix.netcom.com(204.30.70.132) by dfw-ix4.ix.netcom.com via smap (V1.3) id sma011475; Sun Aug 10 14:59:06 1997 Message-ID: <33EDC828.19C3@ix.netcom.com> Date: Sun, 10 Aug 1997 14:54:48 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: William Allen Simpson CC: ietf@ietf.org, gtld-discuss@gtld-mou.org Subject: Re: Internet Governance References: <6430.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. William, William Allen Simpson wrote: > > > From: Jeff Williams > > I am not sure why you loath the cc: to the IETF list, but that is of > > little matter in the grander scope of things I feel. > > Because the IETF list is about governing the IETF (and to a certain > extent, the IAB and IRTF), not the Internet. This does not seem to be a very good resaon in my mind. In that the IETF has and is considered widely as one of the influencing bodies in governing to some extent the Internet, I find this somewhat puzzeling as one of your or the IETF's answers to my query. > > Because the DNS is not the Internet, it is only one small part of the > technical and operational problems of the Internet. Small? That seems a bit of an understatment. It is a KEY area or the operational structure of the internet. > > Because we have already appointed very capable representatives to the > IAHC nee PoC, who individually showed dedication, honor and integrity, > and made one of the most incredible personal sacrifices of any effort > that I have seen in a decade of Internet experience. Very likely so. Seems that this is a reason TO have this posted to the IETF list, rather than otherwise. " Awarness is a step to knowledge and understanding." Lao Tzu. > > Because, even while we may disagree with some of the specific results, > we know and trust our representatives, and are profoundly grateful that > they took up the burden on our behalf. > > Because we know enough not to trust anyone who clearly doesn't yet have > a clue about the tao of the IETF. Surely you are not refering to myself here? If so, I beg your pardon. > > Because we hate clueless off-topic multi-list posting. Well I guess I could take this as an insult. But I won't. I just have to assume that becouse you do not know me, you have just made a judgment error. And anyone can do that I suppose. >;) > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa15337; 11 Aug 97 18:04 EDT Received: from door.netcs.com by ietf.org id aa15089; 11 Aug 97 17:46 EDT Received: from held.netcs.com [138.199.16.50] by door.NetCS.COM with SMTP (8.6.10/25-eef) id XAA23226; Mon, 11 Aug 1997 23:41:58 +0200 Date: Mon, 11 Aug 1997 23:41:53 +0200 (CDT) Sender:ietf-request@ietf.org From: Clemens Schrimpe To: ietf@ietf.org Subject: Re: sms gateway In-Reply-To: <33EF47E2.794B@ietf.org> Message-ID: X-X-Sender: csch@denk.netcs.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. <> ich habe einen dummen Fehler in mein .forward file gebaut woraufhin <> jetzt gerade ca. 800 Mails an +491729021563 auf euer gateway <> gingen - mit identischem Inhalt... <> <> Koenntest Du die wieder aus der Queue loeschen? Keine Sorge, bei 100 ist eh' Schluss (da haben wir im Moment das Limit gesetzt). Gruss, Clemens -- Clemens Schrimpe - NetCS Mobile Communications Group (NMCG) Katharinenstr. 17-18, D-10711 Berlin - GERMANY EMail: Clemens.Schrimpe@NetCS.COM Fax: +49.30/89660-999 Tel: +49.30/89660-0   Received: from ietf.org by ietf.org id aa05066; 12 Aug 97 8:16 EDT Received: from mail1.eni.net by ietf.org id aa04807; 12 Aug 97 8:00 EDT Received: from home.babyg.com ([206.135.5.132]) by mail1.eni.net (8.7.5/8.7.3) with ESMTP id EAA12195 for ; Tue, 12 Aug 1997 04:56:08 -0700 (PDT) Message-Id: <199708121156.EAA12195@mail1.eni.net> Sender:ietf-request@ietf.org From: James Gorman To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: Re: job Date: Tue, 12 Aug 1997 07:58:18 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. NO WAY!!!! ---------- > From: ietf@ietf.org > To: jgorman@eni.net > Subject: job > Date: Tuesday, August 12, 1997 3:52 AM > > find me a job in england. now!   Received: from ietf.org by ietf.org id aa07386; 12 Aug 97 10:41 EDT Received: from mail1.eni.net by ietf.org id aa07273; 12 Aug 97 10:37 EDT Received: from toni.eni.net (firewall-user@chastity.eni.net [206.135.49.2]) by mail1.eni.net (8.7.5/8.7.3) with SMTP id HAA03212 for ; Tue, 12 Aug 1997 07:32:54 -0700 (PDT) Received: by toni.eni.net with Microsoft Mail id <01BCA6F1.8E5CB220@toni.eni.net>; Tue, 12 Aug 1997 07:30:06 -0700 Message-ID: <01BCA6F1.8E5CB220@toni.eni.net> Sender:ietf-request@ietf.org From: Toni Czechorsky To: "'ietf@ietf.org'" Subject: Kitty Sitting Date: Tue, 12 Aug 1997 07:30:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Source-Info: From (or Sender) name not authenticated. =09 Hey There Brad! Guess what! I beat you too it! I actually had visited Kitty on Sunday = to make sure she was ok. I took her some half and half as a treat to = "make friends" (I know you said she was gaining weight but I couldn't = resist). She came down from upstairs (I guess she was at Jan's, but I = didn't see him?) And she drank some and then sat on my lap for an hour = telling how much she missed you.................I was planning on = watering Wed. since you watered Thurs. of last week. I noticed you left = quite a few lights on??? I didn't turn any off? Do you want them to = remain on (and the radio too)?? Went to the beach Sunday night on my way out and it was = glorious..........I had worked all day Sat (Epoch die hard) so it was = nice to relax...................It was pretty windy and overcast, just = the way I like it! Not that many people around. I will probably check on things Friday too and every few days after = that. Are you coming back on a Friday (the 22nd?)=20 Hope all is well and that you are having a GREAT time Toni ---------- From: ietf@ietf.org[SMTP:ietf@ietf.org] Sent: Monday, August 11, 1997 11:54 PM To: Toni Czechorsky Subject: Re: Sea Faring friend hey there. you probably have not been by the house. No=20 problem. let me know how cat is doing when you get a chance. Plants are easily replaced. checked into my hotel here. they put me in a suburb area way=20 out from town. the hotel was a poor attempt at a US style=20 hotel. Small rooms, expensive. I moved out after one night. I took the metro downtown and now am staying at a place right in the center of old munich. I have to take the metro back to get to the conference, but who cares. Downtown is nice, execpt the all speak german. and all they drink is beer. The beer is damn good, but I like a=20 little wine too.=20 gotta go. brad   Received: from cnri by ietf.org id aa11752; 13 Aug 97 15:40 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA03430; Wed, 13 Aug 1997 15:38:50 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id NAA07795 for cat-ietf-redist; Wed, 13 Aug 1997 13:22:52 -0400 (EDT) Message-Id: <199708131722.AA21652@world.std.com> To: cat-ietf@mit.edu, jis@mit.edu Cc: linn@world.std.com Subject: "One-paragraph" summary, CAT WG Munich meeting Date: Wed, 13 Aug 1997 13:22:41 -0400 From: John Linn Precedence: bulk "One-paragraph" summary, Common Authentication Technology (CAT) meeting, Munich IETF, 13 August 1997; full minutes to follow. The CAT WG met for one session at the Munich IETF. Status of several ongoing work items was discussed. FTP Security is reportedly to be considered for Proposed Standard status at the next IESG meeting. Re GSS-V2, the proposed approach is to integrate the RFC2078bis changes list into an updated GSS-V2 base Internet-Draft during September, and then (following a WG Last-Call period) to submit the resulting RFC2078bis and the GSS C bindings as an aligned set to the IESG, requesting their advancement to Proposed Standards; this proposed approach was acceptable to session attendees. Marc Horowitz (Cygnus) and Bill Sommerfeld (HP) indicated a position that draft-ietf-cat-snego-06 does not reflect previously established WG consensus in certain areas, and are to detail the specifics of their dissent to the WG list during the IETF meeting week. William Nace (NSA) presented the recently-distributed FTP and DSA, KEA/Skipjack documents (targeted for informational status), draft-ietf-cat-ftpdsaauth-00-txt and draft-ietf-cat-ftpkeaskj-00.txt. Brian Tung (ISI) presented and discussed the recently-revised kerberos-pk-init and kerberos-pk-cross drafts, and Cliff Neuman (ISI) discussed status and issues relative to the Kerberos RFC1510bis document, draft-ietf-cat-kerberos-revisions-00. John Linn led discussion on some specific issues related to RFC2078bis and RFC1964, and Mike Swift (Microsoft) proposed additional work items, relevant to RFC1964, in areas of user-user authentication and login via access servers. --jl   Received: from ietf.org by ietf.org id aa12423; 13 Aug 97 16:20 EDT Received: from [199.190.211.2] by ietf.org id aa12178; 13 Aug 97 16:05 EDT Received: from mktg (smtp.premisys.com [199.190.212.10]) by vader.premisys.com (8.6.9/8.6.9) with SMTP id NAA18811 for ; Wed, 13 Aug 1997 13:05:48 -0700 Sender:ietf-request@ietf.org From: Harley Frazee X-Orig-Sender: Harley.Frazee@smtp.premisys.com To: ietf@ietf.org Date: Wed, 13 Aug 1997 13:00:10 -0700 Subject: Better Clarity on SNMP error responses Message-ID: Organization: Premisys Communications MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: X-Gateway: NASTA Gate 1.18 for FirstClass(R) Source-Info: From (or Sender) name not authenticated. Hey out there, We have a problem with the limited number of errors that are available to an SNMP set request. To solve our problem, we added an extra MIB variable to our enterprise specific MIB which when included in a standard set request will return a meaningful error code. It is my understanding from reading the rfc's that the values in a "varbind" in the set request cannot be changed in the get response. That means that we legally could not return a different value in the set request to specify a more meaningful error code. Has anyone out these had a similar problem? Is it legal to return a different value in a get response from the set request? Thanks for your help, Harley Frazee Premisys Communications, Inc. harley@premisys.com   Received: from cnri by ietf.org id aa13320; 13 Aug 97 17:25 EDT Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA03848 for ; Wed, 13 Aug 1997 17:24:19 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.7) id PAA11737 for telnet-ietf-list@bsdi.com; Wed, 13 Aug 1997 15:19:18 -0600 (MDT) Received: from bichon.cisco.com (bichon.cisco.com [171.69.1.209]) by services.BSDI.COM (8.8.7/8.8.7) with SMTP id PAA11734 for ; Wed, 13 Aug 1997 15:19:17 -0600 (MDT) Received: from gclark-pc.cisco.com ([198.92.55.57]) by bichon.cisco.com (8.6.12/8.6.5) with SMTP id OAA21770; Wed, 13 Aug 1997 14:18:06 -0700 Message-Id: <3.0.32.19970813141444.0074ae54@bichon.cisco.com> X-Sender: gclark@bichon.cisco.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 13 Aug 1997 14:14:49 -0700 To: Keith Moore , Glen Clark From: Glen Clark Subject: Re: which option to control telnet-accessable serial port? Cc: Keith Moore , telnet-ietf@bsdi.com, Harald Alvestrand , rab@stallion.oz.au, mmonday@cisco.com, swang@cisco.com Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Keith, Has there been any updates on this situation? Have you received any input from you mailing list? If there is anything I can do to help move the process forward, I am, as always, willing to help. Sincerely, Glen Clark Cisco Systems, Inc. At 05:33 PM 7/22/97 -0400, Keith Moore wrote: >Okay, but I'm still interested in opinions from this mailing list, of >the relative merits of the two telnet serial port specifications. > >thanks, > >Keith > >(and will someone please add Glen to the list? thanks!) > >Glen Clark writes: > >> As I stated in my previous mail, until I better understand the >> proceedure I would suggest both drafts be left experimental. >> >> I am especially interested in this course since I am not able to >> register myself to the alias which the call for consensus would >> be made. Keith's suggestion has not produced any notification, >> and my attempts to ask others in the IETF and Internic have not >> been responded to. >> >> Until such time as my interests and the interests of the OEM's which >> already have the Telnet Com Port Control Option in the field can be >> represented I feel it is more appropriate that both drafts be left >> as experimental. > > > > ffff,0000,0000C I S C O S Y S T E M S Glen Clark - Software Engineer 0000,8080,8080 || || Mojave Project 0000,8080,8080 || || glenc@cisco.com 0000,8080,8080 |||| |||| glenc@airnote.net 0000,8080,8080 |||||| |||||| Understanding through Communications   Received: from ietf.org by ietf.org id aa13482; 13 Aug 97 17:34 EDT Received: from relay1.smtp.psi.net by ietf.org id aa13386; 13 Aug 97 17:30 EDT Received: from nips.acec.com by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id RAA21912; Wed, 13 Aug 1997 17:25:44 -0400 (EDT) Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA27123; Wed, 13 Aug 1997 17:25:19 -0400 Message-Id: <3.0.1.32.19970813172750.0094dac0@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 13 Aug 1997 17:27:50 -0400 To: Harley Frazee Sender:ietf-request@ietf.org From: Bob Natale Subject: Re: Better Clarity on SNMP error responses Cc: ietf@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. >At 01:00 PM 8/13/97 -0700, Harley Frazee wrote: Hi Harley, >Hey out there, [If further follow-up is needed, I suggest you post it to snmpv2@tis.com, rather than the main IETF list.] >We have a problem with the limited number of errors that >are available to an SNMP set request. Are you referring to SNMPv1 or SNMPv2c? If the former, note that 13 new error codes were added in SNMPv2c, mostly for the benefit of reporting SetRequest errors. Here's the list from the WinSNMP API header file: // SNMP Error Codes Returned in Error_status Field of PDU // (these are NOT WinSNMP API Error Codes) // Error Codes Common to SNMPv1 and SNMPv2 #define SNMP_ERROR_NOERROR 0 #define SNMP_ERROR_TOOBIG 1 #define SNMP_ERROR_NOSUCHNAME 2 #define SNMP_ERROR_BADVALUE 3 #define SNMP_ERROR_READONLY 4 #define SNMP_ERROR_GENERR 5 // Error Codes Added for SNMPv2 #define SNMP_ERROR_NOACCESS 6 #define SNMP_ERROR_WRONGTYPE 7 #define SNMP_ERROR_WRONGLENGTH 8 #define SNMP_ERROR_WRONGENCODING 9 #define SNMP_ERROR_WRONGVALUE 10 #define SNMP_ERROR_NOCREATION 11 #define SNMP_ERROR_INCONSISTENTVALUE 12 #define SNMP_ERROR_RESOURCEUNAVAILABLE 13 #define SNMP_ERROR_COMMITFAILED 14 #define SNMP_ERROR_UNDOFAILED 15 #define SNMP_ERROR_AUTHORIZATIONERROR 16 #define SNMP_ERROR_NOTWRITABLE 17 #define SNMP_ERROR_INCONSISTENTNAME 18 If you find the full current list inadequate for your needs, please explain (on the snmpv2@tis.com list) what you need. >To solve our problem, we added an extra MIB variable to >our enterprise specific MIB which when included in a >standard set request will return a meaningful error >code. This is not an uncommon idea...except that the "extra MIB variable[s]" should be accessed via a GetRequest following a failed SetRequest. >It is my understanding from reading the rfc's that the >values in a "varbind" in the set request cannot be changed >in the get response. That means that we legally could >not return a different value in the set request to specify >a more meaningful error code. Right (actually, I'd have to check to see whether it's legal to use the new SNMPv2c varbind exception codes... but I doubt that it is). >Has anyone out these had a similar problem? Yes. I think that the new SNMPv2c error codes addressed many of the traditional needs in this area and the use of "extended error code" MIB variables--via subsequent GetRequest PDUs--is also used in some cases. >Is it legal to return a different value in a get >response from the set request? No. Cordially, BobN ----- ISO 9001 Registered Hardware and Software Divsions ---- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------   Received: from ietf.org by ietf.org id aa14319; 13 Aug 97 18:26 EDT Received: from wireless-229.ietf.de by ietf.org id aa14274; 13 Aug 97 18:25 EDT Received: (from tytso@localhost) by rsts-11.mit.edu (8.8.5/8.8.5) id SAA00430; Wed, 13 Aug 1997 18:17:35 -0400 Date: Wed, 13 Aug 1997 18:17:35 -0400 Message-Id: <199708132217.SAA00430@rsts-11.mit.edu> To: ietf@ietf.org Subject: PGP Keyring from the IETF Key Signing event Sender:ietf-request@ietf.org From: tytso@mit.edu Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. The PGP Keyring for the IETF Key Signing party has been double checked. (There was some question about whether it was correct, but that was apparently caused by someone downloading the keyring in ASCII mode.) As reminder, please remember that you should ftp it in binary mode, and that this keyring should be used with PGP 5.0, since it contains PGP 5.0 keys. ftp://tsx-11.mit.edu/pub/tytso/ietf.pgp - Ted   Received: from ietf.org by ietf.org id aa14709; 14 Aug 97 20:08 EDT Received: from poptart.svr.home.net by ietf.org id aa14503; 14 Aug 97 19:54 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.home.net (Netscape Mail Server v1.1) with ESMTP id AAA10596; Thu, 14 Aug 1997 16:54:37 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id QAA06013; Thu, 14 Aug 1997 16:54:24 -0700 (PDT) Message-Id: <199708142354.QAA06013@lock.eos.home.net> To: ietf@ietf.org cc: scoya@CNRI.Reston.VA.US Subject: Call for Nomcom Volunteers Date: Thu, 14 Aug 1997 16:54:19 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. (Steve please reflect onto ietf-announce) Hi folks - I've been selected to head this years instantiation of the IETF Nomination committee. The good part is that I don't have a vote, the bad part is that I have to find 10 fellow IETF folks to actually run the process. This is the first call for volunteers, the second will occur one week from today, the third 12 days from today (the 15th of August), and the volunteer list will close 2 weeks from today. Once the list closes, I'll provide the list to the IETF secretariat for them to verify the eligibility of the each of the volunteers (e.g. has attended at least 2 of the last 3 IETFs). I will also ask them to publish the list prior to verification for volunteers to confirm that I actually got their email volunteering. Volunteer statements will be accepted by email only to "stjohns@home.net" and must include the tag "NOMCOM VOLUNTEER" in the subject line (yes in all caps). The 10 actual Nomcom members will be selected by lot from the verified list of volunteers on September 20th. The exact procedure will be published later, but will be based on the shares traded numbers of 11 stocks selected by the Nomcom chair. The official shares traded numbers will be drawn from the 20 Sept San Jose Daily news which reports the sales figures from the previous day - 19 Sept 1997. This is an important task - please volunteer, but please make sure you can commit the time over the next 5 months to fulfill the obligations of a Nomcom member. Thanks - Mike   Received: from ietf.org by ietf.org id aa08510; 15 Aug 97 12:49 EDT Received: from freenet.msp.mn.us by ietf.org id aa08267; 15 Aug 97 12:34 EDT Received: from infinia (msp8-6.nas.MR.Net [137.192.19.206]) by freenet.msp.mn.us (8.7.3/8.6.10) with SMTP id QAA06975; Fri, 15 Aug 1997 16:32:32 GMT Message-Id: <199708151632.QAA06975@freenet.msp.mn.us> Comments: Authenticated sender is Sender:ietf-request@ietf.org From: Steven Clift To: ietf@ietf.org Date: Fri, 15 Aug 1997 11:32:07 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Article on Internet Self-Governance Reply-to: clift@freenet.msp.mn.us CC: edem-elect@mtn.org Priority: normal X-mailer: Pegasus Mail for Win32 (v2.54) Source-Info: From (or Sender) name not authenticated. There is an interesting article on the Department of Commerce's request for public input on the domain name issue: http://www.nytimes.com/library/cyber/week/081597domain.html The end of the article quoted Don Heath of the Internet Society on the issue of Internet self-governance. Since the ietf@ list doesn't seem to be the appropriate place to -broadly- discuss or follow the "self-goverance" issue, does anyone know if a specific "internet-self-governance" e-mail discussion list or WWW conference has been established? From a person who is interested in how the Internet and "real" democracy are converging - how the Interent uses these tools in its own decision-making/governance will have a lot to say about how these online tools impact the entire future of democracy. Honestly. Thanks, Steven Clift Democracies Online Here is the quote: "Members of that task force at a July forum on domain governance emphasized that their plan is up for constant review and change. And Don Heath, the president ofthe Internet Society and chairman of the IAHC,said he welcomes suggestions from the Commerce Department. "We will, of course, be very interested in the position that evolves for the government from these comments and plan to put great significance in what the their position is," he said. Heath called the process a healthy one that "will add to the broader understanding of many Internet users while helping to reach a consensus." Self-governance, he said, is the most difficult issue the Internet faces today. "If the Internet is ever to reach its fullest potential, it will require self-governance, or self-regulation," he said. "The Internet Society will continue to take the leadership role in fostering self-governance. We certainly do not want to control, nor govern, but we do want to see effective self-governance." ------------------------------------------------------- Steven L. Clift, Director, Democracies Online 3454 Fremont Ave S, Minneapolis, MN 55408 USA Tel: 612-824-3747 E: clift@freenet.msp.mn.us http://www.e-democracy.org/do/ - Democracies Online http://freenet.msp.mn.us/people/clift/ - Home Page -------------------------------------------------------   Received: from ietf.org by ietf.org id aa06417; 18 Aug 97 9:49 EDT Received: from info.dsv.su.se by ietf.org id aa06127; 18 Aug 97 9:34 EDT Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.5/8.8.5) with ESMTP id PAA27479; Mon, 18 Aug 1997 15:34:00 +0200 (MET DST) X-Sender: jpalme@dsv.su.se (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Aug 1997 15:34:05 +0200 To: IETF general mailing list Sender:ietf-request@ietf.org From: Jacob Palme Subject: Personal notes from some IETF working group meetings in Munich Cc: Web4Groups technical , TERENA WG on e-mail Source-Info: From (or Sender) name not authenticated. My personal notes (not official minutes) from some of the applications area working groups during the IETF meeting in Munich, August 1997, is available at URL http://www.dsv.su.se/~jpalme/ietf/ietf-august-97-notes.html. The notes cover partially the following working groups and BOFs: Hypertext Transfer Protocol WG Webdav - WWW Distributed Authoring and Versioning WG A character set policy for the IETF BOF Drums - revision of the e-mail standards WG Registry Information Database Exchange Formats and Protocols BOF Sending HTML in e-mail - MHTML WG ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme   Received: from ietf.org by ietf.org id aa09322; 18 Aug 97 12:53 EDT Received: from dfw-ix10.ix.netcom.com by ietf.org id aa09204; 18 Aug 97 12:47 EDT Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id LAA05279; Mon, 18 Aug 1997 11:47:24 -0500 (CDT) Received: from kcx-ks5-02.ix.netcom.com(204.30.70.162) by dfw-ix10.ix.netcom.com via smap (V1.3) id sma005234; Mon Aug 18 11:47:08 1997 Message-ID: <33F826EB.28CA@ix.netcom.com> Date: Mon, 18 Aug 1997 11:41:47 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: "Richard J. Sexton" CC: ietf@ietf.org Subject: Re: my posting to newdom@ar.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Richard, Richard J. Sexton wrote: > > One thing I don't understand is why the IETF has been constantly > left out of the DNS crisis resolution. The IETF bowed out of the problem early on on their own accord. A dicission I to this day do not understand. BTW, I am copying them (IETF) on my response to you now. Hope that is ok? Maybe something will shake loose. In several cases I have cc'ed some of the discussions from the IAHC-Discuss list as well as the gTLD-MoU and Domain-policy lists. I was rebuffed very strongly from several members for doing so. In the case of Don Heath, he even changed his E-Mail address several times to avoid recognizing this problem. I don't understand. > > It's been said the IETF speaks only to operational issues, > and in my mind this is simply a method of automtic exclusion > for purposes of control. The IETF excluded themselvs BY CHOICE! (See my comment above) > > While the IETF charter is clear, I say "tough shit". We have > this as the oldest bunch of folks that can get together > and *build* things to fix net.problems, and has a method > for depositing documents with due diligence that we > call the rfc process. I agree. I would say that some of the relevant RFC's such as RFC2050, RFC1918 and RFC1917, which relate to IP allocations are really non-addressive of the current situation. As a long standing member of IETF myself, I find their lack of intrest as a standards body very confusing. On several occasions, as I mentioned above I have attempted to get the IETF actively involved, to no avail. Puzzeling in my mind. Can't put my finger on the reason why. > > It is my fervent belief that an iedf session of from 3 to > 5 days durarion would fix every problem related to the > DNS today. I totaly agree. Hence my puzzelment as to their steadfast refusal to become involved. Go figure. > > If we try this and fail, I will understand. If we don't, > I will not. Well I think this may be a bit of an extream view, I can certianly understand your feeling. I share it to a degree. If you have any particular influence that can turn their thinking around, I encourage you and anyone to exert that to the fullest. You may be alinated for a time, but we all face that possibility every day anyway. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from cnri by ietf.org id aa09982; 18 Aug 97 13:34 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA14129; Mon, 18 Aug 1997 13:37:28 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id LAA25637 for cat-ietf-redist; Mon, 18 Aug 1997 11:48:49 -0400 (EDT) Message-Id: <3.0.1.32.19970818114736.006b993c@world.std.com> X-Sender: linn@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 18 Aug 1997 11:47:36 -0400 To: cat-ietf@mit.edu From: John Linn Subject: Status/proposal re snego-06 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk CAT fanciers: As noted last week in the summary minutes from the Munich CAT session, two attendees asserted that snego-06 did not accurately capture established WG consensus re certain issues (not detailed within the session). It was proposed that these issues be identified on the WG mailing list during the meeting week so as to enable timely reconciliation, but this does not yet appear to have taken place. Recognizing the need to balance the following factors: - timely progress towards advancement of a significant work item which has been pending for some time - the need for WG advancement recommendations to reflect at least rough consensus among the set of WG members actively involved in reviewing particular specifications - possible travel and attendant unavailability among relevant individuals, I'd like to propose the following plan on behalf of the WG: the concerns mentioned at the meeting (accompanied, if possible, by specific proposed changes to snego-06 text in order to reconcile those concerns) are to be identified to the mailing list no later than Wednesday, 27 August in order to enable review and discussion by the snego-06 document editors and the WG generally. Should the results of such discussion dictate a subsequent snego revision, that revision would be submitted to the IESG requesting consideration for Proposed Standard status. If the results of such discussion do not dictate changes to snego-06, or if the issues cited at the Munich meeting are not identified to the WG list by Wednesday, 27 August, snego-06 will be submitted to the IESG requesting consideration for Proposed Standard status. Is this plan feasible and tolerable to/for all concerned? I'll assume its acceptance on behalf of the WG unless objections are raised on the mailing list by Wednesday, 27 August. Thanks, regards, ... --jl   Received: from ietf.org by ietf.org id aa10062; 18 Aug 97 13:36 EDT Received: from lint.cisco.com by ietf.org id aa09992; 18 Aug 97 13:34 EDT Received: from big-dawgs.cisco.com (herndon-dhcp-121.cisco.com [171.68.53.121]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id KAA16031; Mon, 18 Aug 1997 10:34:10 -0700 (PDT) Message-Id: <3.0.3.32.19970818133406.0078dd10@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 18 Aug 1997 13:34:06 -0400 To: Jeff Williams Sender:ietf-request@ietf.org From: Paul Ferguson Subject: Re: my posting to newdom@ar.com Cc: ietf@ietf.org In-Reply-To: <33F826EB.28CA@ix.netcom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. At 11:41 AM 08/18/97 +0100, Jeff Williams wrote: > > The IETF bowed out of the problem early on on their own >accord. A dicission I to this day do not understand. > The IETF Working Groups, by and large, does not engage in policy issues. - paul   Received: from ietf.org by ietf.org id aa11197; 18 Aug 97 14:44 EDT Received: from dfw-ix6.ix.netcom.com by ietf.org id aa11110; 18 Aug 97 14:40 EDT Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id NAA10999; Mon, 18 Aug 1997 13:40:26 -0500 (CDT) Received: from kcx-ks3-26.ix.netcom.com(204.30.70.122) by dfw-ix6.ix.netcom.com via smap (V1.3) id sma010490; Mon Aug 18 13:40:05 1997 Message-ID: <33F84168.70AE@ix.netcom.com> Date: Mon, 18 Aug 1997 13:34:48 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Paul Ferguson CC: ietf@ietf.org Subject: Re: my posting to newdom@ar.com References: <3.0.3.32.19970818133406.0078dd10@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Paul and all, Paul Ferguson wrote: > > At 11:41 AM 08/18/97 +0100, Jeff Williams wrote: > > > > > The IETF bowed out of the problem early on on their own > >accord. A dicission I to this day do not understand. > > > > The IETF Working Groups, by and large, does not engage in policy > issues. Though I respect your concern here, there is alot more than just a policy issues involved here. Many technical issues are also part and parcel to this problem, which is what I was eluding to. It would seem to me that the IETF could knock these issues out fairly easly and quickly, and never get involved with the policy issues. > > - paul Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa11753; 18 Aug 97 15:19 EDT Received: from ginger.lcs.mit.edu by ietf.org id aa11675; 18 Aug 97 15:16 EDT Received: by ginger.lcs.mit.edu id AA20929; Mon, 18 Aug 97 15:16:11 -0400 Date: Mon, 18 Aug 97 15:16:11 -0400 Sender:ietf-request@ietf.org From: Noel Chiappa Message-Id: <9708181916.AA20929@ginger.lcs.mit.edu> To: jwkckid1@ix.netcom.com, richard@vrx.net Subject: Re: my posting to newdom@ar.com Cc: ietf@ietf.org, jnc@ginger.lcs.mit.edu Source-Info: From (or Sender) name not authenticated. From: Jeff Williams > One thing I don't understand is why the IETF has been constantly left > out of the DNS crisis resolution. The IETF bowed out of the problem early on on their own accord. A dicission I to this day do not understand. As Paul Ferguson indicated, because these are mostly *policy* issues, and the IETF (wisely, in my opinion) takes a limited role in such issues. As a pragmatic matter, the IETF cannot take an oversight role anyway, because we have no legal authority or control in this matter. Painful experience has shown us that the courts are all to ready to jump in, and (mis)-apply trademark, etc law to disputes in this area. The IETF does continue to deal with DNS issues that are technical in nature (such as the recent DNS security work), and it also stands ready to advise policy-makers on both technical constraints, and what our perception of sound policies ought to be (i.e. the silliness of applying national trademark law to international domains such as .com) - should they wish to hear our comments (and the old saying about horses and water comes to mind). Next, I will note that the IETF is knee (waist? neck? worse?) deep in technical issues caused by the continued exponential growth of the Internet, and is already short of brainpower/energy for these pressing techical issues. One is therefore forced to apply a species of triage, and apply IETF attention where it is most useful - and policy issues where we will have a limited role, at best, don't look like good candidates for a portion of the IETF's limited energy. Finally, the IETF *is* interested in being involved in these discussions - but we do so first through the medium of individual members who want to pay attention to the day-day goings, carried on via open specialized mailing lists, and second, through a wider (in personnel terms) review of the final conclusions of any such effort, for those who are interested but don't have the time to keep up with the day-day email. BTW, I am copying them (IETF) on my response to you now. Hope that is ok? ... In several cases I have cc'ed some of the discussions from the IAHC-Discuss list as well as the gTLD-MoU and Domain-policy lists. I was rebuffed very strongly from several members for doing so. Because those lists were set up precisely so that IETF members *who were interested in this issue* could add themselves, and leave those of us who were less interested out of the day-day discussions. So, a message or so trying to clarify if the IETF made the right call (such as the message I'm replying to) is OK here - but continued badgering to try and get the rest of us to pay attention, once we have made it clear that we don't want to pay attention, and have rational reasons for that choice, will produce a negative reaction. > has a method for depositing documents with due diligence that we call > the rfc process. I'm certain that you will find that the RFC process (and indeed the whole document-distribution system, including I-D's) stands more than ready to help distribute any documents - and indeed I expect the IETF is interested in having *all* our mechanisms, such as open special-interest mailing lists, as well as wider review of eventual consensus outputs from such smaller groups, available to help. > It is my fervent belief that an iedf session of from 3 to 5 days > durarion would fix every problem related to the DNS today. I totaly agree. Hence my puzzelment as to their steadfast refusal to become involved. Go figure. > If we try this and fail, I will understand. I think you're both barmy if you really think that that would work. Any solution the IETF comes up with will be immediately ignored by courts in the US, Germany, etc - which are *already* moving in on their own, ignoring the opinion of the IETF. (Speaking of Germany, I rather liked the case of the US company with German interests being slammed in the German courts for Web pages in the US which used a term trademarked in Germany - a term *for which the company held a valid trademark in the US* - I'm waiting to see what happens when US courts decide to apply the principle in reverse to German companies - amazing how short-sighted the German legal system was.) This doesn't even take into account what legislatures might do. There *is* a role for the IETF in the larger policy process, but in legal, etc, matters you have to accept that the IETF's role is secondary to the traditional systems that societies have for dealing with such issues. Noel   Received: from ietf.org by ietf.org id aa14224; 18 Aug 97 18:03 EDT Received: from dfw-ix11.ix.netcom.com by ietf.org id aa14109; 18 Aug 97 17:58 EDT Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id QAA18173; Mon, 18 Aug 1997 16:58:23 -0500 (CDT) Received: from kcx-ks6-20.ix.netcom.com(204.30.70.212) by dfw-ix11.ix.netcom.com via smap (V1.3) id sma018133; Mon Aug 18 16:57:51 1997 Message-ID: <33F86FC0.7FEE@ix.netcom.com> Date: Mon, 18 Aug 1997 16:52:32 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Noel Chiappa CC: richard@vrx.net, ietf@ietf.org Subject: Re: my posting to newdom@ar.com References: <9708181916.AA20929@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Noel, Noel Chiappa wrote: > > From: Jeff Williams > > > One thing I don't understand is why the IETF has been constantly left > > out of the DNS crisis resolution. First of all this is Richards comment. But I do agree with it for the most part. > > The IETF bowed out of the problem early on on their own accord. A > dicission I to this day do not understand. > > As Paul Ferguson indicated, because these are mostly *policy* issues, and the > IETF (wisely, in my opinion) takes a limited role in such issues. This is not an answer. Most of the problems with the current DNS problem are NOT policy issues as I stated fully in my prevuous response to Paul. The problems of policy revolve around TEHCNICAL problems with .com, .net and .org and the admisistration of the "Root" in it's legacy software form currrently. So I find this response a NON_ANSWER and self avoiding. As a member of IETF, I feel shamed. > > As a pragmatic matter, the IETF cannot take an oversight role anyway, because > we have no legal authority or control in this matter. Painful experience has > shown us that the courts are all to ready to jump in, and (mis)-apply > trademark, etc law to disputes in this area. I nor Richard, were suggesting that an oversite role be taken by the IETF at all. Rather a more "High Level" technical role. You are very correct that the trademark problems are outside the scope of the IETF charter. And as such, that should not be addressed by the IETF. But Technical matters are within the role of the IETF, and as such, hence ignoring them or not taking some sort of possition is very bad overall practice IMHO for the IETF. > > The IETF does continue to deal with DNS issues that are technical in nature > (such as the recent DNS security work), and it also stands ready to advise > policy-makers on both technical constraints, and what our perception of sound > policies ought to be (i.e. the silliness of applying national trademark law > to international domains such as .com) - should they wish to hear our > comments (and the old saying about horses and water comes to mind). The IETF should be commended in these efforts related to pariferal issues such as the DNS security work, I agree. But quite frankly, those areas, are only PART of the DNS technical problems. What about the rest? > > Next, I will note that the IETF is knee (waist? neck? worse?) deep in > technical issues caused by the continued exponential growth of the Internet, > and is already short of brainpower/energy for these pressing techical issues. Well in that the DNS is central to the growth of the internet, I would think that would be a great motivator to become more centraly involved with the DNS existing problems. > One is therefore forced to apply a species of triage, and apply IETF > attention where it is most useful - and policy issues where we will have a > limited role, at best, don't look like good candidates for a portion of the > IETF's limited energy. Again I will say, that is not what Richard an I were talking about at all. Rather Richard and I were taling to the more central TECHINCAL issues, other than DNS security. > > Finally, the IETF *is* interested in being involved in these discussions - > but we do so first through the medium of individual members who want to pay > attention to the day-day goings, carried on via open specialized mailing > lists, and second, through a wider (in personnel terms) review of the final > conclusions of any such effort, for those who are interested but don't have > the time to keep up with the day-day email. I can understand this compleatly. But I have other pressing issues on a day-to-day basis as well and manage to stay very current. No excuse here guy! > > BTW, I am copying them (IETF) on my response to you now. Hope that is ok? > ... In several cases I have cc'ed some of the discussions from the > IAHC-Discuss list as well as the gTLD-MoU and Domain-policy lists. I was > rebuffed very strongly from several members for doing so. > > Because those lists were set up precisely so that IETF members *who were > interested in this issue* could add themselves, and leave those of us who > were less interested out of the day-day discussions. That is very unfortunate that the intrest in the day to day discussions has little intrest. They should. > > So, a message or so trying to clarify if the IETF made the right call (such > as the message I'm replying to) is OK here - but continued badgering to try > and get the rest of us to pay attention, once we have made it clear that we > don't want to pay attention, and have rational reasons for that choice, will > produce a negative reaction. Very intresting. No badgering is intended at all. Only saying "WAKE UP". > > > has a method for depositing documents with due diligence that we call > > the rfc process. > > I'm certain that you will find that the RFC process (and indeed the whole > document-distribution system, including I-D's) stands more than ready to help > distribute any documents - and indeed I expect the IETF is interested in > having *all* our mechanisms, such as open special-interest mailing lists, as > well as wider review of eventual consensus outputs from such smaller groups, > available to help. THis is great! However, much greater role in the TECHNICAL issues that are more CENTRAL DNS issues need attention. This is what the IETF is supposed to do. > > > It is my fervent belief that an iedf session of from 3 to 5 days > > durarion would fix every problem related to the DNS today. > > I totaly agree. Hence my puzzelment as to their steadfast refusal to > become involved. Go figure. > > > If we try this and fail, I will understand. > > I think you're both barmy if you really think that that would work. What would work? Please elaborate. > > Any solution the IETF comes up with will be immediately ignored by courts in > the US, Germany, etc - which are *already* moving in on their own, ignoring > the opinion of the IETF. As to policy, I agree. On the other hand, I doubt that TECHNICAL issues would be ignored. Rather it appears that the IETF is ignoring the CENTRAL TECHNICAL issues, and concentrating on more pariferal TECHNICAL technical issues (DNS Security for example). > > (Speaking of Germany, I rather liked the case of the US company with German > interests being slammed in the German courts for Web pages in the US which > used a term trademarked in Germany - a term *for which the company held a > valid trademark in the US* - I'm waiting to see what happens when US courts > decide to apply the principle in reverse to German companies - amazing how > short-sighted the German legal system was.) All of the policy issues are really outgrowths of the existing CENTRAL TECHNICAL issues, other than the Trademark problems, and even those to a degree. > > This doesn't even take into account what legislatures might do. Well you can count on them procrastinating for quite a while at least. > > There *is* a role for the IETF in the larger policy process, but in legal, > etc, matters you have to accept that the IETF's role is secondary to the > traditional systems that societies have for dealing with such issues. I do. > > Noel Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from cnri by ietf.org id aa02943; 19 Aug 97 5:36 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid FAA16162; Tue, 19 Aug 1997 05:39:51 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id DAA26706 for cat-ietf-redist; Tue, 19 Aug 1997 03:38:39 -0400 (EDT) From: "J.Lebastard" Message-Id: <9708190739.AA13768@bahamas.frcl.bull.fr> Subject: Re: Status/proposal re snego-06 To: John Linn Date: Tue, 19 Aug 1997 09:39:16 +0200 (DFT) Cc: IETF CAT Group In-Reply-To: <3.0.1.32.19970818114736.006b993c@world.std.com> from "John Linn" at Aug 18, 97 11:47:36 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Precedence: bulk > CAT fanciers: > > As noted last week in the summary minutes from the Munich CAT session, two > attendees asserted that snego-06 did not accurately capture established WG > consensus re certain issues (not detailed within the session). > Is this plan feasible and tolerable to/for all concerned? I'll assume its > acceptance on behalf of the WG unless objections are raised on the mailing > list by Wednesday, 27 August. FYI, Denis Pinkas will be back from holidays next monday, 25th August .... -- Jacques LEBASTARD mailto:J.Lebastard@frcl.bull.fr BULL SA - ISM AccessMaster http://www.openmaster.com/ Rue Jean Jaures - A5/146 Tel: +33 1 30 80 77 86 F-78340 Les Clayes sous Bois Fax: +33 1 30 80 77 99   Received: from ietf.org by ietf.org id aa04469; 19 Aug 97 7:25 EDT Received: from mersey.hursley.ibm.com by ietf.org id aa04223; 19 Aug 97 7:11 EDT Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA74535; Tue, 19 Aug 1997 12:11:43 +0100 Date: Tue, 19 Aug 1997 12:11:43 +0100 Message-Id: <9708191111.AA74535@hursley.ibm.com> Sender:ietf-request@ietf.org From: "(Brian E Carpenter)" Subject: IAB appointments to gTLD POC To: ietf@ietf.org Reply-To: pocnom@iab.org Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4770 Source-Info: From (or Sender) name not authenticated. [the official version of this will be sent to the ietf-announce list as soon as the Secretariat is back from Munich] IAB appointments to the DNS POC IETF, The IAB has now concluded its discussion of the appointment of two members to the Policy Oversight Committee established under the recently signed DNS Memorandum of Understanding. The list of nominees and the procedure followed are attached below. (One nominee, Bill Manning, withdrew after this list was published.) We were delighted to have such a good list of nominees, but this made the final choice very difficult as we were limited to two appointments. As announced, we looked principally at technical expertise, combined with international experience. It should be noted that we have made these appointments before the POC has been formally established and in the absence of a precise job description for its members. It should also be noted that the appointees are expected to act as individual experts, not as delegates of the IAB or the IETF. The IAB wishes to sincerely thank its appointees to the IAHC, Geoff Huston and Hank Nussbacher, who have given much of their time and energy to the IAHC and recently to the interim POC. We also thank the other candidates for their willingness to serve, and all IETF members who nominated or commented on candidates. The IAB appointees are Patrik Faltstrom (3 year term) Rob Austein (1 year term) Regards, Brian Carpenter (IAB Chair) --attachments-- Subject: Re: Call for POC Nominations Sender: ietf-announce-request@ietf.org From: Abel Weinrib Reply-To: pocnom@iab.org Date: Mon, 04 Aug 1997 18:07:37 -0400 Message-Id: <9708041807.aa29786@ietf.org> The IAB has been asked to appoint two people to the Policy Oversight Committee (POC) established under the recently signed DNS Memorandum of Understanding. The final list of willing nominees has now been determined: Antonio-Blasco Bonito Bill Manning Carl Malamud Christopher Wilkinson Eric Brunner J. Clarke Anderson John Lekashman Laura L. Smith Mark Andrews Olafur Gudmundsson Patrik Faltstrom Paul Vixie Pindar Wong Rick Wesson Rob Austein Stev Knowles The two IAB appointments will be chosen from this list shortly. Confidential comments from the community are still welcome--please send them to pocnom@iab.org. Abel Weinrib, IAB Executive Director >To: IETF-Announce: ; >Subject: Call for POC Nominations >Sender: ietf-announce-request@ietf.org >From: Brian E Carpenter >Reply-to: pocnom@iab.org >Date: Tue, 27 May 1997 11:27:28 -0400 >X-Orig-Sender: scoya@ietf.org >Content-Length: 2071 > > >IETF, > >The IAB has been requested to appoint two people to the Policy >Oversight Committee (POC) established under the recently signed >DNS Memorandum of Understanding. For full details please >see http://www.iahc.org/gTLD-MoU.html > >Although there is continued discussion at the political level >about these matters, the IAB has decided to proceed with these >appointments to avoid loss of time if and when the POC starts up. > >One person is to be appointed for one year and a second person >for three years, to allow for rolling replacements in future. >The IAB has decided to appoint persons with strong technical >expertise in DNS and Internet technology and with a strong claim >to have an international outlook. The IAB has further decided >to make an open call for nominations from the IETF community. > >Procedure: > >1. This message is the call for nominations, which should be sent >to pocnom@iab.org by the closing date of 30 June 1997. > >** DO NOT SEND NOMINATIONS AS A REPLY TO THIS MESSAGE; SEND THEM > TO pocnom@iab.org ** > >2. Each nomination must give the name, affiliation, email address >and phone number of the nominee, plus a brief statement (maximum >10 lines) about the nominee's technical and international credentials. > >3. Self-nominations are allowed. > >4. The IAB will verify each nominee's willingness to serve for one >or three years. > >5. The list of willing nominees will be published by the IAB shortly >after the closing date. Confidential comments from the community will >be solicited. The IAB will then make its two appointments >and announce them within one month. > >6. Apart from the above, the IAB will be guided in its deliberations >by the procedures defined in RFC 2027. > >7. Nominees must accept that a recall procedure, analagous to that >defined in RFC 2027, may be invoked at any time during their terms. > >Note - for future years, the IAB is considering delegating >this task to the normal IETF Nominating and Recall Committee >established under RFC 2027. Comments on this idea are welcome. > > Brian Carpenter (IAB Chair) brian@hursley.ibm.com >   Received: from ietf.org by ietf.org id aa05361; 19 Aug 97 8:27 EDT Received: from ietf.ietf.org by ietf.org id aa05241; 19 Aug 97 8:21 EDT To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: pocnom@iab.org Subject: IAB appointments to the DNS POC Date: Tue, 19 Aug 1997 08:21:21 -0400 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9708190821.aa05241@ietf.org> IETF, The IAB has now concluded its discussion of the appointment of two members to the Policy Oversight Committee established under the recently signed DNS Memorandum of Understanding. The list of nominees and the procedure followed are attached below. (One nominee, Bill Manning, withdrew after this list was published.) We were delighted to have such a good list of nominees, but this made the final choice very difficult as we were limited to two appointments. As announced, we looked principally at technical expertise, combined with international experience. It should be noted that we have made these appointments before the POC has been formally established and in the absence of a precise job description for its members. It should also be noted that the appointees are expected to act as individual experts, not as delegates of the IAB or the IETF. The IAB wishes to sincerely thank its appointees to the IAHC, Geoff Huston and Hank Nussbacher, who have given much of their time and energy to the IAHC and recently to the interim POC. We also thank the other candidates for their willingness to serve, and all IETF members who nominated or commented on candidates. The IAB appointees are Patrik Faltstrom (3 year term) Rob Austein (1 year term) Regards, Brian Carpenter (IAB Chair) --attachments-- Subject: Re: Call for POC Nominations Sender: ietf-announce-request@ietf.org From: Abel Weinrib Reply-To: pocnom@iab.org Date: Mon, 04 Aug 1997 18:07:37 -0400 Message-Id: <9708041807.aa29786@ietf.org> The IAB has been asked to appoint two people to the Policy Oversight Committee (POC) established under the recently signed DNS Memorandum of Understanding. The final list of willing nominees has now been determined: Antonio-Blasco Bonito Bill Manning Carl Malamud Christopher Wilkinson Eric Brunner J. Clarke Anderson John Lekashman Laura L. Smith Mark Andrews Olafur Gudmundsson Patrik Faltstrom Paul Vixie Pindar Wong Rick Wesson Rob Austein Stev Knowles The two IAB appointments will be chosen from this list shortly. Confidential comments from the community are still welcome--please send them to pocnom@iab.org. Abel Weinrib, IAB Executive Director >To: IETF-Announce: ; >Subject: Call for POC Nominations >Sender: ietf-announce-request@ietf.org >From: Brian E Carpenter >Reply-to: pocnom@iab.org >Date: Tue, 27 May 1997 11:27:28 -0400 >X-Orig-Sender: scoya@ietf.org >Content-Length: 2071 > > >IETF, > >The IAB has been requested to appoint two people to the Policy >Oversight Committee (POC) established under the recently signed >DNS Memorandum of Understanding. For full details please >see http://www.iahc.org/gTLD-MoU.html > >Although there is continued discussion at the political level >about these matters, the IAB has decided to proceed with these >appointments to avoid loss of time if and when the POC starts up. > >One person is to be appointed for one year and a second person >for three years, to allow for rolling replacements in future. >The IAB has decided to appoint persons with strong technical >expertise in DNS and Internet technology and with a strong claim >to have an international outlook. The IAB has further decided >to make an open call for nominations from the IETF community. > >Procedure: > >1. This message is the call for nominations, which should be sent >to pocnom@iab.org by the closing date of 30 June 1997. > >** DO NOT SEND NOMINATIONS AS A REPLY TO THIS MESSAGE; SEND THEM > TO pocnom@iab.org ** > >2. Each nomination must give the name, affiliation, email address >and phone number of the nominee, plus a brief statement (maximum >10 lines) about the nominee's technical and international credentials. > >3. Self-nominations are allowed. > >4. The IAB will verify each nominee's willingness to serve for one >or three years. > >5. The list of willing nominees will be published by the IAB shortly >after the closing date. Confidential comments from the community will >be solicited. The IAB will then make its two appointments >and announce them within one month. > >6. Apart from the above, the IAB will be guided in its deliberations >by the procedures defined in RFC 2027. > >7. Nominees must accept that a recall procedure, analagous to that >defined in RFC 2027, may be invoked at any time during their terms. > >Note - for future years, the IAB is considering delegating >this task to the normal IETF Nominating and Recall Committee >established under RFC 2027. Comments on this idea are welcome. > > Brian Carpenter (IAB Chair) brian@hursley.ibm.com >   Received: from ietf.org by ietf.org id aa06056; 20 Aug 97 9:32 EDT Received: from ietf.ietf.org by ietf.org id aa05588; 20 Aug 97 9:07 EDT To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: "Mike St. Johns" Subject: Call for Nomcom Volunteers Date: Wed, 20 Aug 1997 09:07:30 -0400 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9708200907.aa05588@ietf.org> Hi folks - I've been selected to head this years instantiation of the IETF Nomination committee. The good part is that I don't have a vote, the bad part is that I have to find 10 fellow IETF folks to actually run the process. This is the first call for volunteers, the second will occur one week from today, the third 12 days from today (the 15th of August), and the volunteer list will close 2 weeks from today. Once the list closes, I'll provide the list to the IETF secretariat for them to verify the eligibility of the each of the volunteers (e.g. has attended at least 2 of the last 3 IETFs). I will also ask them to publish the list prior to verification for volunteers to confirm that I actually got their email volunteering. Volunteer statements will be accepted by email only to "stjohns@home.net" and must include the tag "NOMCOM VOLUNTEER" in the subject line (yes in all caps). The 10 actual Nomcom members will be selected by lot from the verified list of volunteers on September 20th. The exact procedure will be published later, but will be based on the shares traded numbers of 11 stocks selected by the Nomcom chair. The official shares traded numbers will be drawn from the 20 Sept San Jose Daily news which reports the sales figures from the previous day - 19 Sept 1997. This is an important task - please volunteer, but please make sure you can commit the time over the next 5 months to fulfill the obligations of a Nomcom member. Thanks - Mike   Received: from ietf.org by ietf.org id aa07863; 20 Aug 97 10:59 EDT Received: from xray.pro.icl.se by ietf.org id aa07744; 20 Aug 97 10:53 EDT Received: from pctomfa.pro.icl.se (pctomfa.pro.icl.se [140.150.77.100]) by xray.teamware.se (8.6.9/tomfa/9608130859) with ESMTP id QAA28401; Wed, 20 Aug 1997 16:55:44 +0200 Message-Id: <25953.872085358.83302182.22323@> Date: Wed, 20 Aug 1997 15:55:58 +0200 Sender:ietf-request@ietf.org From: Tomas Fasth Subject: Re: my posting to newdom@ar.com To: jwkckid1@ix.netcom.com, jnc@ginger.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: richard@vrx.net, ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Reply-To: Tomas Fasth X-Importance: normal X-Sensitivity: normal X-Priority: normal X-Mailer: TeamWARE Embla 2.03, Final, Build: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Source-Info: From (or Sender) name not authenticated. Jeff, IMO, you are making a lot of noice here. Honestly, I find it very tiresome to extract any substance in a posting of 10K of which 1K is the senders contribution. A tip: try to keep the quoted text short. You are repeatedly mentioning "TECHNICAL ISSUES" with no clarification as if you are assuming that everybody already know (or care) about what you are referring to. Another tip: avoid ambigous discussions and focus on making your point clear and easily understood. IMO, technical issues concerning DNS are better suited in a mailing-list designated for that purpose. The probability of getting constructive followups concerning technical matters related to DNS is much higher if you move closer to such a forum. IETF concist of individuals on a volentary basis. You can not force an individual to work on (or bother about) issues which do not interest that individual. My guess is that a minority of ietf@ietf.org subscribers are interested in discussing DNS technics. And those who are, are probably already present in mailing-lists related to DNS. So Jeff, what are you trying to achieve here? Regards, Tomas --------------- Tomas Fasth   Received: from ietf.org by ietf.org id aa08283; 20 Aug 97 11:15 EDT Received: from dfw-ix3.ix.netcom.com by ietf.org id aa08164; 20 Aug 97 11:13 EDT Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id KAA24582; Wed, 20 Aug 1997 10:11:32 -0500 (CDT) Received: from kcx-ks13-11.ix.netcom.com(206.214.130.139) by dfw-ix3.ix.netcom.com via smap (V1.3) id sma024353; Wed Aug 20 10:11:09 1997 Message-ID: <33FAB363.35E@ix.netcom.com> Date: Wed, 20 Aug 1997 10:05:39 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Tomas Fasth CC: jnc@ginger.lcs.mit.edu, richard@vrx.net, ietf@ietf.org Subject: Re: my posting to newdom@ar.com References: <25953.872085358.83302182.22323@> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Tomas, Tomas Fasth wrote: > > Jeff, > > IMO, you are making a lot of noice here. > Honestly, I find it very tiresome to extract any substance in a posting > of 10K of which 1K is the senders contribution. I don't believ I mentioned any of that In MY spicific responses. Though they may have been part of the E-Mail I was copying to the IETF. > > A tip: try to keep the quoted text short. I try to do so when it is approiate. Otherwise clarity is more important and therefore requires a bit more verbage at times. > > You are repeatedly mentioning "TECHNICAL ISSUES" with no clarification > as if you are assuming that everybody already know (or care) about > what you are referring to. Catagoricly NOT TRUE. And if you don't mind me saying so, you did not read my original post reguarding TECHNICAL ISSUES closely or you would not be making this statment. Please refrain from doing so in the future. Thank you. > > Another tip: avoid ambigous discussions and focus on making your point > clear and easily understood. I do try to do this. If it is not easly understood, please feel free to post me privatly as some have already done. I will be happy to refrase in hopes of helping anyone understand any point I make. >;) > > IMO, technical issues concerning DNS are better suited in a mailing-list > designated for that purpose. The probability of getting constructive > followups concerning technical matters related to DNS is much higher > if you move closer to such a forum. I do so on some other mailing lists frequently or as time allows. > > IETF concist of individuals on a volentary basis. You can not force an > individual to work on (or bother about) issues which do not interest > that individual. My guess is that a minority of ietf@ietf.org > subscribers are interested in discussing DNS technics. And those who > are, are probably already present in mailing-lists related to DNS. I realize what the IETF consist's of. I am a long standing member, though less active these days. I am not attempting to FORCE anything on anyone and stated such clearly. I do so again here! I am sure you are VERY CORRECT that there is a MINORITY of subscribers the the IETF@ietf.org mailing list that have ANY intrest in DNS TECHINCAL matters. This is unfortunate. I do believe that raising awarness in the severity of the DNS TECHNICAL matters is of the UPMOST importance to the health of the Internet hwoever. Do you disagree? And as such, should be a matter of GREAT importance to the IETF in general. > > So Jeff, what are you trying to achieve here? > > Regards, Tomas > > --------------- > Tomas Fasth Thank you for your comments, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa08845; 20 Aug 97 11:38 EDT Received: from mail.bhi-erc.com by ietf.org id aa08720; 20 Aug 97 11:36 EDT Received: from ccMail by mail.bhi-erc.com (IMA Internet Exchange 2.02 Enterprise) id 3FB0A330; Wed, 20 Aug 97 08:16:03 -0700 Mime-Version: 1.0 Date: Wed, 20 Aug 1997 08:28:34 -0700 Message-ID: <3FB0A330.@bhi-erc.com> Sender:ietf-request@ietf.org From: Timothy W Haight Subject: RE: my posting to newdom@ar.com To: Jeff Williams , Tomas Fasth Cc: jnc@ginger.lcs.mit.edu, richard@vrx.net, ietf@ietf.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Source-Info: From (or Sender) name not authenticated. please remove me from your mailing list. -----Original Message----- From: Jeff Williams Sent: Wednesday, August 20, 1997 10:06 AM To: Tomas Fasth Cc: jnc@ginger.lcs.mit.edu; richard@vrx.net; ietf@ietf.org Subject: Re: my posting to newdom@ar.com Tomas, Tomas Fasth wrote: > > Jeff, > > IMO, you are making a lot of noice here. > Honestly, I find it very tiresome to extract any substance in a posting > of 10K of which 1K is the senders contribution. I don't believ I mentioned any of that In MY spicific responses. Though they may have been part of the E-Mail I was copying to the IETF. > > A tip: try to keep the quoted text short. I try to do so when it is approiate. Otherwise clarity is more important and therefore requires a bit more verbage at times. > > You are repeatedly mentioning "TECHNICAL ISSUES" with no clarification > as if you are assuming that everybody already know (or care) about > what you are referring to. Catagoricly NOT TRUE. And if you don't mind me saying so, you did not read my original post reguarding TECHNICAL ISSUES closely or you would not be making this statment. Please refrain from doing so in the future. Thank you. > > Another tip: avoid ambigous discussions and focus on making your point > clear and easily understood. I do try to do this. If it is not easly understood, please feel free to post me privatly as some have already done. I will be happy to refrase in hopes of helping anyone understand any point I make. >;) > > IMO, technical issues concerning DNS are better suited in a mailing-list > designated for that purpose. The probability of getting constructive > followups concerning technical matters related to DNS is much higher > if you move closer to such a forum. I do so on some other mailing lists frequently or as time allows. > > IETF concist of individuals on a volentary basis. You can not force an > individual to work on (or bother about) issues which do not interest > that individual. My guess is that a minority of ietf@ietf.org > subscribers are interested in discussing DNS technics. And those who > are, are probably already present in mailing-lists related to DNS. I realize what the IETF consist's of. I am a long standing member, though less active these days. I am not attempting to FORCE anything on anyone and stated such clearly. I do so again here! I am sure you are VERY CORRECT that there is a MINORITY of subscribers the the IETF@ietf.org mailing list that have ANY intrest in DNS TECHINCAL matters. This is unfortunate. I do believe that raising awarness in the severity of the DNS TECHNICAL matters is of the UPMOST importance to the health of the Internet hwoever. Do you disagree? And as such, should be a matter of GREAT importance to the IETF in general. > > So Jeff, what are you trying to achieve here? > > Regards, Tomas > > --------------- > Tomas Fasth Thank you for your comments, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa08833; 20 Aug 97 11:38 EDT Received: from dfw-ix16.ix.netcom.com by ietf.org id aa08657; 20 Aug 97 11:34 EDT Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id KAA02975; Wed, 20 Aug 1997 10:32:32 -0500 (CDT) Received: from kcx-ks11-04.ix.netcom.com(206.214.130.100) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma029402; Wed Aug 20 10:24:17 1997 Message-ID: <33FAB677.432B@ix.netcom.com> Date: Wed, 20 Aug 1997 10:18:47 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Randy Bush CC: Global TLD's discuss , eDNS Discuss , Domain policy , IETF ORG , Tomas Fasth , jnc@ginger.lcs.mit.edu, richard@vrx.net Subject: Re: my posting to newdom@ar.com References: <25953.872085358.83302182.22323@> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Randy and all, Randy Bush wrote: > > > So Jeff, what are you trying to achieve here? > > Find someone foolish enough to answer his idiotic mail. Very intresting response from an IETF member. > > randy Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa09107; 20 Aug 97 11:46 EDT Received: from ns1.vrx.net by ietf.org id aa08984; 20 Aug 97 11:44 EDT Received: from mbv1-ipl-ri22.kos.net(really [206.186.41.80]) by vrx.net via sendmail with smtp id for ; Wed, 20 Aug 1997 11:42:25 -0400 (EDT) (Smail-3.2.0.92 1997-Feb-9 #2 built 1997-Apr-8) Message-Id: Date: Wed, 20 Aug 1997 11:42:25 -0400 (EDT) X-Sender: richard@vrx.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tomas Fasth Sender:ietf-request@ietf.org From: "Richard J. Sexton" Subject: Re: my posting to newdom@ar.com Cc: jwkckid1@ix.netcom.com, jnc@ginger.lcs.mit.edu, ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 03:55 PM 8/20/97 +0200, Tomas Fasth wrote: >IETF concist of individuals on a volentary basis. You can not force an >individual to work on (or bother about) issues which do not interest >that individual. My guess is that a minority of ietf@ietf.org >subscribers are interested in discussing DNS technics. And those who >are, are probably already present in mailing-lists related to DNS. Nobody is trying to force anybody to do anything. You are quite correct in that DNS policy is no the perview of the IETF. Arguably, it is not the purview of the US Government either, byt they're now involved in it in a big way. Don't you think thats a bit ironic? There are problems with the current DNS that are separate from expansion of the root zone; the latter has obfuscated the former and impeded progress. I think it would be beneficial if the IEFT held an emergancy workshop about the DNS. 3 Days ought to do it. One day to recap wherere we are right now and what has happened. One day to synthesis a more palettable solution, one day to review and refine it.   Received: from ietf.org by ietf.org id aa09747; 20 Aug 97 12:02 EDT Received: from mail.bhi-erc.com by ietf.org id aa09595; 20 Aug 97 11:59 EDT Received: from ccMail by mail.bhi-erc.com (IMA Internet Exchange 2.02 Enterprise) id 3FB0F4B0; Wed, 20 Aug 97 08:37:47 -0700 Mime-Version: 1.0 Date: Wed, 20 Aug 1997 08:50:00 -0700 Message-ID: <3FB0F4B0.@bhi-erc.com> Sender:ietf-request@ietf.org From: Timothy W Haight Subject: RE: my posting to newdom@ar.com To: Jeff Williams , Randy Bush Cc: Global TLD's discuss , eDNS Discuss , Domain policy , IETF ORG , Tomas Fasth , jnc@ginger.lcs.mit.edu, richard@vrx.net Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Source-Info: From (or Sender) name not authenticated. Please remove me from this list. -----Original Message----- From: Jeff Williams Sent: Wednesday, August 20, 1997 10:19 AM To: Randy Bush Cc: Global TLD's discuss ; eDNS Discuss ; Domain policy ; IETF ORG ; Tomas Fasth ; jnc@ginger.lcs.mit.edu; richard@vrx.net Subject: Re: my posting to newdom@ar.com Randy and all, Randy Bush wrote: > > > So Jeff, what are you trying to achieve here? > > Find someone foolish enough to answer his idiotic mail. Very intresting response from an IETF member. > > randy Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa10635; 20 Aug 97 12:27 EDT Received: from THOR.INNOSOFT.COM by ietf.org id aa10497; 20 Aug 97 12:24 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IMJYDYYAJ494E6GE@INNOSOFT.COM> for ietf@ietf.org; Wed, 20 Aug 1997 09:24:00 PDT Date: Wed, 20 Aug 1997 09:15:50 -0700 (PDT) Sender:ietf-request@ietf.org From: Ned Freed Subject: Internet-drafts still not accepting documents after Munich meeting To: ietf@ietf.org Message-id: <01IMNOSX49QI94E6GE@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Source-Info: From (or Sender) name not authenticated. As it often the case, I have a flock of new Internet Draft documents I'd like to post as a result of feedback I've received from the Munich IETF. I like to get this done quickly before I and others become entangled in other matters and lose focus on progress made during the meeting. This time, however, I have been unable to do so -- when I send in the new drafts in to the usual address I get back the following: > The cut-off for Internet-Draft submissions was Wednesday,July 30, 1997 > at 5pm ET. Internet-Drafts received after this time will not be > announced nor made available in the Internet-drafts Directories. > We will not accept Internet-Draft submissions until after the IETF > meeting, August 18. You will have to resubmit your document at that > time. The message indicates that new drafts would be accepted on or after August 18. It is now August 20 and I still get this message back. I've always regarded the inability to send in drafts during IETF week as rather silly -- don't we all have mail systems that queue up messages for us? This current behavior, however, I regard as unacceptable and I would like to see it fixed ASAP. Ned   Received: from ietf.org by ietf.org id aa11174; 20 Aug 97 12:50 EDT Received: from xray.pro.icl.se by ietf.org id aa11098; 20 Aug 97 12:48 EDT Received: from pctomfa.pro.icl.se (pctomfa.pro.icl.se [140.150.77.100]) by xray.teamware.se (8.6.9/tomfa/9608130859) with ESMTP id SAA29457; Wed, 20 Aug 1997 18:49:51 +0200 Message-Id: <21909.872095370.93313808.28119@> Date: Wed, 20 Aug 1997 18:42:50 +0200 Sender:ietf-request@ietf.org From: Tomas Fasth Subject: Re: my posting to newdom@ar.com To: jwkckid1@ix.netcom.com MMDF-Warning: Parse error in original version of preceding line at ietf.org Cc: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Reply-To: Tomas Fasth X-Importance: normal X-Sensitivity: normal X-Priority: normal X-Mailer: TeamWARE Embla 2.03, Final, Build: 69 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Source-Info: From (or Sender) name not authenticated. Jeff Williams: > Catagoricly NOT TRUE. And if you don't mind me saying so, you did >not read my original post reguarding TECHNICAL ISSUES closely or >you would not be making this statment. Please refrain from doing so >in the future. Thank you. Jeff, I assure you, I tried to find such a posting in the archive for ietf@ietf.org. There is none. And that is my point. You are showing lack of manner by throwing a fragment of an ongoing discussion thread onto a different audience. It will definitely not serve your purpose. I'm not sure what you want me to refrain from, since you did not give me (or others on this list) a fair chance to understand the issue. When you go out of scope you are supposed to reinitialize your variables. In other words, by addressing a new audience it's your responsibility to state (or refer to) the facts, make your point and clarify what you want to achieve. I realize now that I may have jumped into something infectious here. Based on the few messages I found regarding this subject, I got a feeling that you are trying to raise technical issues (whatever they are) for political reasons. If that is the case I can understand why so few IETF'ers want to deal with it. Having jumped into the trap, I might as well give your case a try. But I rather do that outside this list, since I guess most subscribers don't want to hear more about it. So, please E-mail me a pointer where I can find facts about this. thanks, Tomas --------------- Tomas Fasth   Received: from ietf.org by ietf.org id aa12578; 20 Aug 97 13:36 EDT Received: from gungnir.fnal.gov by ietf.org id aa12469; 20 Aug 97 13:34 EDT Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA06241; Wed, 20 Aug 1997 12:34:26 -0500 Message-Id: <199708201734.MAA06241@gungnir.fnal.gov> To: Ned Freed Cc: ietf@ietf.org Sender:ietf-request@ietf.org From: Matt Crawford Subject: Re: Internet-drafts still not accepting documents after Munich meeting In-reply-to: Your message of Wed, 20 Aug 1997 09:15:50 PDT. <01IMNOSX49QI94E6GE@INNOSOFT.COM> Date: Wed, 20 Aug 1997 12:34:26 -0500 X-Orig-Sender: crawdad@gungnir.fnal.gov Source-Info: From (or Sender) name not authenticated. > This time, however, I have been unable to do so -- when I send in the new > drafts in to the usual address I get back the following: > > > The cut-off for Internet-Draft submissions was Wednesday,July 30, 1997 Yeah, yeah. I got the same message. I wrote to ietf-info (since hardly anyone on *this* list can do anything about the problem). They know and and working on fixing it. OK? __________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: 0x566F63C5 - D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A   Received: from ietf.org by ietf.org id aa13031; 20 Aug 97 13:51 EDT Received: from limes.NIC.DTAG.DE by ietf.org id aa12915; 20 Aug 97 13:50 EDT Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92]) by limes.NIC.DTAG.DE (8.8.5/8.8.3) with ESMTP id TAA07979; Wed, 20 Aug 1997 19:48:12 +0200 (MET DST) Received: from kronos.NIC.DTAG.DE (kronos.NIC.DTAG.DE [194.25.1.92]) by kronos.NIC.DTAG.DE (8.8.5/8.7.1) with ESMTP id TAA16132; Wed, 20 Aug 1997 19:50:45 +0200 (MET DST) To: "Richard J. Sexton" cc: ietf@ietf.org Subject: Re: my posting to newdom@ar.com In-reply-to: Your message of "Wed, 20 Aug 1997 11:42:25 EDT." Date: Wed, 20 Aug 1997 19:50:45 +0200 Message-ID: <16130.872099445@kronos.NIC.DTAG.DE> Sender:ietf-request@ietf.org From: Ruediger Volk Source-Info: From (or Sender) name not authenticated. > I think it would be beneficial if the IEFT held an emergancy workshop > about the DNS. I'm not aware that "the IETF" holds workshops - at least I cannot remember any over the 8 years I've been watching IETF mailings lists and attending meetings. Please remember that the IETF actually does it's work in it's working groups which in fact are constituted by the membership of their mailing lists - while the WG sessions at the meetings are only considered as a special way for having very intense discussion within a subset of the WG members. I don't think that any of the existing working groups would be right for holding that workshop (I don't think it would fit well any WG's charter). Please think a bit more specific about what you actually mean by "the IETF holds a workshop" (and you certainly would be more specific as to the topic(s) of the workshop than "about the DNS"): - how large an attendance do you think about? - how close would you want it to resemble (a) the merged WG mailing lists? (b) the attendance of the regular IETF meetings? (c) the IESG with special guests? (d) the IAB with special guests? (e) the IANA with special guests? (f) any set of specific WGs? which? - do you think (a) or (b) are achievable? (I don't think so) - do you think that's reasonable to achive (f) if the workshop topic is not really on the WG's charters? (I have the feeling you want the topic of the workshop to be something not on any current charter) - would you talk about (c) to (e) as "the IETF holds a workshop"? (I'd rather say "the I holds a workshop" - and by the way some I indeed seem to do workshops once in a while) > 3 Days ought to do it. One day to recap wherere we > are right now and what has happened. One day to synthesis a more > palettable solution, one day to review and refine it. "The IETF" never works this way - not even for it's own technical subject area - and it's just not possible to get to the IETF style "rough consensus" with this arrangement and timeframe - and no "running code" either. Or are you expecting results that don't match IETF style? Why would you expect the IETF to be able/good to achive something outside the style, the culture, or procedures of "the IETF"? As the word "foolish" has been mentioned already and critized as being used by an IETF member I'd like to note, that I'm painfully aware that it may be foolish of me to contribute this comment to this discussion. To limit my foolishness and the consumption of time I'll keep it to a single message in this thread. Ruediger Volk   Received: from ietf.org by ietf.org id aa13030; 20 Aug 97 13:51 EDT Received: from lint.cisco.com by ietf.org id aa12926; 20 Aug 97 13:50 EDT Received: from big-dawgs.cisco.com (herndon-dhcp-121.cisco.com [171.68.53.121]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id KAA25732; Wed, 20 Aug 1997 10:50:17 -0700 (PDT) Message-Id: <3.0.3.32.19970820135015.0070d868@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 20 Aug 1997 13:50:15 -0400 To: Tomas Fasth Sender:ietf-request@ietf.org From: Paul Ferguson Subject: Re: my posting to newdom@ar.com Cc: ietf@ietf.org In-Reply-To: <21909.872095370.93313808.28119@> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. At 06:42 PM 08/20/97 +0200, Tomas Fasth wrote: > >Having jumped into the trap, I might as well give your case a try. >But I rather do that outside this list, since I guess most subscribers >don't want to hear more about it. > Right on that point. - paul   Received: from ietf.org by ietf.org id aa13305; 20 Aug 97 14:00 EDT Received: from giasmda.vsnl.net.in by ietf.org id aa13240; 20 Aug 97 13:59 EDT Received: from localhost by giasmda.vsnl.net.in (SMI-8.6/SMI-SVR4) id XAA02578; Wed, 20 Aug 1997 23:29:09 +0530 Date: Wed, 20 Aug 1997 23:29:08 +0530 (IST) Sender:ietf-request@ietf.org From: PRAKASH R X-Sender: prakashr@giasmda To: Timothy W Haight cc: Jeff Williams , Randy Bush , Global TLD's discuss , eDNS Discuss , Domain policy , IETF ORG , Tomas Fasth , jnc@ginger.lcs.mit.edu, richard@vrx.net Subject: RE: my posting to newdom@ar.com In-Reply-To: <3FB0F4B0.@bhi-erc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. Please tell me why I am receiving all the coomunication that you people are doing? Thanks   Received: from ietf.org by ietf.org id aa13577; 20 Aug 97 14:07 EDT Received: from dfw-ix12.ix.netcom.com by ietf.org id aa13504; 20 Aug 97 14:06 EDT Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id NAA08600 for ; Wed, 20 Aug 1997 13:06:29 -0500 (CDT) Received: from kcx-ks5-15.ix.netcom.com(204.30.70.175) by dfw-ix12.ix.netcom.com via smap (V1.3) id sma008558; Wed Aug 20 13:05:50 1997 Message-ID: <33FAE0C8.28@ix.netcom.com> Date: Wed, 20 Aug 1997 13:19:20 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: IETF ORG Subject: [Fwd: Re: my posting to newdom@ar.com] Content-Type: multipart/mixed; boundary="------------65B869C4C04" Source-Info: From (or Sender) name not authenticated. This is a multi-part message in MIME format. --------------65B869C4C04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, FOrwarding to insure that everyone can determine that I am primarily intrested in TECHNICAL ISSUES in respect to the DNS crisis problems. I believe I posted this as a cc' befor however. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com --------------65B869C4C04 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <33F952C5.5D1D@ix.netcom.com> Date: Tue, 19 Aug 1997 09:01:09 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Rob Austein Subject: Re: my posting to newdom@ar.com References: <33F86FC0.7FEE@ix.netcom.com> <9708181916.AA20929@ginger.lcs.mit.edu> <9708190227.aa12254@rurha-pente.epilogue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rob, Rob Austein wrote: > > Date: Mon, 18 Aug 1997 16:52:32 +0100 > From: Jeff Williams > > ...Most of the problems with the current DNS problem are NOT policy > issues as I stated fully in my prevuous response to Paul. The > problems of policy revolve around TEHCNICAL problems with .com, > .net and .org and the admisistration of the "Root" in it's legacy > software form currrently. > > So what are these technical problems? Hard to fix 'em without knowing > what they are.... Well if you had been following the lists you would know. But just as a starter here is a list. 1.) Legacy code is no longer scalable under current load. 2.) .com and .net are nearly maxed out. 3.) No truely shared registry code is in use currently. 4.) Zone file is in awful shape. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com --------------65B869C4C04--   Received: from ietf.org by ietf.org id aa13716; 20 Aug 97 14:09 EDT Received: from ginger.lcs.mit.edu by ietf.org id aa13617; 20 Aug 97 14:08 EDT Received: by ginger.lcs.mit.edu id AA25595; Wed, 20 Aug 97 14:08:29 -0400 Date: Wed, 20 Aug 97 14:08:29 -0400 Sender:ietf-request@ietf.org From: Noel Chiappa Message-Id: <9708201808.AA25595@ginger.lcs.mit.edu> To: jwkckid1@ix.netcom.com Subject: Re: my posting to newdom@ar.com Cc: ietf@ietf.org, jnc@ginger.lcs.mit.edu Source-Info: From (or Sender) name not authenticated. From: Jeff Williams > You are repeatedly mentioning "TECHNICAL ISSUES" with no clarification > as if you are assuming that everybody already know (or care) about that > you are referring to. my original post reguarding TECHNICAL ISSUES For those of us who don't recall this message, could you please briefly post what they were? In doing so, please note that most of us consider the following issues: - number of top level domains - how many registries exist for each domain, and how those registries are picked - methods for settling disputes as to who owns which name which seem to be high on the list of those the IAHC tackled, to be not technical issues, but policy matters. Anyway, to the extend there are DNS technical issues (e.g. security), such issues are, as is traditional with the IETF, best handled in a technical WG devoted to DNS - and not by the IETF as a whole. Even for a topics as critical to the continued operation of the Internet as large scale routing issues (and believe me, if your IP datagrams don't get from point A to point B, it doesn't *matter* if the DNS is working or not), the discussion is, by and large, kept in smaller groups *where those who are interested may participate*. Noel   Received: from ietf.org by ietf.org id aa14209; 20 Aug 97 14:29 EDT Received: from rip.psg.com by ietf.org id aa14145; 20 Aug 97 14:28 EDT Received: by rip.psg.com id m0x1FUE-0007zWC; Wed, 20 Aug 97 11:28 PDT (Smail3.1.29.1#1) Message-Id: Date: Wed, 20 Aug 97 11:28 PDT Sender:ietf-request@ietf.org From: Randy Bush To: Ruediger Volk Cc: ietf@ietf.org Subject: Re: my posting to newdom@ar.com References: <16130.872099445@kronos.NIC.DTAG.DE> Source-Info: From (or Sender) name not authenticated. >> I think it would be beneficial if the IEFT held an emergancy workshop >> about the DNS. > I'm not aware that "the IETF" holds workshops - at least I cannot remember > any over the 8 years I've been watching IETF mailings lists and attending > meetings. Ruediger, he said IEFT, that's the Idiotic Ersatz Trolling Fools. You bought the troll. Install procmail now. Do not respond to the garbage, it detracts from useful work. randy   Received: from cnri by ietf.org id aa15446; 20 Aug 97 15:22 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA21411; Wed, 20 Aug 1997 15:25:14 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id MAA05626 for cat-ietf-redist; Wed, 20 Aug 1997 12:48:33 -0400 (EDT) Message-Id: <199708201648.AA19556@world.std.com> To: cat-ietf@mit.edu Cc: linn@world.std.com Subject: DRAFT minutes for CAT-WG Munich meeting Date: Wed, 20 Aug 1997 12:48:25 -0400 From: John Linn Precedence: bulk DRAFT minutes from Munich CAT meeting; please send any comments or corrections to the list NLT Tuesday, 26 August, in order that they can be reflected in a timely submission to the IETF Secretariat. ----- Notes from Common Authentication Technology (CAT) meeting, Munich IETF, 13 August 1997, compiled by John Linn (with thanks to Rich Graveman (Bellcore) for access to his notes from the session and to Cliff Neuman (ISI) for providing copies of his presentation slides in text form). The CAT WG met for one session at the Munich IETF. REVIEW OF ONGOING WORK ITEMS: FTP SECURITY FTP Security (draft-ietf-cat-ftpsec-09) is in IESG hands and had been inadvertently delayed in its IESG consideration, but is reportedly on the agenda to be considered for Proposed Standard status at the next IESG conference call. REVIEW OF ONGOING WORK ITEMS: GSS-V2 AND C BINDINGS Re GSS-V2, the proposed approach is to integrate the RFC2078bis changes list into an updated GSS-V2 base Internet-Draft during September, and then (following a WG Last-Call period) to submit the resulting RFC2078bis and the GSS C bindings as an aligned set to the IESG, requesting their advancement to Proposed Standards; this proposed approach was acceptable to session attendees. No more than very minor changes to the C bindings are anticipated. REVIEW OF ONGOING WORK ITEMS: SNEGO Approximately 6 attendees indicated that they had reviewed draft-ietf-cat-snego-06; approximately 15 indicated familiarity with this or previous snego versions. It had been believed that draft-ietf-cat-snego-06 represented WG consensus for advancement, but Marc Horowitz (Cygnus) and Bill Sommerfeld (HP) indicated a position that draft-ietf-cat-snego-06 does not reflect previously established WG consensus in certain areas, and were to detail the specifics of their dissent to the WG list during the IETF meeting week. No other snego-related comments were indicated in the session. Follow-up discussion is underway on the mailing list. FTP AND DSA, KEA/SKIPJACK William Nace (NSA) presented a pair of recently-distributed documents, concerning, respectively, FTP with DSA (draft-ietf-cat-ftpdsaauth-00-txt), and FTP with KEA/Skipjack algorithms (draft-ietf-cat-ftpkeaskj-00.txt). Other contributors include Peter Yee and Russ Housley. Given the status of KEA/Skipjack (currently classified), the document authors are targeting this document for informational status. Discussion within the session suggested informational status for the DSA document as well, but (given the fact of unconstrained DSA specification) the DSA document could be admissible for subsequent standards-track consideration by the WG. Approximately three attendees indicated familiarity with the drafts; a concern was indicated that the algorithms applied may constitute national-level solutions. The DSA draft provides FIPS-196 authentication for FTP. Unilateral DSA signature-based authentication is used. The KEA/Skipjack draft provides confidentiality for both the data and command streams; labels are also implemented. Encrypted data are base-64 encoded. KERBEROS PK-INIT AND PK-CROSS Brian Tung (ISI) presented and discussed the recently-revised kerberos-pk-init and kerberos-pk-cross drafts. Brian noted that Kerberos open issues are being identified at http://gost.isi.edu/info/kerberos. KERBEROS PK-INIT AND PK-CROSS: PK-INIT Approximately 4 attendees indicated they had read pk-init-04; approximately 15 were familiar with one or more pk-init versions. Document contributors include Ari Medvinsky and Matt Hur (CyberSafe), Jon Trostle (Novell), Brian Tung and Cliff Neuman (ISI), and John Wray (Digital). In draft-ietf-cat-kerberos-pk-init-04, a convention was added for translating between X.500 and Kerberos names. Mike Swift (Microsoft) questioned why base-64 encoding was applied in name translation rather than using the new name type being defined in 1510bis. Ted Ts'o (MIT) observed that the base-64 approach avoids the need to recognize X.500 semantics within Kerberos. In pk-init-04, a client's realm comes from a certificate, not a KDC. A client's principal name also comes from a certificate. A KDC's principal name was added as an X.509 v3 attribute. Diffie-Hellman specification was imported from PKCS #3, specification was added for checksummed encryption, and more specific errors were defined. Support within pk-init for SPEKE, an algorithm with which approximately 3 attendees indicated familarity, had been proposed on the mailing list. Ted Ts'o believed that SPEKE was patent-pending, but terms were unknown; Cliff Neuman believed that patent or patent-pending status should not be a bar to consideration as long as an algorithm's implementation is not mandatory for conformance with the specification. Brian Tung is to continue discussion of SPEKE on the mailing list. Mike Swift observed that Microsoft's CAPI supports PKCS formats rather than bare-level public-key encryption, and would like to be able to support pk-init functions with PKCS-level objects. Ted Ts'o agreed that this suggestion appeared reasonable, noting the broad existing base of code supporting PKCS formats. Brian Tung will raise this issue to the list for further discussion. A suggestion was made that use of X.509 AltSubjectName be considered. KERBEROS PK-INIT AND PK-CROSS: PK-CROSS Brian Tung described draft-ietf-cat-kerberos-pk-cross-02 as including minor changes relative to its predecessor. Approximately 2 attendees indicated that they had read pk-cross-02; approximately 7 indicated familiarity with one or more pk-cross revisions. In pk-cross-02, the remote realm now determines the lifetime of a shared key. Matt Hur has suggested using pk-init to do pk-cross, which would be a major change. Mike Swift noted that Microsoft was evaluating usage of DNS as a means to locate KDCs; this was considered to be a form of existing practice which may warrant codification in RFC1510bis. Mike Swift also reiterated his recommendation, as made relevant to pk-init, to allow public-key operations to be performed using PKCS objects. KERBEROS-REVISIONS (RFC1510BIS) Cliff Neuman (ISI) discussed status and issues relative to the Kerberos RFC1510bis document, draft-ietf-cat-kerberos-revisions-00. Approximately 4 attendees indicated that they had reviewed this draft. Changes and issues had previously been summarized to the CAT list. It was noted in discussion that the currently pending issues list includes the addition of key derivation procedures for 3DES support. Document-related comments were solicited, to krb-protocol@mit.edu for protocol-related issues and via http://gost.isi.edu/info/kerberos (as also used for pk-init, pk-cross, and pktapp). An HTML/SGML version is in progress, targeted for completion by 1 September; its content will correspond to a new I-D (kerberos-revisions-01) to be submitted. As revisions of the HTML versions proceed, corresponding I-Ds will also be issued and will remain authoritative. Major changes considered since the kerberos-revisions-00 I-D, and discussed at the session, are: - Authorization data field: Elements are of type AuthorizationData (new terminology). New element types include: kdc-issued (checksummed with application server's key, vouched for by the KDC of that application server's realm), intended-for-server and intended-for-application-class (identifying targets or sets thereof for which a ticket is intended), if-relevant, and Boolean combinations of authorization elements ("or" is currently proposed; "and" was considered appropriate as well). If a kdc-issued element occurs in an inter-realm environment, a receiving KDC reads and (if acceptable) reissues the element; it is not passed through without reissuance and, were a passed-through element to occur, that element would be ignored. Each of the intended-for-server, intended-for-application-class, and if-relevant attribute types carries a sequence of elements. If intended-for-server or intended-for-application-class attributes are not understood at a targeted recipient, their enclosing ticket is to be rejected; if received elsewhere, they may be ignored. If if-relevant attributes are not understood at a targeted recipient, they may be ignored. In the interests of simplicity, and without perceived loss of needed function, it was agreed in discussion that kdc-issued should be limited to appear at the top nesting level only, and should not nest recursively. Backwards compatibility with existing code incapable of recognizing these newly-defined elements was considered important; Cliff Neuman is to propose text to the mailing list discussing the circumstances under which these elements should be included. One suggestion was that they be included at the level of a ticket element. - Extensions field to ticket: This is an optional sequence, allowing additional data to be linked to the ticket so that it follows the ticket throughout the system. It is located in a ticket's cleartext portion at the end of the ticket, is typed opaque, is linked from within the authorization data field, and contains a flag as to whether it is OK to be removed. It can be used for PK-CROSS to distribute the inter-realm key, or can be used to distribute authorization data which is integrity protected but not confidential, plaintext ticket data, or accompanying authorization credentials. Placement of the extensions field in the ticket's cleartext portion allows unnecessary encryption of ancillary data to be avoided. - Optional client version in pre-auth: This identifies the version of kinit, in a manner considered analogous to an HTTP version string. The intended concept is to use this for backwards compatibility when changes are made. These numbers are not registered and vendor dependent; vendors or users of this field are admonished to pick version identifiers unlikely to conflict with those of other vendors. No corresponding server version identfier is provided, so as not to advertise known and exploitable bugs. RFC2078BIS, RFC1964 ISSUES John Linn led discussion on some specific issues related to RFC2078bis and RFC1964. Specific items cited: Re sequence number setup in RFC1964, John Wray's working proposal for the context acceptor to use the initiator's ISN in the single-hop case was accepted (recognizing that a separate reflection indicator is included in the protocol). Re gss_display_status and CONTINUE_NEEDED: some clarification was desired as to whether these can be used together or not. Some existing implementations return CONTINUE_NEEDED when iterating through successive messages returned from gss_display_status, but this had not been contemplated in RFC-2078. The sense of the discussion was that CONTINUE_NEEDED should be returned only by gss_init_sec_context and gss_accept_sec_context; this intent (along with commentary on the residual portability issue) should be cited in RFC-2078bis and defensive callers should ignore CONTINUE_NEEDED if returned by calls other than gss_init_sec_context and gss_accept_sec_context. If a name is imported with an unrecognized mechanism, GSS_S_BAD_MECH status is to be returned. RFC-2078 contains MIT arc OIDs for some, but not all, of the generic name types; this was considered benign and the sense of the discussion was to retain these OIDs to avoid backward compatibility issues. For the case of host-based service, where an IANA arc OID had been assigned for use in preference to its predecessor MIT arc OID, it was recommended that both OIDs be accepted with equivalent effect but that the MIT arc OID be emitted on output. RFC-2078bis needs (per discussion re snego) to add facilities for informatory conf_req, integ_req inputs to gss_init_sec_context. The conjunction of supplementary info bits and non-zero routine errors was discussed briefly. The goal is to tighten up the list of possible cases. This topic was deferred to discussion on the list. RFC1964 EXTENSIONS Mike Swift solicited interest in two possible areas of extension to RFC-1964, user-user authentication and initial authentication via a dial-up access server. Mike noted that user-user authentication would be useful for DCOM, and suggested support for Kerberos user-user authentication as a submechanism within RFC-1964. Marc Horowitz believed that it would be more appropriately supported as a separate mechanism with its own OID; snego could be used to select between RFC-1964 Kerberos and a user-user mechanism. Generic resolution of name discovery for the user-user environment was believed to be a difficult issue, but there appeared to be interest in investigating and potentially drafting a specification for user-user authentication support. Mike also solicited interest in specification of initial authentication via a dial-up server (as in pktapp), where an initial request is forwarded through an access server. Ted Ts'o commented that Derek Atkins' Charon thesis had addressed essentially this problem some years previously. OTHER DISCUSSION Bengt Ackzell (Generic Systems) noted that, per the Memphis CAT minutes, IDUP had been planned for placement into WG Last Call following the Munich meeting if no comments were pending. Recent IDUP on-list discussion has been quiet, the base specification has not been recently revised, and issuance of corresponding C bindings remains pending. Upon further review, it appeared that further revision or on-list discussion of pending comments was needed before proceeding. --jl   Received: from ietf.org by ietf.org id aa16939; 20 Aug 97 16:09 EDT Received: from rover.cygnus.com by ietf.org id aa16866; 20 Aug 97 16:07 EDT Received: (from marc@localhost) by rover.cygnus.com (8.8.5/8.6.12) id QAA11945; Wed, 20 Aug 1997 16:08:02 -0400 (EDT) To: Ned Freed Cc: ietf@ietf.org Subject: Re: Internet-drafts still not accepting documents after Munich meeting References: <01IMNOSX49QI94E6GE@INNOSOFT.COM> Sender:ietf-request@ietf.org From: Marc Horowitz Date: 20 Aug 1997 16:08:02 -0400 In-Reply-To: Ned Freed's message of Wed, 20 Aug 1997 09:15:50 -0700 (PDT) Message-ID: Lines: 13 X-Mailer: Gnus v5.3/Emacs 19.34 Source-Info: From (or Sender) name not authenticated. Ned Freed writes: >> I've always regarded the inability to send in drafts during IETF >> week as rather silly -- don't we all have mail systems that queue >> up messages for us? This current behavior, however, I regard as >> unacceptable and I would like to see it fixed ASAP. Someone sees those messages, as I sent mail to internet-drafts@ietf.org in the week before IETF (to complain about bugs in the MIME formatting) and I got a response. I assumed that message was more like a vacation response than a bounce. Marc   Received: from ietf.org by ietf.org id aa17770; 20 Aug 97 16:39 EDT Received: from merit.edu by ietf.org id aa17693; 20 Aug 97 16:37 EDT Received: from Bill.Simpson.DialUp.Mich.Net (pm036-09.dialip.mich.net [141.211.7.51]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA24692 for ; Wed, 20 Aug 1997 16:37:56 -0400 (EDT) Date: Wed, 20 Aug 97 20:05:10 GMT Sender:ietf-request@ietf.org From: William Allen Simpson Message-ID: <6442.wsimpson@greendragon.com> To: ietf@ietf.org Subject: Re: Internet-drafts still not accepting documents after Munich meeting Source-Info: From (or Sender) name not authenticated. Yes, I got stung by this change last December IETF, things that didn't make the deadline (by minutes) for one reason or another were not posted. But at least _now_ there is a message -- in December they just disappeared. And speaking of things that disappeared -- I had at least one draft that was sent over 3 hours before the deadline this time, that was never posted, and I never received a message about it either! And I also have some drafts ready to go now.... They should go back to queuing, with an automated message saying when they receive a draft, and with a vacation alternate that says it will not be processed until after such and such a date. > From: Ned Freed > As it often the case, I have a flock of new Internet Draft documents I'd like > to post as a result of feedback I've received from the Munich IETF. I like to > get this done quickly before I and others become entangled in other matters and > lose focus on progress made during the meeting. >... > The message indicates that new drafts would be accepted on or after August > 18. It is now August 20 and I still get this message back. > > I've always regarded the inability to send in drafts during IETF week as rather > silly -- don't we all have mail systems that queue up messages for us? This > current behavior, however, I regard as unacceptable and I would like to see it > fixed ASAP. > WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from ietf.org by ietf.org id aa18041; 20 Aug 97 16:48 EDT Received: from ns1.vrx.net by ietf.org id aa17978; 20 Aug 97 16:47 EDT Received: from mbv1-ipl-ri22.kos.net(really [206.186.41.49]) by vrx.net via sendmail with smtp id for ; Wed, 20 Aug 1997 16:47:59 -0400 (EDT) (Smail-3.2.0.92 1997-Feb-9 #2 built 1997-Apr-8) Message-Id: Date: Wed, 20 Aug 1997 16:47:59 -0400 (EDT) X-Sender: richard@vrx.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Ruediger Volk Sender:ietf-request@ietf.org From: "Richard J. Sexton" Subject: Re: my posting to newdom@ar.com Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 07:50 PM 8/20/97 +0200, Ruediger Volk wrote: > > I think it would be beneficial if the IEFT held an emergancy workshop > > about the DNS. >I'm not aware that "the IETF" holds workshops - at least I cannot remember >any over the 8 years I've been watching IETF mailings lists and attending >meetings. This is very true, but doesnt mean it couldn't or shouldn't happen. >Please remember that the IETF actually does it's work in it's working groups >which in fact are constituted by the membership of their mailing lists >while the WG sessions at the meetings are only considered as a special >way for having very intense discussion within a subset of the WG members. This, also is understood; the work that has gone on ni mailing lists so far has brought us to where we are. Much more gets done in person and sometimes this needs to be done. That there are IEFT physical meetings serves as proof of this. >I don't think that any of the existing working groups would be right >for holding that workshop (I don't think it would fit well any WG's charter). This is nt a reson to not do it. >Please think a bit more specific about what you actually mean by "the IETF >holds a workshop" (and you certainly would be more specific as to the >topic(s) of the workshop than "about the DNS"): > >- how large an attendance do you think about? 30 - 300 I would expect. >- how close would you want it to resemble > (a) the merged WG mailing lists? > (b) the attendance of the regular IETF meetings? > (c) the IESG with special guests? > (d) the IAB with special guests? > (e) the IANA with special guests? > (f) any set of specific WGs? which? The answer to the above is "don't care". >- do you think (a) or (b) are achievable? (I don't think so) Yes, I do. Everytime a conference or workshop on the DNS is announced the attendance just goes up. I believe this situation has now reached critical mass (especially with no followon to the NSF/NSI cooperative agreement) and this is an appropriate action. >- do you think that's reasonable to achive (f) if the workshop topic is not > really on the WG's charters? (I have the feeling you want the topic > of the workshop to be something not > on any current charter) If some people get together with a common interest to solve a common problem is is a de facto working group. The formalization of that is rather irrellavent. >- would you talk about (c) to (e) as "the IETF holds a workshop"? > (I'd rather say "the I > holds a workshop" - and by the > way some I indeed seem > to do workshops once in a while) It's planned, it's announced, it's attended. It comes up with some r results which are jusdged on their merit. ISP assocations all over the world are now doing this. The research and education commnity that used to run the net is now taking a proactive back seat to commercial forward movement. > > 3 Days ought to do it. One day to recap wherere we > > are right now and what has happened. One day to synthesis a more > > palettable solution, one day to review and refine it. >"The IETF" never works this way - not even for it's own technical subject area >- and it's just not possible to get to the IETF style "rough consensus" >with this arrangement and timeframe - and no "running code" either. >Or are you expecting results that don't match IETF style? >Why would you expect the IETF to be able/good to achive something >outside the style, the culture, or procedures of "the IETF"? Plenty of poeple have running code :-) I agree the format is a little unusual, but this does not mean it cannot acheive goals set out for it. >As the word "foolish" has been mentioned already and critized as being used >by an IETF member I'd like to note, that I'm painfully aware that it may be >foolish of me to contribute this comment to this discussion. >To limit my foolishness and the consumption of time I'll keep it to a single >message in this thread. Trying to fix things is not foolish. Trying to break or prevent them is. If you ask the man that created the Intellectual Infrastructute Fund where 30% of the domain name fees have been going, you will get a passionate reponse about keeping the IEFT processes "pure" and free from proprieory intererests, and the vision of thsat fund to to provide for workshops and small research grants to further internet development. That the NSF will probably fund the staging of such a workshop is not relevant, it's something that needs to be tried. Better to try and fail, then never try.   Received: from cnri by ietf.org id aa18797; 20 Aug 97 17:18 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA21886; Wed, 20 Aug 1997 17:21:24 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id PAA23530 for cat-ietf-redist; Wed, 20 Aug 1997 15:41:10 -0400 (EDT) Message-Id: <413F344AD0FBD01186D40060976782F70811CC@nile.spyrus.com> From: "Yee, Peter" To: cat-ietf@mit.edu Subject: RE: DRAFT minutes for CAT-WG Munich meeting Date: Wed, 20 Aug 1997 12:45:52 -0700 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Precedence: bulk >FTP AND DSA, KEA/SKIPJACK >The DSA draft provides FIPS-196 authentication for FTP. Unilateral >DSA signature-based authentication is used. The KEA/Skipjack draft >provides confidentiality for both the data and command streams; labels >are also implemented. Encrypted data are base-64 encoded. Actually, the DSA signature authentication can be either unilateral or mutual. We only showed the unilateral case to conserve time in the slot. -Peter Yee yee@spyrus.com   Received: from ietf.org by ietf.org id aa19315; 20 Aug 97 17:36 EDT Received: from THOR.INNOSOFT.COM by ietf.org id aa19252; 20 Aug 97 17:34 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IMNRQWPEWW94EOAF@INNOSOFT.COM> for ietf@ietf.org; Wed, 20 Aug 1997 14:34:55 PDT Date: Wed, 20 Aug 1997 14:30:52 -0700 (PDT) Sender:ietf-request@ietf.org From: Ned Freed Subject: Re: Internet-drafts still not accepting documents after Munich meeting In-reply-to: "Your message dated Wed, 20 Aug 1997 16:08:02 -0400" To: Marc Horowitz Cc: ietf@ietf.org Message-id: <01IMNZNEJY8O94EOAF@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <01IMNOSX49QI94E6GE@INNOSOFT.COM> Source-Info: From (or Sender) name not authenticated. > > > I've always regarded the inability to send in drafts during IETF > > > week as rather silly -- don't we all have mail systems that queue > > > up messages for us? This current behavior, however, I regard as > > > unacceptable and I would like to see it fixed ASAP. > Someone sees those messages, as I sent mail to > internet-drafts@ietf.org in the week before IETF (to complain about > bugs in the MIME formatting) and I got a response. I assumed that > message was more like a vacation response than a bounce. First of all, thanks are due to Marcia Beaulieu, who earlier sent me mail saying that the problem is now fixed. And it does seem to be. Second, both the automatic response as well as Marcia's response to me clearly indicate that resubmission is required. This, to me, qualifies as a "bounce", not a "vacation notice". It doesn't matter to me whether or not someone is reading my earlier messages if I have to resubmit them to get them posted. Ned   Received: from ietf.org by ietf.org id aa20305; 20 Aug 97 18:06 EDT Received: from callandor.cybercash.com by ietf.org id aa20072; 20 Aug 97 18:05 EDT Received: by callandor.cybercash.com; id RAA01524; Wed, 20 Aug 1997 17:53:26 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma001515; Wed, 20 Aug 97 21:53:07 GMT Received: by cybercash.com (4.1/SMI-4.1) id AA13990; Wed, 20 Aug 97 17:59:17 EDT Date: Wed, 20 Aug 1997 17:59:16 -0400 (EDT) Sender:ietf-request@ietf.org From: "Donald E. Eastlake 3rd" To: ietf@ietf.org Subject: Re: Internet-drafts still not accepting documents after Munich meeting In-Reply-To: <6442.wsimpson@greendragon.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Wed, 20 Aug 1997, William Allen Simpson wrote: > Date: Wed, 20 Aug 97 20:05:10 GMT > From: William Allen Simpson > To: ietf@ietf.org > Subject: Re: Internet-drafts still not accepting documents after Munich meeting > > Yes, I got stung by this change last December IETF, things that didn't > make the deadline (by minutes) for one reason or another were not > posted. But at least _now_ there is a message -- in December they just > disappeared. > > And speaking of things that disappeared -- I had at least one draft that > was sent over 3 hours before the deadline this time, that was never > posted, and I never received a message about it either! There was a machine crash. > And I also have some drafts ready to go now.... > > They should go back to queuing, with an automated message saying when > they receive a draft, and with a vacation alternate that says it will > not be processed until after such and such a date. Enough things are changed by decisions made during an IETF meeting that automatic queueing of drafts received during the meeting strikes me as a bad idea. Even areas without a WG meeting scheduled frequently have some hallway discussions. > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html WARNING, on 4 Sep 1997, +1-508 will change to +1-978.   Received: from ietf.org by ietf.org id aa21505; 20 Aug 97 18:54 EDT Received: from jekyll.piermont.com by ietf.org id aa21422; 20 Aug 97 18:52 EDT Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.6/8.6.12) with SMTP id SAA04469; Wed, 20 Aug 1997 18:52:35 -0400 (EDT) Message-Id: <199708202252.SAA04469@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "Richard J. Sexton" cc: Ruediger Volk , ietf@ietf.org Subject: Re: my posting to newdom@ar.com In-reply-to: Your message of "Wed, 20 Aug 1997 16:47:59 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 20 Aug 1997 18:52:30 -0400 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. "Richard J. Sexton" writes: > >I'm not aware that "the IETF" holds workshops - at least I cannot remember > >any over the 8 years I've been watching IETF mailings lists and attending > >meetings. > > This is very true, but doesnt mean it couldn't or shouldn't happen. Mr. Sexton, the IETF is a voluntary organization. The members have decided they don't want to address the issue. You have no way to force them to do so. You are free to found another organization consisting of people of a different opinion. Now, could you please stop broadcasting this topic to thousands of uninterested IETF members who have decided they don't want to deal with this issue? Perry   Received: from ietf.org by ietf.org id aa21917; 20 Aug 97 19:06 EDT Received: from ns1.vrx.net by ietf.org id aa21844; 20 Aug 97 19:05 EDT Received: from mbv1-ipl-ri3.kos.net(really [206.186.41.41]) by vrx.net via sendmail with smtp id for ; Wed, 20 Aug 1997 19:06:17 -0400 (EDT) (Smail-3.2.0.92 1997-Feb-9 #2 built 1997-Apr-8) Message-Id: Date: Wed, 20 Aug 1997 19:06:17 -0400 (EDT) X-Sender: richard@vrx.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: perry@piermont.com Sender:ietf-request@ietf.org From: "Richard J. Sexton" Subject: Re: my posting to newdom@ar.com Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 06:52 PM 8/20/97 -0400, Perry E. Metzger wrote: Hi Perry. How come I'm "Mr. Sexton" all of a sudden? Is this sme newfound Euro manners ? :-) >Mr. Sexton, the IETF is a voluntary organization. The members have >decided they don't want to address the issue. You have no way to force >them to do so. You are free to found another organization consisting >of people of a different opinion. Now, could you please stop >broadcasting this topic to thousands of uninterested IETF members who >have decided they don't want to deal with this issue? Good point. Now how do you suggest the IETF members who are interested in the issue organize?   Received: from ietf.org by ietf.org id aa22187; 20 Aug 97 19:16 EDT Received: from jekyll.piermont.com by ietf.org id aa22094; 20 Aug 97 19:14 EDT Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.6/8.6.12) with SMTP id TAA04597; Wed, 20 Aug 1997 19:14:27 -0400 (EDT) Message-Id: <199708202314.TAA04597@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: "Richard J. Sexton" cc: perry@piermont.com, ietf@ietf.org Subject: Re: my posting to newdom@ar.com In-reply-to: Your message of "Wed, 20 Aug 1997 19:06:17 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 20 Aug 1997 19:14:27 -0400 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. "Richard J. Sexton" writes: > >Mr. Sexton, the IETF is a voluntary organization. The members have > >decided they don't want to address the issue. You have no way to force > >them to do so. You are free to found another organization consisting > >of people of a different opinion. Now, could you please stop > >broadcasting this topic to thousands of uninterested IETF members who > >have decided they don't want to deal with this issue? > > Good point. Now how do you suggest the IETF members who are interested > in the issue organize? I SUGGEST THEY ORGANIZE SOMEWHERE ELSE. Please stop bothering the IETF list with this. Perry   Received: from ietf.org by ietf.org id aa22360; 20 Aug 97 19:21 EDT Received: from ns1.vrx.net by ietf.org id aa22314; 20 Aug 97 19:21 EDT Received: from mbv1-ipl-ri3.kos.net(really [206.186.41.41]) by vrx.net via sendmail with smtp id for ; Wed, 20 Aug 1997 19:21:57 -0400 (EDT) (Smail-3.2.0.92 1997-Feb-9 #2 built 1997-Apr-8) Message-Id: Date: Wed, 20 Aug 1997 19:21:57 -0400 (EDT) X-Sender: richard@vrx.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: perry@piermont.com Sender:ietf-request@ietf.org From: "Richard J. Sexton" Subject: Re: my posting to newdom@ar.com Cc: perry@piermont.com, ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 07:14 PM 8/20/97 -0400, Perry E. Metzger wrote: > >"Richard J. Sexton" writes: >> >Mr. Sexton, the IETF is a voluntary organization. The members have >> >decided they don't want to address the issue. You have no way to force >> >them to do so. You are free to found another organization consisting >> >of people of a different opinion. Now, could you please stop >> >broadcasting this topic to thousands of uninterested IETF members who >> >have decided they don't want to deal with this issue? >> >> Good point. Now how do you suggest the IETF members who are interested >> in the issue organize? > >I SUGGEST THEY ORGANIZE SOMEWHERE ELSE. With all due respect, Perry, you have a bit of a vested interest here, and if it's unanimous that no IETF'ers want to do anything I'll understand, but I wasn't aware your voice was authoratative for all of the IETF.   Received: from ietf.org by ietf.org id aa02618; 20 Aug 97 23:28 EDT Received: from email.archlab.tuwien.ac.at by ietf.org id aa02486; 20 Aug 97 23:23 EDT Received: by email.archlab.tuwien.ac.at (950413.SGI.8.6.12/940406.SGI.AUTO) id FAA16082; Thu, 21 Aug 1997 05:23:33 +0200 Date: Thu, 21 Aug 1997 05:23:32 +0200 (MDT) Sender:ietf-request@ietf.org From: Sascha Ignjatovic To: ietf@ietf.org Subject: to much trafic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. may i ask why i got all this last mails wich are for its own "to much trafic" double and tripple sascha   Received: from ietf.org by ietf.org id aa06153; 22 Aug 97 9:26 EDT Received: from ietf.ietf.org by ietf.org id aa05538; 22 Aug 97 9:07 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: mobile-ip@smallworks.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mobileip-tunnel-reverse-04.txt Date: Fri, 22 Aug 1997 09:07:22 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708220907.aa05538@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Reverse Tunneling for Mobile IP Author(s) : G. Montenegro Filename : draft-ietf-mobileip-tunnel-reverse-04.txt Pages : 19 Date : 1997-08-20 Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-tunnel-reverse-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-tunnel-reverse-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-tunnel-reverse-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821133050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-tunnel-reverse-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-tunnel-reverse-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821133050.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06175; 22 Aug 97 9:26 EDT Received: from ietf.ietf.org by ietf.org id aa05490; 22 Aug 97 9:04 EDT To: ietf-announce@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-costales-subscribe-01.txt Date: Fri, 22 Aug 1997 09:04:14 -0400 Sender:ietf-announce-request@ietf.org From: Cynthia Clark Message-ID: <9708220904.aa05490@ietf.org> ------Included Message--- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : E-Mail Headers to Facilitate Mailing List Subscriptions and Unsubscriptions Author(s) : B. Costales Filename : draft-costales-subscribe-01.txt Pages : 4 Date : 1997-08-19 The number of ways to subscribe-to (and to unsubscribe-from) e-mail mailing lists is as varied as the number of programmers designing mailing list software. For some lists, for example, users (un)subscribe by sending a request to -request@host.domain. For others lists the address is majordomo@host.domain with the request to (un)subscribe embedded in the message body. Yet others set up special hosts to satisfy this need, such as @list-off.domain. In this Internet Draft we offer two new e-mail headers intended to make mailing list subscription and unsubscription easier and more uniform: List-Subscribe and List-Unsubscribe. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-costales-subscribe-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-costales-subscribe-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-costales-subscribe-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821130232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-costales-subscribe-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-costales-subscribe-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821130232.I-D@ietf.org> --NextPart --OtherAccess   Received: from ietf.org by ietf.org id aa06173; 22 Aug 97 9:26 EDT Received: from ietf.ietf.org by ietf.org id aa05636; 22 Aug 97 9:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: madman@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-madman-nsm-mib-06.txt Date: Fri, 22 Aug 1997 09:10:05 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708220910.aa05636@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mail and Directory Management Working Group of the IETF. Title : Network Services Monitoring MIB Author(s) : S. Kille, N. Freed Filename : draft-ietf-madman-nsm-mib-06.txt Pages : 21 Date : 1997-08-20 A networked application is a realization of some well defined service on one or more host computers that is accessible via some network, uses some network for its internal operations, or both. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-madman-nsm-mib-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-madman-nsm-mib-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-madman-nsm-mib-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821130337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-madman-nsm-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-madman-nsm-mib-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821130337.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06160; 22 Aug 97 9:26 EDT Received: from ietf.ietf.org by ietf.org id aa05815; 22 Aug 97 9:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-discov-atmarp-00.txt Date: Fri, 22 Aug 1997 09:14:38 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708220914.aa05815@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : ILMI-Based Server Discovery for ATMARP Author(s) : M. Davison Filename : draft-ietf-ion-discov-atmarp-00.txt Pages : 6 Date : 1997-08-20 This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM address of servers, shall be used to locate ATMARP servers. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-discov-atmarp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-discov-atmarp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-discov-atmarp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821132734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-discov-atmarp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-discov-atmarp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821132734.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06159; 22 Aug 97 9:26 EDT Received: from ietf.ietf.org by ietf.org id aa05670; 22 Aug 97 9:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: madman@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-madman-mail-monitor-mib-05.txt Date: Fri, 22 Aug 1997 09:10:21 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708220910.aa05670@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mail and Directory Management Working Group of the IETF. Title : Mail Monitoring MIB Author(s) : S. Kille, N. Freed Filename : draft-ietf-madman-mail-monitor-mib-05.txt Pages : 32 Date : 1997-08-20 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-madman-mail-monitor-mib-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-madman-mail-monitor-mib-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-madman-mail-monitor-mib-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821130415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-madman-mail-monitor-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-madman-mail-monitor-mib-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821130415.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06162; 22 Aug 97 9:26 EDT Received: from ietf.ietf.org by ietf.org id aa05797; 22 Aug 97 9:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-discov-mars-00.txt Date: Fri, 22 Aug 1997 09:14:36 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708220914.aa05797@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : ILMI-Based Server Discovery for MARS Author(s) : M. Davison Filename : draft-ietf-ion-discov-mars-00.txt Pages : 6 Date : 1997-08-20 This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM address of servers, shall be used to locate MARS servers. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-discov-mars-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-discov-mars-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-discov-mars-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821132909.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-discov-mars-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-discov-mars-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821132909.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06642; 22 Aug 97 9:45 EDT Received: from ietf.ietf.org by ietf.org id aa06526; 22 Aug 97 9:40 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-costales-subscribe-01.txt (re-send) Date: Fri, 22 Aug 1997 09:40:41 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708220940.aa06526@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : E-Mail Headers to Facilitate Mailing List Subscriptions and Unsubscriptions Author(s) : B. Costales Filename : draft-costales-subscribe-01.txt Pages : 4 Date : 1997-08-19 The number of ways to subscribe-to (and to unsubscribe-from) e-mail mailing lists is as varied as the number of programmers designing mailing list software. For some lists, for example, users (un)subscribe by sending a request to -request@host.domain. For others lists the address is majordomo@host.domain with the request to (un)subscribe embedded in the message body. Yet others set up special hosts to satisfy this need, such as @list-off.domain. In this Internet Draft we offer two new e-mail headers intended to make mailing list subscription and unsubscription easier and more uniform: List-Subscribe and List-Unsubscribe. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-costales-subscribe-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-costales-subscribe-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-costales-subscribe-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821130232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-costales-subscribe-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-costales-subscribe-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821130232.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa13498; 22 Aug 97 15:30 EDT Received: from mail1.bellatlantic.net by ietf.org id aa13317; 22 Aug 97 15:24 EDT Received: from default (client200-191-193.bellatlantic.net [151.200.191.193]) by mail1.bellatlantic.net (8.8.5/8.8.5) with SMTP id OAA29316 for ; Fri, 22 Aug 1997 14:26:22 -0500 (EST) Message-ID: <33FDE429.7294@bellatlantic.net> Date: Fri, 22 Aug 1997 15:10:34 -0400 Sender:ietf-request@ietf.org From: Rigault Reply-To: rigault@bellatlantic.net X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ietf@ietf.org Subject: Remove Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa13505; 22 Aug 97 15:30 EDT Received: from ietf.ietf.org by ietf.org id aa13203; 22 Aug 97 15:20 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-freed-firewall-req-00.txt Date: Fri, 22 Aug 1997 15:20:19 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221520.aa13203@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Internet Firewall Transparency Requirement Author(s) : N. Freed, K. Carosso Filename : draft-freed-firewall-req-00.txt Pages : 8 Date : 21-Aug-97 This memo defines a basic transparency requirement for Internet firewalls. While such a requirement may seem obvious, the fact of the matter is that firewall behavior is currently either unspecified or underspecified, and problems often arise in practice. This document is intended to be a necessary first step in making the behavior of firewalls more consistent and correct. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-freed-firewall-req-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-freed-firewall-req-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-freed-firewall-req-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821142414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-freed-firewall-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-freed-firewall-req-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821142414.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa16255; 22 Aug 97 17:20 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA28889 for ; Fri, 22 Aug 1997 17:23:22 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA06509; Fri, 22 Aug 1997 17:19:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 22 Aug 1997 17:15:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA06425 for ietf-ppp-outgoing; Fri, 22 Aug 1997 17:15:03 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA06417 for ; Fri, 22 Aug 1997 17:14:58 -0400 (EDT) Received: from ietf.ietf.org by ietf.org id aa15338; 22 Aug 97 17:13 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-05.txt Date: Fri, 22 Aug 1997 17:13:52 -0400 Message-ID: <9708221713.aa15338@ietf.org> Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol "L2TP" Author(s) : A. Valencia, K. Hamzeh, W. Verthein, W. Townsley, T. Kolar, M. Littlewood, G. Pall, B. Palter, J. Taarud Filename : draft-ietf-pppext-l2tp-05.txt Pages : 82 Date : 1997-08-21 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2tp-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821135419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821135419.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa16313; 22 Aug 97 17:21 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA28895; Fri, 22 Aug 1997 17:24:57 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id QAA01793 for cat-ietf-redist; Fri, 22 Aug 1997 16:12:15 -0400 (EDT) To: cat-ietf@mit.edu Subject: Comments on snego-06 From: Marc Horowitz Date: 22 Aug 1997 16:12:14 -0400 Message-Id: Lines: 57 X-Mailer: Gnus v5.3/Emacs 19.34 Precedence: bulk The snego-06 draft still has several problems. Some are technical, others are just editorial. ** Severe technical problems (I believe these must be fixed before we go to last call): In section 2, there is still text about specifying a single option to a mechanism by adding to the end of the mech OID. I thought this was going to be removed. This technique has two problems. First, if you want to specify two options, you can't. Second, there is nothing preventing the owner of a bit of OID arc from defining two mechanisms having OID's A.B.C.D and A.B.C.D.E. This makes it impossible to distinguish the second mechanism from the first mechanism with option E. In general, if we want to have a protocol for specifying mechanism options outside the mechanism, I think we should do so in such a way which does not require use of snego. Section 3.1 describes the policy for the acceptor to choose a mechanism. I thought we had decided that policy issues were a local matter. Section 3.2: if the acceptor does not understand the negotiation mechanism, GSS_S_BAD_MECH, not GSS_S_FAILURE, should be returned. In the current text, the mechListMic is only in the NegTokenTarg, not in the NegTokenInit. This means that if the client provides the last token, then an additional message is necessary, just to carry the MIC. This is wasteful; mechListMIC should be in NegTokenInit, and the MIC should be in the same message as the final preferredToken, whether generated by the initiator or acceptor. ** Minor technical problems (I believe these should be fixed, but they won't break the spec in any significant way if not): The negResult field is unnecessary. The initiator can determine if the acceptor accepted a mechanism by checking for the presence of the supportedMech field. Even if it was necessary, having two accept values is redundant, as the initiator can tell from the underlying mechanisms's return value from GSS_Init_sec_context if additional further are necessary. What is MechSpecInfo used for? I'd like to hear a concrete example about how it is intended to be used, or see it removed from the draft. As far as I can tell, whenever this sort of functionality might be needed, it should be inside the preferredToken, and invisible to snego. ** Editorial issues: In section 2, the draft describes negotiation tokens as "new GSS-API context-level tokens". This is not accurate; they are simply mechanism context-level tokens, like any other. Appendix A: the functions' descriptions should explain how the cred_handle is used by them. Marc   Received: from ietf.org by ietf.org id aa16586; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15636; 22 Aug 97 17:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-allman-ftp-variable-05.txt Date: Fri, 22 Aug 1997 17:14:46 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221714.aa15636@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : FTP Extensions for Variable Protocol Specification Author(s) : S. Ostermann, M. Allman Filename : draft-allman-ftp-variable-05.txt Pages : 6 Date : 1997-08-21 The specification for the File Transfer Protocol assumes that the underlying network protocols use a 32-bit network address and a 16-bit transport address (specifically IP version 4 and TCP). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over a variety of network and transport protocols. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allman-ftp-variable-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-allman-ftp-variable-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-allman-ftp-variable-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821151533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allman-ftp-variable-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-allman-ftp-variable-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821151533.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16594; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15819; 22 Aug 97 17:15 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rem-conf@es.net Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-info-repair-00.txt Date: Fri, 22 Aug 1997 17:14:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221715.aa15819@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Options for Repair of Streaming Media Author(s) : C. Perkins Filename : draft-ietf-avt-info-repair-00.txt Pages : 8 Date : 21-Aug-97 This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-info-repair-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-info-repair-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-info-repair-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821150522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-info-repair-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-info-repair-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821150522.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16608; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15691; 22 Aug 97 17:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-tag-stack-03.txt Date: Fri, 22 Aug 1997 17:14:54 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221714.aa15691@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Label Switching: Label Stack Encodings Author(s) : Y. Rekhter, D. Farinacci, T. Li, A. Conta, D. Tappan, E. Rosen, G. Fedorkow Filename : draft-rosen-tag-stack-03.txt Pages : 19 Date : 1997-08-21 'Multi-Protocol Label Switching (MPLS)' [1,2,9] requires a set of procedures for augmenting network layer packets with 'label stacks' (sometimes called 'tag stacks'), thereby turning them into 'labeled packets'. Routers which support MPLS are known as 'Label Switching Routers', or 'LSRs'. In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on PPP data links and on LAN data links. This document also specifies rules and procedures for processing the various fields of the label stack encoding. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-tag-stack-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rosen-tag-stack-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rosen-tag-stack-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821152617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-tag-stack-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-tag-stack-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821152617.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16603; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15817; 22 Aug 97 17:15 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-asid@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-asid-ldapv3-url-04.txt Date: Fri, 22 Aug 1997 17:14:06 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221715.aa15817@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access, Searching and Indexing of Directories Working Group of the IETF. Title : The LDAP URL Format Author(s) : T. Howes, M. Smith Filename : draft-ietf-asid-ldapv3-url-04.txt Pages : 8 Date : 21-Aug-97 LDAP is the Lightweight Directory Access Protocol, defined in [1], [2] and [3]. This document describes a format for an LDAP Uniform Resource Locator. The format describes an LDAP search operation to perform to retrieve information from an LDAP directory. This document replaces RFC1959. It updates the LDAP URL format for version 3 of LDAP and clarifies how LDAP URLs are resolved. This document also defines an extension mechanism for LDAP URLs, so that future documents can extend their functionality, for example, to provide access to new LDAPv3 extensions as they are defined. The key words 'MUST', 'MAY', and 'SHOULD' used in this document are to be interpreted as described in [6]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-asid-ldapv3-url-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-asid-ldapv3-url-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-asid-ldapv3-url-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821143853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-asid-ldapv3-url-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-asid-ldapv3-url-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821143853.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16609; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15602; 22 Aug 97 17:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-allman-ftp-sec-consider-02.txt Date: Fri, 22 Aug 1997 17:14:40 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221714.aa15602@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : FTP Security Considerations Author(s) : S. Ostermann, M. Allman Filename : draft-allman-ftp-sec-consider-02.txt Pages : 5 Date : 21-Aug-97 The specification for the File Transfer Protocol contains a number of mechanisms that can be used to compromise network security. The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force 'password guessing' attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-allman-ftp-sec-consider-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-allman-ftp-sec-consider-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-allman-ftp-sec-consider-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821151334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-allman-ftp-sec-consider-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-allman-ftp-sec-consider-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821151334.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16576; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15306; 22 Aug 97 17:13 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pfenning-irc-extensions-02.txt Date: Fri, 22 Aug 1997 17:13:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221713.aa15306@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the Internet Relay Chat Protocol (IRCX) Author(s) : T. Pfenning, K. Cedola, L. Dusseault Filename : draft-pfenning-irc-extensions-02.txt Pages : 39 Date : 1997-08-21 This document describes extensions to the Internet Relay Chat (IRC) protocol defined in RFC 1459[1]. Only client-server interactions are defined. The added functionality includes optional user authentication for multiple security providers, support for UNICODE[2] characters, multilayer security, and a unified property mechanism. Chat server implementations can optionally support channel or server services with full control over all messages and events. These services communicate with the core server over an extended IRC connection. All changes to the IRC protocol are designed in a way that existing clients will continue to work against servers implementing the exten- sions. Support for the extended protocol can be queried by clients to take advantage of the added functionality or to conform to the basic protocol as defined in RFC1459. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pfenning-irc-extensions-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-pfenning-irc-extensions-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-pfenning-irc-extensions-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821134621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pfenning-irc-extensions-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-pfenning-irc-extensions-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821134621.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16571; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15257; 22 Aug 97 17:13 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ip1394@mailbag.intel.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ip1394-ipv4-03.txt,.ps Date: Fri, 22 Aug 1997 17:13:36 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221713.aa15257@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over IEEE 1394 Working Group of the IETF. Title : IP over IEEE 1394 (High Performance Serial Bus) Revision 3 Author(s) : P. Johansson Filename : draft-ietf-ip1394-ipv4-03.txt,.ps Pages : 15 Date : 1997-08-21 This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary methods, data structures and code for that purpose and additionally defines a standard method for Address Resolution Protocol (ARP). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ip1394-ipv4-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ip1394-ipv4-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ip1394-ipv4-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821133545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ip1394-ipv4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ip1394-ipv4-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821133545.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16578; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15285; 22 Aug 97 17:13 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kim-jtc1-sc6-ects-02.txt Date: Fri, 22 Aug 1997 17:13:45 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221713.aa15285@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhanced Communications Transport Service Definition Author(s) : D. Kim Filename : draft-kim-jtc1-sc6-ects-02.txt Pages : 78 Date : 1997-08-21 This memo is the final Committee Draft of the Enhanced Transport Service Definition under development within ISO/IEC JTC1/SC6/WG7 since last several years in order to provide to the upper-layer applications enhanced transport services over the current OSI transport service; major enhancements include multicast services and enhanced QoS. This memo is distributed to possibly interested grops within IETF, especially to experts in Transport Area, to make noticed the efforts being made within SC6 to come up with a new transport service definition meeting the wide range of requirements of the both current and future multimedia multicast applications. It is to be noted that a protocol maned ECTP(Enhanced Communications Transport Protocol) supporting this ECTS is also under development within SC6 and will be made public in the near future. Experts interested in this topic might compare the services defined by ECTS with those provided by more known protocols including RTP, MTP, RMP, and RAMP. The ultimate apparent objective of ECTS is the multimedia multicast transport service with varying degrees of reliability and multicast QoS. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kim-jtc1-sc6-ects-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kim-jtc1-sc6-ects-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kim-jtc1-sc6-ects-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821134031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kim-jtc1-sc6-ects-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kim-jtc1-sc6-ects-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821134031.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16602; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15488; 22 Aug 97 17:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-palme-newsmail-00.txt Date: Fri, 22 Aug 1997 17:14:16 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221714.aa15488@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Messages between Email and Netnews Author(s) : J. Palme Filename : draft-palme-newsmail-00.txt Pages : 11 Date : 21-Aug-97 Messages can be transported through gateways between email and netnews. Combined clients for mail and netnews can submit the same message at the same time to email and netnews. Many netnews clients can produce email replies to the author of netnews articles. This standard specifies how to handle these kinds of messages. This standard specifies three new email headers: 'Posted-To', 'Group-Reply-To' and 'Personal-Reply-To'. Further discussions on this memo should take place in the mailing-list MAILNEWS-L@SEGATE.SUNET.SE. More info in the full text of this memo or at URL http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newsharmony. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-palme-newsmail-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-palme-newsmail-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-palme-newsmail-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821145058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-palme-newsmail-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-palme-newsmail-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821145058.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16583; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15522; 22 Aug 97 17:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mailext-new-fields-09.txt Date: Fri, 22 Aug 1997 17:14:21 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221714.aa15522@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Auto-Submitted, Supersedes and Expires E-mail Headers Author(s) : J. Palme Filename : draft-ietf-mailext-new-fields-09.txt Pages : 7 Date : 21-Aug-97 This memo introduces three new e-mail (RFC 822) headers, Auto-Submitted, Supersedes, and Expires. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mailext-new-fields-09.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-new-fields-09.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mailext-new-fields-09.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821145308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mailext-new-fields-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mailext-new-fields-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821145308.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16604; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15432; 22 Aug 97 17:14 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-baer-listspec-01.txt Date: Fri, 22 Aug 1997 17:14:03 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221714.aa15432@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields Author(s) : J. Baer, G. Neufeld Filename : draft-baer-listspec-01.txt Pages : 12 Date : 1997-08-21 The mailing list command specification header fields are a simple set of fields to be added to email messages sent by email distribution lists. Each field contains a URL (usually mailto) locating the relevant information or performing the command directly. The three core header fields described in this document are List-Help, List-Subscribe, and List-Unsubscribe. There are three other header fields described here which, although not as widely applicable, will have utility for a sufficient number of mailing lists to justify their formalization here. These are List-Post, List-Owner and List-Archive. By including these header fields, mail clients can provide automated tools for performing these functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-baer-listspec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-baer-listspec-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-baer-listspec-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821143548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-baer-listspec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-baer-listspec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821143548.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16569; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15785; 22 Aug 97 17:15 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: drums@cs.utk.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-drums-MHRegistry-01.txt Date: Fri, 22 Aug 1997 17:14:30 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221715.aa15785@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detailed Revision/Update of Message Standards Working Group of the IETF. Title : Mail and Netnews Header Registration Procedure Author(s) : J. Palme Filename : draft-ietf-drums-MHRegistry-01.txt Pages : 9 Date : 21-Aug-97 Various IETF standards and e-mail and netnews software products use various e-mail and netnews header fields. This document specifies a procedure for the registration of e-mail and netnews header field names, to reduce the risk that two different products use the same header name in different ways (homonyms) or that several different header names are used with identical meaning (synonyms). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-drums-MHRegistry-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-drums-MHRegistry-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-drums-MHRegistry-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821145857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-drums-MHRegistry-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-drums-MHRegistry-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821145857.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16567; 22 Aug 97 17:23 EDT Received: from ietf.ietf.org by ietf.org id aa15755; 22 Aug 97 17:15 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: madman@innosoft.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-madman-trackmib-00.txt Date: Fri, 22 Aug 1997 17:15:15 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708221715.aa15755@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mail and Directory Management Working Group of the IETF. Title : Message Tracking MIB Author(s) : B. Ernst, G. Jones, J. Weintraub Filename : draft-ietf-madman-trackmib-00.txt Pages : 32 Date : 21-Aug-97 This document defines a message tracking Management Information Base (MIB) for electronic messaging usage. Message tracking is the ability to find out, after the fact, the path that a particular message took through the messaging system and the current status of that message. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-madman-trackmib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-madman-trackmib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-madman-trackmib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970821153424.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-madman-trackmib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-madman-trackmib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970821153424.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa16949; 22 Aug 97 17:27 EDT Received: from poptart.svr.home.net by ietf.org id aa16887; 22 Aug 97 17:25 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.corp.home.net (Netscape Mail Server v2.02) with ESMTP id AAA6772; Fri, 22 Aug 1997 14:25:09 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id OAA19037; Fri, 22 Aug 1997 14:25:09 -0700 (PDT) Message-Id: <199708222125.OAA19037@lock.eos.home.net> X-Mailer: exmh version 1.6.7 5/3/96 To: ietf@ietf.org cc: scoya@CNRI.Reston.VA.US Subject: Nomination Committee - Second call for Volunteers.. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Aug 1997 14:25:03 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. [Steve - please reflect onto the IETF-Announce list] Hi - As you may or may not know I've been tapped to head this years IAB/IESG nominating committee. This is the second call for volunteers to participate as members of that committee. If you would like to volunteer, please send me email (to stjohns@corp.home.net) with the phrase "NOMCOM VOLUNTEER" (yes - all caps) in your subject line indicating your desire to participate. Please include your snail mail and phone numbers in the body of the message. To be eligible to serve on the NOMCOM, you must have attended 2 of the last 3 IETFs. Please make sure you can spend the time required to serve. Although there won't be any face to face meetings except for the December IETF, you will have to spend about 2 hours a week on the phone during the 12 active weeks of the nominations process (starting around the December IETF) in teleconferences with the entire nominations committee. You'll also be assigned various candidates to interview as part of the nominations process. Third and last call for volunteers will be next Wednesday, the 27th of August. Cutoff for accepting volunteers will be as of 1600 PDT on the 29th of August - specifically, they have to be in my email box at that time. Once I've got the complete list of volunteers, I'll post it and also ask that the Secretariat verify eligibility. The 10 members will be selected by lot based on the sales volume of 11 stocks as of the NASDAQ market close on 19 September as reported in the San Jose Mercury News on 20 September 1997. The procedure is as follows: 1) The Secretariat will provide the final list of eligibles listed in alphabetical order and numbered from 0 sequentially increasing and will mail this to the IETF and IETF-Announce list on or before the 17th of September. 2) The sales volume figure for the NASDAQ most active stock on the 19th of Sept will be used to provide an initial offset into the list. The 10,000s and 1,000s digit from the volume figure will be used to generate a "random" number from 00 to 99 (e.g. if the sales figure is 345,009,234 shares, the number is 09). The actual offset into the list is calculated as volnumber**5 mod the length of the list. So if the volume number is 9, the length of the list is 47, the offset would be 17. 3) Each stock in turn will then be used to select a nomcom member from the list by using the same procedure of extracting the 10,000 and 1000 digits, raising them to the 5th power, adding that to the current position number and then taking that mod the length of the list. So if the first of the listed stocks sales figure was 45,923,213 and the length of the list were 47 as above, then the volume number would be 23, and the final position on the list would be (17 + 23**5) mod 47 or 39. The person with the number 39 (remembering that the list is numbered from 0 this is actually the 40th person) would become the first member. 4) Step three is repeated continuing from the current position on the list until all 10 members are selected. 5) In the event that there is a duplicate selection,simply continue down the list sequentially until you find a person who has not been selected. Continue the process from that position on the list. 6) If the most active stock is also one of the stocks I list for the selection, it will be used twice, once for the initial offset, and once for selecting a member. 7) The figures as reported in the SJMercury News are the official figures. In the event of a disagreement between the numbers in the SJMercury and any other publication, the SJMercury figures will be considered correct. 8) If any stock is not listed in the 20 September 1997 edition of the paper, it will be replaced in order by one of the alternate stocks IN ITS PLACE - e.g. the other stocks on the list will retain their specific positions, rather than having the stock deleted and having the alternate stock added to the end of the list. 9) The list of stocks is as follows: Member 1) Apple Computer (reported as AppleC) 2) @Home Corporation (reported as AtHome) 3) Cisco Systems (reported as Cisco) 4) Cyber Cash (reported as CybrCsh) 5) Excite (reported as Excite) 6) Intel (reported as Intel) 7) MCI (reported as MCI) 8) Microsoft (reported as Microsft) 9) Netcom (reported as Netcom) 10) Netscape (reported as Netscpe) Alternate 1) Quantum 2) 3Com 3) Yahoo   Received: from ietf.org by ietf.org id aa18179; 22 Aug 97 18:21 EDT Received: from merit.edu by ietf.org id aa17981; 22 Aug 97 18:11 EDT Received: from Bill.Simpson.DialUp.Mich.Net (pm036-00.dialip.mich.net [141.211.7.42]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA07486 for ; Fri, 22 Aug 1997 18:11:16 -0400 (EDT) Date: Fri, 22 Aug 97 20:53:13 GMT Sender:ietf-request@ietf.org From: William Allen Simpson Message-ID: <6452.wsimpson@greendragon.com> To: ietf@ietf.org Subject: Re: my posting to newdom@ar.com Source-Info: From (or Sender) name not authenticated. Resend of Date: Thu, 21 Aug 97 14:35:22 GMT > From: "Richard J. Sexton" > At 07:14 PM 8/20/97 -0400, Perry E. Metzger wrote: > >I SUGGEST THEY ORGANIZE SOMEWHERE ELSE. > > With all due respect, Perry, you have a bit of a vested interest > here, and if it's unanimous that no IETF'ers want to do anything > I'll understand, but I wasn't aware your voice was authoratative for > all of the IETF. > Sexton (I am neither presuming that you are male or female, and have no need of an "honorific" in any case, since your balderdash is egregiously without honor or respect): The IETF "authority" for liaisons with other groups, known as the IAB, with the advice and concurrance of active and interested IETF members and several years of internal discussion, has already organized such a group in the past. It was called the IAHC. It is finished. Perry Metzger, an active and interested IETF participant, was appointed (among others) to represent us in that effort. We trust that he has done so to the best of his ability. There is no known reason why the IETF, IRTF, IANA, IAB, or ISoc, would organize yet another group to scrutinize the results of its previous efforts. Once is enough. Volunteer time is limited. Moreover, the results of the IAHC have been ratified by the IETF "authority" for liaisons with other groups through a Memorandum of Understanding. If some other group is organized, it is unlikely to be part of the established IETF structure. Unless coercive force is used, it is unlikely to have any effect on IETF activities. I _suggest_ they organize somewhere else. As an active and interested IETF member, I _demand_ that you stop this barrage of pointless and irritating messages that are outside the scope of the IETF list. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from cnri by ietf.org id aa19189; 22 Aug 97 19:26 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA29295; Fri, 22 Aug 1997 19:29:30 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id RAA10072 for cat-ietf-redist; Fri, 22 Aug 1997 17:35:10 -0400 (EDT) Message-Id: <199708222134.RAA00455@thunk.ch.apollo.hp.com> X-Authentication-Warning: thunk.ch.apollo.hp.com: sommerfeld owned process doing -bs To: Marc Horowitz Cc: cat-ietf@mit.edu Subject: Re: Comments on snego-06 In-Reply-To: marc's message of 22 Aug 1997 16:12:14 -0400. Date: Fri, 22 Aug 1997 17:34:38 -0400 From: Bill Sommerfeld Precedence: bulk First, I would like to apologize for not having had the time to review snego-06 until the time of the meeting in munich; unfortunately, since the last IETF, my job has involved very little work related to GSSAPI or other CAT-area standards. I agree with substantially everything Marc has to say regarding problems with '06. (I don't agree completely about the precise priority of all the technical issues, but agree that all of his issues are legitimate). Something appears to have been "lost in translation" from the changes which Denis and I agreed on in Memphis and what was subsequently published in -06. Most importantly, the showstopper issue is that -06 adds an unnecessary message to the exchange if the last message in the underlying mechanism is in the initiator->acceptor direction. while I don't have my notes handy, if I recall correctly, the `mechListMic OPTIONAL' field was present in both message types (or perhaps in all messages save the first, with the 2nd and subsequent i->a messages using NegTokenTarg to encapsulate the inner mechanism; I believe we discussed both possibilities). - Bill   Received: from ietf.org by ietf.org id aa19380; 22 Aug 97 19:41 EDT Received: from zephyr.isi.edu by ietf.org id aa19297; 22 Aug 97 19:38 EDT Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 22 Aug 1997 16:38:35 -0700 Message-Id: <199708222338.AA18927@zephyr.isi.edu> To: IETF-Announce: ; To: Internet-Monthly-Report-People: ; Subject: Internet Monthly Report for July, 1997 Cc: imr-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Date: Fri, 22 Aug 97 16:42:42 PDT Sender:ietf-announce-request@ietf.org From: IMR Editor --NextPart The Internet Monthly Report for July, 1997 is now available at the following location: URL= ftp://ftp.isi.edu/in-notes/imr/imr9707.txt The Internet Monthly Report (IMR) is normally distributed via EMail to the IMR list and the IETF list. For most readers this is the most convenient way to receive the report. However, there are some mail systems or mail gateways that do not accommodate large messages (some issues of the IMR are more than 100,000 characters). Readers that do not receive the IMR via the normal distribution may obtain copies via FTP or EMail retrieval. Requests to be added or deleted from the IMR report list: The Internet Monthly Report list is managed by MajorDomo atISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be added or deleted from the Internet Monthly report list should be sent to majordomo@isi.edu with the message body either subscribe imr or unsubscribe imr. Requests to be added or deleted from the IETF list should be sent to ietf-request@ietf.org. Internet Monthly Report availability via WWW, FTP and EMAIL: IMR Retrieval using WWW ----------------------- The URL below may be used in web browsers to access the IMRs. You will see a list of names in the form IMR9707.TXT. For example, IMR9707.TXT is the report for July 1997. URL: ftp://ftp.isi.edu/in-notes/imr IMR Retrieval using EMAIL via the RFC-INFO Service -------------------------------------------------- The EMail retrieval system RFC-Info will send a large report in segments in separate EMail messages not exceeding 50,000 characters each. Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_imrs. For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs IMR Retrieval using FTP ----------------------- IMRs are available via anonymous FTP from FTP.ISI.EDU, with the pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of the IMR. For example IMR9707.TXT is the report for July 1997). Login with FTP username anonymous and password ftp. IMR retrieval using MIME ------------------------ Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retreive the current IMR. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="rfc-info@isi.edu" Content-Type: text/plain Retrieve: imr Doc-ID: imr9707 --OtherAccess Content-Type: Message/External-body; name="imr9707.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes/imr" Content-Type: text/plain --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19573; 22 Aug 97 19:49 EDT Received: from zephyr.isi.edu by ietf.org id aa19451; 22 Aug 97 19:47 EDT Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 22 Aug 1997 16:47:19 -0700 Message-Id: <199708222347.AA19446@zephyr.isi.edu> To: ietf@ietf.org, imr@isi.edu Subject: Internet Monthly Report for July, 1997 Cc: imr-ed@isi.edu Date: Fri, 22 Aug 97 16:51:26 PDT Sender:ietf-request@ietf.org From: IMR Editor Source-Info: From (or Sender) name not authenticated. July 1997 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. Each organization is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via network mail to "IMR-ED@ISI.EDU". ````````````````````````````````````````````````````````````````````` The Internet Monthly Report mailing list is now managed by MajorDomo at ISI.EDU. The announcements of new issues on the Internet Monthly Report are sent to the IETF-Announce list and to this IMR list. Requests to be ADDED or DELETED from the Internet Monthly report list should be sent to "majordomo@isi.edu" with the message body either "subscribe imr" or "unsubscribe imr". Details on obtaining the current IMR, or back issues, via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info@ISI.EDU" with the message body "help: ways_to_get_imrs". For example: To: rfc-info@ISI.EDU Subject: getting imrs help: ways_to_get_imrs or URL: http://www.isi.edu/in-notes/imr/ IMR Editor [Page 1] Internet Monthly Report July 1997 TABLE OF CONTENTS INTERNET ARCHITECTURE BOARD IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3 INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3 Internet Projects INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 19 Registration Services . . . . . . . . . . . . . . . . . page 19 Directory Services. . . . . . . . . . . . . . . . . . . page 19 US Domain Registry. . . . . . . . . . . . . . . . . . . page 20 MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 23 UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 25 IANA REPORT . . . . . . . . . . . . . . . . . . . . . . . page 25 RFC EDITOR REPORT . . . . . . . . . . . . . . . . . . . . page 26 200z CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 27 TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 31 SOFTBANK Forums. . . . . . . . . . . . . . . . . . . . . . page 31 IMR Editor [Page 2] Internet Monthly Report July 1997 INTERNET ARCHITECTURE BOARD The minutes of the IAB back to 1990 are available for anonymous ftp access on host ftp.isi.edu, directory /pub/IAB, or via the IAB World-Wide Web page with URL http://www.iab.org/iab/. Brian Carpenter IAB Chair INTERNET ENGINEERING REPORTS ---------------------------- Internet Monthly Report for July, 1997 1. As I write this, we are about to leave for the IETF Meeting in Munich, Germany. Our hosts for this meeting Digi/ISOC.DE. The final meeting of the year will be held in Washington, DC from December 8-12, 1997. Our local host is Newbridge Networks. The IETF will meet in Los Angeles from March 30 - April, 3, 1998 and then in Chicago August 24-28. We're still looking into the final meeting of 1998. Once all arrangements have been made, notifications will be sent to the IETF Announcement list. Remember that information on future meetng sites can always be found in the file 0mtg-sites.txt, located on the IETF shadow directories. Of course, this information is provided on the Web. The IETF's URL is: http://www.ietf.org/ 2. The minutes of the IESG teleconferences be found on all the IETF shadow directories in the iesg directory. The following IESG minutes have been added: June 5, 1997 (iesg.97-06-05) July 10, 1997 (iesg-97-07-10) 3. The IESG approved or recommended the following 13 Protocol Actions during the month of July, 1997: o Selection and Operation of Secondary DNS Servers for publication as a Best Current Practices RFC. IMR Editor [Page 3] Internet Monthly Report July 1997 o SMTP Service Extension for Command Pipelining for publication as a Draft Standard. o Routing Aspects Of IPv6 Transition for publication as an Informational RFC. o VENUS - Very Extensive Non-Unicast Service for publication as an Informational RFC. o Review of Roaming Implementations for publication as an Informational RFC. o Application of Internet Cache Protocol (ICP), version 2 for publication as an Informational RFC. o The "data" URL scheme for publication as a Proposed Standard. o Clarifications to the DNS Specification for publication as a Proposed Standard. o IMAP URL Scheme for publication as a Proposed Standard. o MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations for publication as a Proposed Standard. o Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field for publication as a Proposed Standard. o IMAP4 Mailbox Referrals for publication as a Proposed Standard. o IMAP4 Multi-Accessed Mailbox Practice (None) 4. Four Last Calls were issued by the IESG during the month of July, 1997: o Simple Authentication and Security Layer (SASL) for consideration as a Proposed Standard. o Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 for consideration as a Proposed Standard. IMR Editor [Page 4] Internet Monthly Report July 1997 o Simple Hit-Metering and Usage-Limiting for HTTP for consideration as a Proposed Standard. o Compressing IP/UDP/RTP Headers for Low-Speed Serial Links for consideration as a Proposed Standard. 5. Six new working groups were created TCP Over Satellite (tcpsat) IP Payload Compression Protocol (ippcp) Transaction Internet Protocol (tip) IP Over IEEE 1394 (ip1394) PSTN and Internet Internetworking (pint) Uniform Resource Locator Registration Procedures (urlreg) 6. There were 284 Internet-Draft Actions during the month of July, 1997: (idmr) o Internet Group Management Protocol MIB (idmr) o Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification -- (none) o Photuris: Session Key Management Protocol (none) o The Auto-Submitted, Supersedes and Expires E-mail Headers (ion) o NHRP Protocol Applicability Statement (ipsec) o Internet Security Association and Key Management Protocol (ISAKMP) (intserv) o Specification of Guaranteed Quality of Service (none) o Loop control for the Auto-Submitted e-mail header (rsvp) o RSVP Cryptographic Authentication (ion) o IP Broadcast over ATM Networks (cat) o The Simple and Protected GSS-API Negotiation Mechanism (ssh) o Site Security Handbook IMR Editor [Page 5] Internet Monthly Report July 1997 (asid) o A MIME Content-Type for Directory Information (grip) o Expectations for Security Incident Response (receipt) o An Extensible Message Format for Message Disposition Notifications (intserv) o General Characterization Parameters for Integrated Service Network Elements (rsvp) o RSVP Management Information Base (intserv) o Integrated Services Management Information Base (ion) o Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (http) o PEP - an Extension Mechanism for HTTP (dhc) o An Extension to the DHCP Option Codes (dhc) o An option for FQDNs in DHCP options (ipsec) o The OAKLEY Key Determination Protocol (dnsind) o Selection and Operation of Secondary DNS Servers (http) o Transparent Content Negotiation in HTTP (pppext) o PPP LCP Extensions (asid) o Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions (asid) o Lightweight Directory Access Protocol (v3) (drums) o Augmented BNF for Syntax Specifications: ABNF (atommib) o Definitions of Managed Objects for the SONET/SDH Interface Type (none) o Photuris: Extended Schemes and Attributes (none) o IANA Charset Registration Procedures (ion) o Transient Neighbors for IPv6 over ATM (none) o TFTP Blocksize Option IMR Editor [Page 6] Internet Monthly Report July 1997 (mhtml) o Sending HTML in E-mail, an informational supplement to RFC ???: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML) (ipsec) + The ESP Triple DES Transform (none) o Using the MARS model in non-ATM NBMA networks. (ipsec) o IP Authentication Header (issll) o Providing integrated services over low-bitrate links (pppext) o Point-to-Point Tunneling Protocol--PPTP (ipsec) o The resolution of ISAKMP with Oakley (ipngwg) o IPv6 Router Alert Option (roamops) o Dialup Roaming Requirements (none) o Redundant MARS architectures and SCSP (none) o SMTP Service Extension for Command Pipelining (none) o SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over IEEE 802-style networks (none) o Internet Calendar Access Protocol (ICAP) (ediint) o Requirements for Inter-operable Internet EDI (intserv) o The Use of RSVP with IETF Integrated Services (bmwg) o Benchmarking Terminology for LAN Switching Devices (none) o Domain Names and Company Name Retrieval (issll) o The Multi-Class Extension to Multi-Link PPP (none) o The TACACS+ Protocol Version 1.77 (none) o Network Ingress Filtering: Defeating IP Source Address Spoofing Denial of Service Attacks (none) o A Method for the Transmission of IPv6 Packets over ARCnet Networks. (none) o IMAP URL Scheme IMR Editor [Page 7] Internet Monthly Report July 1997 (ipngwg) o IPv6 Multicast Address Assignments (none) o Advanced Sockets API for IPv6 (ediint) o MIME-based Secure EDI (none) o NNTP LIST Additions (rmonmib) o Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0 (none) o Wrapping MIME Objects: Application/MIME (http) o Simple Hit-Metering and Usage-Limiting for HTTP (frnetmib) o Management Information Base for Frame Relay Data Compression (http) o Feature Tag Registration Procedures (none) o Universal Format for Logger Messages (tls) o Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) (roamops) o The Network Access Identifier (none) o DHCP Options for Novell Directory Services (none) o PF_KEY Key Management API, Version 2 (radius) o Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS (lsma) o Scenarios and Appropriate Protocols for Distributed Interactive Simulation (ssh) o Users' Security Handbook (dhc) o DHCP Option for IEEE 1003.1 POSIX Timezone Specifications (urn) o Guidelines and a Framework for URN Resolution Systems (none) o Representing the Dublin Core within X.500, LDAP and CLDAP (rtfm) o RTFM Working Group - New Attributes for Traffic Flow Measurement (rmonmib) o Remote Network Monitoring MIB Protocol Identifiers IMR Editor [Page 8] Internet Monthly Report July 1997 (vrrp) o Virtual Router Redundancy Protocol (asid) o The LDAP Data Interchange Format (LDIF) - Technical Specification (printmib) o Printer MIB (find) o A Tagged Index Object for use in the Common Indexing Protocol (avt) o Compressing IP/UDP/RTP Headers for Low-Speed Serial Links (asid) o Definition of an Object Class to Hold LDAP Change Records (none) o Internationalization of Domain Names (none) o Flow Grouping For Reducing Reservation Requirements for Guaranteed Delay Service (none) o Telnet Com Port Control Option (harts) o Humanities and Arts: Sharing Center Stage on the Internet (ipngwg) o IP Version 6 over PPP (none) o Multiprotocol Extensions for BGP-4 (dnsind) o Negative Caching of DNS Queries (DNS NCACHE) (none) o Content Duration MIME Header Definition (none) o Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration (none) o VPIM Voice Message MIME Sub-type Registration (none) o Survey of Defined Managed Objects for Applications Management (mixer) o Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) (idr) o A Framework for Inter-Domain Route Aggregation (http) o HTTP Remote Variant Selection Algorithm -- RVSA/1.0 (pppext) o Mobile-IPv4 Configuration Option for PPP IPCP (none) o Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field IMR Editor [Page 9] Internet Monthly Report July 1997 (mixer) o Use of an X.500/LDAP directory to support MIXER address mapping (webdav) o Requirements for Distributed Authoring and Versioning on the World Wide Web (rmonmib) o Remote Network Monitoring Management Information Base for High Capacity Networks (rtfm) o Traffic Flow Measurement: Meter MIB (none) o Scalable support for multi-homed multi-provider connectivity (spki) o Simple Public Key Certificate (run) o DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (Spam*) (fax) o File Format for Internet Fax (http) + Problem with HTTP/1.1 Warning header, and proposed fix (radius) o RADIUS Server MIB (asid) o LDAP Multi-master Replication Protocol (ipngwg) o Transmission of IPv6 Packets over FDDI Networks (ipngwg) o Transmission of IPv6 Packets over Ethernet Networks (radius) o RADIUS Client MIB (none) o RSVP over ATM Implementation Guidelines (qosr) o A Framework for QoS-based Routing in the Internet (none) o S/MIME Message Specification (secsh) o Connect (roamops) o Guidelines for the Secure Operation of RADIUS Proxies in Roaming (tcpimpl) o Known TCP Implementation Problems (issll) o PPP in a real-time oriented HDLC-like framing (pkix) o Internet Public Key Infrastructure Part IV: Certificate Policy and Certification Practices Framework IMR Editor [Page 10] Internet Monthly Report July 1997 (pppext) o PPP over AAL5 and FUNI (secsh) o SSH Transport Layer Protocol (secsh) o SSH Authentication Protocol (aft) o SOCKS Protocol Version 5 (none) o Directory Entries From Email Address (asid) o A Summary of the X.500(96) User Schema for use with LDAPv3 (avt) o RTP Profile for Audio and Video Conferences with Minimal Control (pppext) o PPP LCP CallBack (ipngwg) o Router Renumbering for IPv6 (rsvp) o Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment (asid) o An Approach for Using LDAP as a Network Information Service (find) o Hierarchical Extensions to the Common Indexing Protocol (none) o HTTP based Geo-temporal Searching (HGS). (ipsec) + The ESP RC5-CBC Algorithm (none) o Application of Internet Cache Protocol (ICP), version 2 (snmpv3) o An Architecture for Describing Internet Management Frameworks (ipsec) + The ESP CAST128-CBC Algorithm (urn) o A URN Namespace for IETF Documents (ipngwg) o An IPv6 Aggregatable Global Unicast Address Format (none) o IP Version 6 Addressing Architecture (ipsec) + The ESP DES-CBC Transform (ipngwg) o IPv6 Testing Address Allocation (none) o Plaintext Password SASL Mechanism and Transition Codes IMR Editor [Page 11] Internet Monthly Report July 1997 (none) o The IP Network Address Translator (NAT) (ftpext) o Feature negotiation mechanism for the File Transfer Protocol (none) o Firewall Traversal authorization system (pppext) o Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IPSEC networks (http) o Scenarios for the Delivery of Negotiated Content using HTTP (snmpv3) o View-based Access Control Model for the Simple Network Management Protocol (SNMP) (none) o Application Protocol Design Principles (ipp) o Internet Printing Protocol/1.0: Security (none) + PPP/IPCP Extension for Word Alignment of IP Datagrams (radius) + RADIUS Accounting Interim Accounting Record Extension (ipsec) o IP Security Document Roadmap (ipsec) + The Use of HMAC-SHA-1-96 within ESP and AH (ipsec) + The Use of HMAC-MD5-96 within ESP and AH (ipsec) + The ESP DES-CBC Cipher Algorithm With Explicit IV (ipsec) + ESP with Cipher Block Chaining (CBC) (none) + Analysis of Services and Interfaces used when Interworking Between the Internet and the Intelligent Network (I.N.) (ipsec) + The ESP ARCFOUR Algorithm (asid) + Lightweight Directory Access Protocol: Dynamic Attributes (ipsec) + The ESP DES-XEX3-CBC Transform (mhtml) + MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) (none) + Transaction Internet Protocol - Requirements IMR Editor [Page 12] Internet Monthly Report July 1997 (none) + Advise on the implementation of In-Reply-To, References and Supersedes e-mail and netnews headers (http) o Feature Tag Scenarios (none) + Telnet Remote Serial Port (RSP) Option (ipcdn) + Cable Modem Management Information Base for MCNS compliant Cable Modems (ipcdn) + Radio Frequency (RF) Interface Management Information Base for MCNS compliant RF interfaces (asid) + The vCard Schema For Use In LDAPv3 (none) + Cache Array Routing Protocol v1.0 (none) o Key Exchange Delegation Record for the DNS (none) + The Compressed Payload Header (none) + Internet Technology for Integration of Carrier Network Management (TMN) and Enterprise Network Management (none) + Key Management for Multicast: Issues and Architectures (issll) + RSVP over ATM Implementation Requirements (none) o ODETTE File Transfer Protocol (none) + IPSOFACTO: IP Switching Over Fast ATM Cell Transport (none) + The Site Installation Handbook (none) o A Dictionary Server Protocol (fax) + Capabilities Exchange and Immediate Delivery over ESMTP (cat) + The Kerberos Network Authentication Service (V5) (none) + HTTP/1.1 Message Digest Attribute Request (pppext) + The PPP DES Encryption Protocol, Version 2 (DESE-bis) (ipp) o Mapping between LPD and IPP Protocols IMR Editor [Page 13] Internet Monthly Report July 1997 (none) + IP Multicast over ATM MLIS using ATM Multicast Routers (none) + IP Multicast Routing over ATM (snmpv3) o User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) (tcpimpl) + Some Testing Tools for TCP Implementors (none) + Open Software Distribution Methods (ipp) + Internet Printing Protocol/1.0: Protocol Specification (none) + Path MTU discovery in the presence of security gateways (none) + Why traceroute can not work through IPsec gateways (ipngwg) + TLA and NLA Assignment Rules (none) + NNTP Generic Data Extensions (ippcp) + IP Payload Compression Protocol (IPComp) (ipsec) + The ESP Blowfish-CBC Algorithm Using an Explicit IV (none) + Capabilities Negotiation with BGP-4 (none) + LDAP Object Class for Application Users (pppext) + The PPP Triple-DES Encryption Protocol (3DESE) (ipsec) + The ESP 3DES-CBC Algorithm Using an Explicit IV (idmr) + Core Based Trees (CBT) Multicast Routing MIB (cat) + FTP Authentication Using DSA (cat) + Encryption using KEA and SKIPJACK (ipsec) + The ESP IDEA-CBC Algorithm Using Explicit IV (ipsec) + IP Encapsulating Security Payload (ESP) (none) + ILMI-Based Server Discovery for ATMARP (none) + ILMI-Based Server Discovery for MARS IMR Editor [Page 14] Internet Monthly Report July 1997 (calsch) + iCalendar Transport-Independent Interoperability Protocol (iTIP) Part One: Scheduling Events and BusyTime (calsch) + iCalendar Transport-Independent Interoperability Protocol (iTIP) Part Two: Scheduling To-Dos (calsch) + iCalendar Transport-Independent Interoperability Protocol (iTIP) Part Three - Scheduling Journal Entries (none) + Dynamic Tunneling Path Configuration for Uni-directional Link Routing (none) + An IP tunneling approach for Uni-directional Link routing (none) + Guidelines for Next Hop Client (NHC) developers (avt) + RTP Payload Format for QuickTime Media Streams (aft) + Feature Discovery: A Generic Extension Mechanism for SOCKS Version 5 (dhc) + Netware/IP Domain Name and Information (none) + IMSS: IP Multicast Shortcut Service (issll) + A Framework for Integrated Services and RSVP over ATM (acap) + ACAP Authorization Identifier Datasets (dnssec) + Domain Name System Security Extensions (none) + SOCKS V5 UDP and Multicast Extensions (none) + ESP with Cipher Block CheckSums (CBCS) (asid) + LDAP Replication Requirements (asid) + The Java LDAP Application Program Interface (ipngwg) o IPv6 Name Lookups Through ICMP (mhtml) + Content-ID and Message-ID Uniform Resource Locators (svrloc) + Wide Area Network Service Location (none) + Proposal for SPKI Certificate Formats and Semantics IMR Editor [Page 15] Internet Monthly Report July 1997 (none) + Synchronous IP Switching Protocol (ion) + A Distributed MARS Service Using SCSP (ion) + Intra-area IP unicast among routers over legacy ATM (none) + Guidelines for Writing RFC Text on Security Considerations (none) + Directory Schema Listing Requirements (asid) + Schema for Replication Information (none) + Information Exchange to Be Supported by the Service Support Transfer Protocol (SSTP) (ip1394) o IP over IEEE 1394 (High Performance Serial Bus) Revision 1a (pppext) o PPP Over FUNI (rsvp) + Protocol for Exchange of PoliCy Information (PEPCI) (none) + Internet Email Subaddressing (ipcdn) + IP Over Cable Data Networks - Terms of Reference (acap) + ACAP Personal Addressbook Dataset Class (pppext) + PPP LCP Self Describing Padding (ipngwg) o Neighbor Discovery for IP Version 6 (IPv6) (ipngwg) + IPv6 Stateless Address Autoconfiguration (ipngwg) + Internet Protocol, Version 6 (IPv6) Specification (lsma) + Taxonomy of Communication Requirements for Large-scale Multicast Applications (asid) + LDAP API Extensions for Sort and Simple Paged Results (idr) + Using a Dedicated AS for Sites Homed to a Single Provider (none) + End-to-End Traffic Management Issues in IP/ATM Internetworks (ipngwg) + Site prefixes in Neighbor Discovery (pkix) + Internet Public Key Infrastructure IMR Editor [Page 16] Internet Monthly Report July 1997 (pkix) + Internet Public Key Infrastructure Part V: Time Stamp Protocols (none) + RTP Payload Format for BT.656-3 Encoding (ngtrans) + Site prefixes in Neighbor Discovery (asid) + Referral Whois Protocol (RWhois) 2.0 (none) o A Stream Cipher Encryption Algorithm 'Arcfour' (none) + IPv6 Inverse Neighbor Discovery for IPv6 and IPv4 Tunnels (http) + An Extension to HTTP : Digest Access Authentication (none) + DHCP Server Verification by Client Via DNSSEC (none) + Transmission of IPv6 Packets over Frame Relay (none) + Conversion of MIMEDIR content into XML (issll) + Integrated Service Mappings on IEEE 802 Networks (ippcp) + IP Payload Compression Protocol Architecture (none) + Error Record (ERR) for DNS (dhc) + Subnet Selection Option for DHCP (none) + Scalability Issues in Label Switching over ATM (idr) + Route Aggregation Tutorial (none) + ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering (acap) o ACAP personal options dataset class (none) + HTTP X-Connfrom header (ipsec) + The ESP CAST5-128-CBC Transform (none) + Handling Internationalized Query Components in URLs (none) + Normalization of Internationalized Identifiers (dhc) + Securing DHCP IMR Editor [Page 17] Internet Monthly Report July 1997 (tn3270e) + Definitions of Managed Objects for TN3270E Response Time Collection Using SMIv2 (asid) + The C LDAP Application Program Interface (none) + Universal Forms Description Language Specification Version 3.2 (none) + Universal Forms Description Language Specification Version 3.2 (avt) + RTP Payload for DTMF Digits (svrloc) + Definition of lpr: URLs for use with Service Location (none) + Uniform Resource Locators (URL): DNS URL Naming Scheme 7. Seven RFCs were published during this period RFC2093 E (none) Group Key Management Protocol (GKMP) Specification RFC2094 E (none) Group Key Management Protocol (GKMP) Architecture RFC2170 I (none) Application REQuested IP over ATM (AREQUIPA) RFC2177 PS (none) IMAP4 IDLE command RFC2178 DS (ospf) OSPF Version 2 RFC2179 I (none) Network Security For Trade Shows RFC2180 I (none) IMAP4 Multi-Accessed Mailbox Practice IMR Editor [Page 18] Internet Monthly Report July 1997 INTERNET PROJECTS ----------------- INTERNIC -------- REGISTRATION SERVICES July InterNIC Stats Monthly Registrations: 138,814 Gopher Sessions: 64,418 Retrievals: 8164 WAIS Sessions: 20,017 Retrievals: 12,423 FTP Sessions: 119,307 Retrievals: 201,245 Telnet Sessions: 71,069 HTTP: 13,386,951 Whois Client Queries: 5,153,853 Whois Server Queries: 28,483,417 Updates: 172,397 email: 558,630 Rich Landers INTERNIC DIRECTORY AND DATABASE SERVICES The InterNIC Guide to US Universities is now available at: http://ds.internic.net/aldeau/attframes3.html The Guide can be searched by name of the institution or geographically by state. It provides contact information for the institution including a link to the college's web site. The University Guide was developed by Aldea Communications. IMR Editor [Page 19] Internet Monthly Report July 1997 A reminder - if you would like to help the Internet community find a resource that you offer, send mail to admin@ds.internic.net and we will send information about listing your resource in the Directory of Directories. If you prefer, you can enter information about your resource in our WWW suggestion form. The form can be reached through our Directory of Directories Web page at: http://ds.internic.net:80/ds/dsdirofdirs.html by Rick Huber THE US DOMAIN ============= A total of about 2000 locality domains that were delegated to several domain name managers have been returned to the US Domain administrator. These localities will be made available for redelegation in the coming months. A new policy has been added regarding the locality delegation. For delegations (or redelegations) made after 1-Jul-97, it is assumed by the US Domain Administrator that every applicant for the delegation (or redelegation) of a locality name has the written agreement of the legitimate government for that locality for the applicant to manage the domain name of that locality. Evidience of such an agreement does not need to be presented at the time of delegation (except that the administrative contact on the application template must be the government representative). However, if the delegation is later challenged or contested, the manager of the locality domain must produce the agreement. Failure to do so will most likely result in the transfer of the management of the locality domain to another manager that does have such an agreement. If there is a dispute as to what is the legitimate government for a locality is and who may act for it, the league of cities or association of municipalities of that state (as recognized by the National League of Cities) may be asked to assist in resolving such disputes. In some places there are overlapping jurisdictions with the same name (for example, the city of Los Angeles and the county of Los Angeles). In such cases, the higher level government should have priority. IMR Editor [Page 20] Internet Monthly Report July 1997 The US Domain registration form is now available online at http://www.isi.edu/us-domain. The US Domain has the maps of all the delegated special domains online at http://www.isi.edu/us-domain. The US Domain administrator no longer makes direct registrations of hosts, and only makes delegations of third or fourth level domain names (such as localities). Some of the processing of the requests to the third level domain name is now automated. In particular, most requests to register names in localities already delegated are automatically forwarded to the administrator of that locality. A new policy has been added regarding the charges for the domain name passed on during delegation. The administrator of the locality has to notify one year in advance before charging for those domains. US DOMAIN ADMINISTRATIVE INFORMATION ==================================== EMAIL/FAX 4293 PHONE 500 ---------------------------- Total Contacts 4793 DELEGATIONS: 271 FORWARDED REQUESTS: 1847 OTHER US DOMAIN MSGS:2675 --------------------------- Total 4793 OTHER US DOMAIN MESSAGES include referrals to other subdomains or to/from the InterNic, phone calls, modifications, application requests, discussion and clarification of the requests, questions about names, resolving technical problems with zone files and name servers, and whois listings. IMR Editor [Page 21] Internet Monthly Report July 1997 MAJOR SUBDOMAINS DELEGATED ========================== K12 CC TEC STATE LIB MUS GEN DST COG =================================================================== 52 39 36 47 41 26 28 10 6 =================================================================== THIRD LEVEL DELEGATIONS ======================== GEN.OK.US. General Independent Entities, Oklahoma. LOCALITIES ========== GLOUCESTER.NJ.US. NEW-ORLEANS.LA.US. NAMPA.ID.US. MANHATTAN.KS.US. MERIDIAN.MI.US. BOLTON.VT.US. WESTLAKE-VILLAGE.CA.US. AGOURA-HILLS.CA.US. FRANKLIN.KS.US. WATERFORD.NY.US. BERKELEY-LAKE.GA.US. SWANZEY.NH.US. ALBANY.NH.US. BERKELEY.IL.US. BUTLER.IN.US. PITKIN.CO.US. PEPPERMALL.MA.US. PORT-CLINTON.OH.US. WEBBERVILLE.MI.US. PERRY.MI.US. POTTERVILLE.MI.US. MORRICE.MI.US. DURAND.MI.US. LAINGSBURG.MI.US. BATH.MI.US. FOWLERVILLE.MI.US. PLAQUEMINE.LA.US. FREDON.NJ.US. HAMPTON.NJ.US. OGDENSBURG.NJ.US. STANHOPE.NJ.US. STILLWATER.NJ.US. BEATTYVILLE.KY.US. MAGGIE-VALLEY.NC.US. CASHMERE.WA.US. ADIRONDACK.NY.US. BELLEVUE.OH.US. MILAN.OH.US. VERMILION.OH.US. KENSINGTON.NH.US. SANDWICH.NH.US. STRATFORD.NH.US. BREVARD.FL.US. IMR Editor [Page 22] Internet Monthly Report July 1997 OTHER US DOMAIN DELEGATIONS THIS MONTH ====================================== We delegated 228 4th level domain names this month. URL: http://www.isi.edu/us-domain/ Shanthi Ranganathan (US-Domain@ISI.EDU) MERIT INTERNET ENGINEERING -------------------------- This report summarizes July 1997 activities of Merit's Internet Engineering group on behalf of the Routing Arbiter (RA) service and other projects. Organizations that are peering with the Route Server Next Generation (RSng) project's Route Servers can use a new Web Interface to check the parameters of their peering session: http://www.rsng.net/peer_template/viewconf.html The new form displays public fields in RSng's extended 'inet-rtr' (Internet router) objects, which specify routes that the Route Server should import and export on behalf of each peer. The RSng inet-rtr object, which was developed by Jake Khuon, extends the definition found in the RIPE document, "Specifying an `Internet Router' in the Routing Registry" (RIPE-122). To use the Configuration Viewer to view an RSng inet-rtr object, simply enter the IP address or AS number of the peer you want to obtain information about. The Configuration Viewer only displays public information about routes exchanged with the Route Servers, rather than private network contact information. The Configuration Viewer was developed by Abha Ahuja. ------------------------------------------------------------ Merit is pleased to announce a new, distributed version of its Internet Rover package. Developed by Bill Norton to monitor network devices for the NSFNET project, the Rover code is now used to monitor networks worldwide, including the Italian National Network, the Pentagon Network, and the Princeton Network. IMR Editor [Page 23] Internet Monthly Report July 1997 The previous, centralized Rover code was based on a simple model: if a device failed a test, an alert would be displayed at the Network Operations Center. NOC operators would then investigate the cause of the failed test and take any necessary action. When the test succeeded, the alert would be removed. Over the past ten years, Merit programming staff have worked with many network operators to evolve the software package to meet their needs. The latest release, Internet Rover 4.0, introduces the notion of distributed "Area Managers" into the model. The Area Managers, which perform tests and maintain a list of alerts on remote systems, use an SNMP agent to externalize the list of alerts to the Central Network Management Stations (CNMS). In this way, the Distributed Rovers can be deployed and connected across a wide-area network. Locating the Area Managers topologically closer to the devices being monitored decreases the likelihood of packet loss from intermediate network failures, and lowers network management bandwidth requirements. In addition, the Distributed Rovers can be split along administrative boundaries, such as AS's, making it possible for networks to share aggregated network management information. NOCs can then "view" one another's alert screens, making it much easier to operate backup NOCs and share NOC services. For more information about the new Rover code, see: http://www.merit.edu/internet.tools/rover/ A new mailing list provides a forum for user feedback to the Rover developers. To join, send e-mail to majordomo@merit.edu with 'subscribe your.email.address rover@merit.edu' (without the quotes) as the only text. ------------------------------------------------------------ Engineer Craig Labovitz and Merit President Eric Aupperle attended an Internet Service Quality Workshop sponsored by Bellcore, which featured presentations on future differentiated services for the Internet. Bill Norton, Jake Khuon, and Abha Ahuja of the RSng staff attended a PacBell NAP open house. Route Servers managed by the Route Server Next Generation project (www.rsng.net/) are up and running at the Digital Internet Exchange and the AADS, MAE-West, MAE-East interconnection points, in addition to the PacBell NAP. Susan R. Harris (srh@merit.edu) IMR Editor [Page 24] Internet Monthly Report July 1997 UCL ---- Main work this month was with SAIC on testing a research reliable multicast protocol, over the CAIRN. Paper based on work has been submitted to INFOCOM 98. John Crowcroft (j.crowcroft@CS.UCL.AC.UK) IANA REPORT ----------- IANA Monthly Report - July 1997 BOOTP-DHCP Extension Codes 8 Cable Address Blocks 2 Country Codes 2 DHCP Options 2 INT Domains 1 MIME Media Types 2 Multicast Addresses: Individual Ass. 2 Novell SAP Numbers 1 PPP Field Assignments 1 Private Enterprise Numbers 70 Port Assignments 48 Protocol Type/Field Assignments 2 SMI Numbers 5 SOCKS Methods 3 Telnet Options 3 Josh Elliott (elliott@isi.edu) IMR Editor [Page 25] Internet Monthly Report July 1997 RFC EDITOR REPORT ----------------- This is a summary of Request for Comments Editor activity for the month of July, 1997: TIME IN QUEUE DOCUMENTS New* 30 days 60 days 90 days TOTAL ------------------------------------------------------------------ | Beginning of 0 8 13 6 | 27 month | | New 22 0 0 0 | 22 | | Processed 6 4 5 3 | 18 ------------------------------------------------------------------ | End of month 16 4 8 3 | 31 * New RFCs added to queue throughout the month The Requests for Comments (RFCs) are a series of notes, started in 1969, about the Internet (originally the ARPANET). The notes discuss many aspects of computing and computer communication focusing in networking protocols, procedures, programs, and concepts, but also including meeting notes, opinion, and sometimes humor. The specification documents of the Internet protocol suite, as defined by the Internet Engineering Task Force (IETF) and its steering group (the IESG), are published as RFCs. RFCs-to-be are edited by the RFC Editor. RFCs enter the RFC Editor's work queue either by an action of the IESG or by independent submission. Most independent submissions are referred to the IESG to check for overlap with IETF work. The IESG might put a hold on a document to gather more input from its members. The wait for an RFC to be published varies as there can be unforeseen complications (typically editorial matters that need clarification from the author). Documents can be removed from the publication queue if they are found to be insufficient or incorrect or if the IESG asks the author to join work already in progress in the IETF. Mary Kennedy (rfc-ed@isi.edu) IMR Editor [Page 26] Internet Monthly Report July 1997 CALENDAR -------- Last update 07/10/97 The information below has been submitted to the IETF Secretariat as a means of notifying readers of future events. Readers are requested to send in dates of events that are appropriate for this calendar section. Please send submissions, corrections, etc., to: Please note: The Secretariat does not maintain on-line information for the events listed below. A copy of this calendar is available as follows: VIA FTP ------- IETF Information is available by anonymous FTP from several sites. US East Coast Address: ds.internic.net (198.49.45.10) US West Coast Address: ftp.isi.edu (128.9.0.32) Europe Address: nic.nordu.net (192.36.148.17) Pacific Rim Address: munnari.oz.au (128.250.1.21) Africa Address: ftp.is.co.za (196.4.160.12) cd ietf ls *0mtg* WWW ------- Click on the link for "meetings" and you should find an entry "listing of other Internet related events". ************************************************************************ 1997 ----------- Jul. 14-17 5th TCL/TK Workshop Boston, MA Jul. 14-18 ANSI X3T10 '97 Jul. 14-17 APPN Implementers Workshop San Jose, CA Jul. 17-19 VTIC-97 San Jose CA Jul. 20-25 ATM Forum Montreal, CANADA IMR Editor [Page 27] Internet Monthly Report July 1997 Jul. 23-26 ACM DL '97 2nd ACM Int'l Conf. on Digital Libraries Philadelphia, PA Jul. 24-25 DMS '97 Vancouver, CANADA Aug. 4-8 ANSI X3T11 (host by Hitachi) Honolulu, HI Aug. 11-15 39th IETF (host by German ISOC) Munich, Germany Aug. 12-14 DCI's Internet Expo Boston, MA Aug. 13-15 IEEE 25th Annual Int'l Computer Software and Application Conference Washington, DC Sep. RIPE28 TBD Sep 2-5 1997 Int'l Conference Intelligent Networks and Intelligence in Networks Paris, France Sep. 5 TERENA Technical Committee Amsterdam Sep. 5 TERENA Executive Committee Amsterdam Sep. 7-11 5th European Conf. on Computer Supported Coop. Work Lancaster University U.K. Sep. 8-12 ANSI X3T10 '97 Sep. 8-12 OIW (Firm) Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland Sep. 10-12 IDMS '97 w/ ACM SIGMM, GMD, IEEE Darmstadt, Germany Sep. 11-12 4th Int'l Workshop on Community Networking (IEEE) Atlanta, Georgia Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France Sep. 16-17 EWOS Assembly Brussels Sep. 21-26 ATM Forum Paris, France Sep. 26-30 3rd ACM/IEEE on Mobile Computing & Networking 1997 (MobiCom'97) Budapest, Hungary Oct. 6-10 ANSI X3T11 (host by FSI) Tucson, AZ Oct. 7-10 COMDEX Internet '97 and Object World '97 Internet Forum Europe (IFE) & Object World Frankfurt (OWF) Frankfurt, Germany Oct. 15-17 ACM SIGPLAN - Conf. on Domain-Specific Languages Santa Barbara, CA Oct. 23-24 TERENA General Assembly Madrid Oct. 24-26 1st Int'l Enterprise Distributed Objected Computing Wrkshop EDOC '97 Gold Coast, Australia Oct. 23-25 ETSI Nice, France Oct. 26-31 LISA '97 - 11th Systems Administration Conference San Diego, CA Oct. 27-31 EWOS Workshops Brussels Oct. 28-31 IEEE Int'l Conf. on Network Protocols Atlanta, GA Nov. 3-5 Int'l Test Conference 1997 Sheraton Washington Hotel Washington, DC Nov. 3-7 ANSI X3T10 '97 IMR Editor [Page 28] Internet Monthly Report July 1997 Nov. 3-7 SPIE Int'l Symposium Voice, Video & Data Communications Conf. on Performance & Control of Network System - Special Session on Switching & Traffic Mgmt in High Speed Networks Dallas, TX Nov. 3-7 2nd French/Brazilian Symposium on Distributed System Architectures: Telecommunication Multimedia Architectures Ceara, Brazil Nov. 8-14 ACM MULTIMEDIA '97 Seattle, WA Nov. 10-14 IEEE 802 Plenary Queen Elizabeth, Montreal Nov. 12-13 CEN/CENELEC/ETSI Brussels Nov. 19-21 ICCC'97 Cannes, France Nov. 24-26 PROMSMmNet '97 Multimedia Networking Santiago, Chile Nov. 30-Dec 5 ATM Forum Singapore Dec. 1-3 30th IEEE/ACM Int'l Symposium on Microarchitecture RTC, NCA Dec. 1-5 ANSI X3T11 (host by DPT) Orlando, FL Dec. 2-3 EWOS Assembly Brussels Dec. 8-12 40th IETF (Host: Newbridge) Washington, DC Dec. 8-12 OIW (Firm) Dec. 8-12 USENIX Symposium on Internet Technology and Systems) Monterey, CA Dec. 17-19 97 Int'l Sym. on Communications Hsinchu, Taiwan TBA TELECOM '97 Asia TBA 1998 ----------- Jan 6-8 W3C Interest Group Mtg TBA Jan. RIPE29 Amsterdam (tbd) Jan 26-29 7th Security Symposium San Antonio, TX Feb. 8-13 ATM Forum Anaheim, CA Feb 7-9 DCI'S Internet Expo San Jose, CA Mar. 9-11 2nd Euromicro Working Conf. on Soft. Maint. & Reeng. Florence, Italy Mar. 9-13 IEEE 802 Plenary Irvine, CA Mar. 29-Apr 2 IEEE INFOCOM '98 - Hotel Nikko San Francisco, CA Mar. 30-Apr. 3 41st IETF (Tentative) Los Angeles, CA Apr. 3-4 IEEE "OPENARCH '98" San Francisco, CA Apr. 12-17 WWW7 Brisbane, Australia Apr. 18-23 CHI '98 (ACM SIGCHI) Los Angeles, CA Apr. 19-24 ATM Forum Berlin, Germany Apr 20-22 W3C Interest Group Mtg TBA May RIPE30 Stockholm (tbd) May 5-8 Networld+Interop '98 Las Vegas, NV IMR Editor [Page 29] Internet Monthly Report July 1997 SPRING 1998 TELECOM '97 Africa Midrand, South Africa Jun 13-17 USENIX '98 Technical Conf. New Orleans, LA Jun 16-18 DCI's Internet Expo Chicago, IL Jul. 6-10 IEEE 802 Plenary San Diego, CA Jul. 20-24 INET '98 TBA Jul. 26-31 ATM Forum Portland, OR Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and Budapest, Hungary Aug. 23-28 42nd IETF (Tentative) Chicago, IL Aug. 29-Sep 4 SIGCOMM '98 Vancouver, CANADA Sep 1-3 DCI's Internet Expo Boston, MA Oct. 4-9 ATM Forum Gold Coast, Australia Oct 20-22 W3C Interest Group Mtg TBA Oct 21-23 Networld+Interop '98 Atlanta, GA Oct. 26-29 TERENA (host by DFN) Dresden, Germany Nov. 9-13 IEEE 802 Plenary Albuquerque, NM Nov. 29-Dec 4 ATM Forum Nashville, TN Dec. 6-11 12th Systems Administration Conf. (LISA '98) Boston, MA Dec. 7-11 43rd IETF (Tentative) TBA 1999 ----- Feb. 7-13 ATM Forum (tentative) TBA Feb 23-25 W3C Interest Group Mtg TBA Apr. 18-24 ATM Forum (tentative) TBA May 11-14 Networld+Interop '99 Las Vegas, NV May 31-Jun 4 WWW8 Toronto, CANADA Jun 4-6 W3C Interest Group Mtg TBA Jul. 18-24 ATM Forum (tentative) TBA late Aug SIGCOMM '99 (West Coast US) TBA Sep. 21-23 W3C Interest Group Mtg TBA Sep. 26-Oct 2 ATM Forum (tentative) TBA Oct. 8-14 TELECOM '99 Geneva, Switzerland Oct. 13-17 Networld+Interop '99 Atlanta, GA Nov. 28-Dec 4 ATM Forum (tentative) TBA 2000 May 9-11 Networld+Interop '00 Las Vegas, NV late Aug SIGCOMM 2000 Europe (tentative) Sep 25-29 Networld+Interop '00 Atlanta, GA IMR Editor [Page 30] Internet Monthly Report July 1997 TERENA LIST OF MEETINGS ----------------------- The current TERENA Calendar may be found on URL: http://www.terena.nl/news/calendar.html +++++++++++++++++++++++++++++++++++++++++++++ + + + TERENA Secretariat + + Singel 466-468 + + 1017 AW Amsterdam + + the Netherlands + + + + email + + + + tel: +31 20 639 1131 + + fax: +31 20 639 3289 + + + +++++++++++++++++++++++++++++++++++++++++++++ SOFTBANK FORUMS --------------- Business Conferences & Expositions BrainShare 97 Sydney Sydney Convention Centre Sydney, Australia Information 011 (61) 2 9369 1242 Conference: July 7-11, 1997 Support Services Conference & Expo West San Jose Convention Center San Jose, CA http://www.sbforums.com/ssce Registration (SOFTBANK Knowledge Interact) (800) 801-1354 (U.S. only) (719) 531-6522 (International) Housing (800) 754-8378 (U.S. & Canada) (650) 378-6643 (International) Conference: August 6-8, 1997 Exposition: August 5-7, 1997 IMR Editor [Page 31] Internet Monthly Report July 1997 Windows NT Intranet Solutions Moscone Convention Center San Francisco, CA http://www.wintis.com Customer Service (888) 800-8920 (U.S. & Canada) (650) 372-7071 (Internatioanl) Conference: August 11-15, 1997 Exposition: August 13-15, 1997 Java Internet Business Expo Jacob K. Javits Convention Center New York, NY http://www.javaexpo.sbforums.com Customer Service (888) 528-2397 (U.S. & Canada) (650) 372-7069 (International) Conference: August 25-28, 1997 Exposition: August 26-28, 1997 Java@Work Sun Microsystems Java Developer and Business Conference Sydney Conventionf Center, Darling Harbour Sydney, Australia http://www.sun.com.au Information 011 (61) 2 9211 7767 Conference: Sept 10-11, 1997 Technology Performance Management Conference and Expo Opryland Hotel Nashville, TN http://www.sbforums.com/tpm Registration (SOFTBANK Knowledge Interact) (800) 909-9848 (U.S. only) (719) 531-6522 (International) Housing (888) 611-2189 (U.S. & Canada) (650) 372-7084 (International) Conference: Sept 14-17, 1997 Exposition: Sept 14-17, 1997 IMR Editor [Page 32] Internet Monthly Report July 1997 Seybold San Francisco Moscone Convention Center San Francisco, CA http://www.seyboldseminars.com Customer Service (888) 473-9265 (U.S. & Canada) (650) 372-7078 (International) Conference: Sept 29-Oct 3, 1997 Exposition: Oct 1-3, 1997 Networld+Interop 97 Atlanta Georgia World Congress Center Atlanta, GA http://www.interop.com/events Customer Service (800) 962-6513 (U.S. & Canada) (650) 372-7079 (International) Conference: Oct 6-10, 1997 Exhibition: Oct 8-10, 1997 CommUnity Georgia World Congress Center Atlanta, GA http://www.interop.com/events/community Customer Service (800) 962-6513 (U.S. & Canada) (650) 372-7079 (International) Conference: Oct 6-10, 1997 Exhibition: Oct 8-10, 1997 Networld+Interop 97 Paris Porte de Versailles Paris, France http://www.interop.com/events Information 011 (33) 1 46 39 5656 Conference: Oct 20-23, 1997 Exhibition: Oct 21-23, 1997 Networld+Interop 97 London Olympia London, England http://www.interop.com/events Information 011 (44) 0181 261 4415 Conference: Oct 27-30, 1997 Exhibition: Oct 28-30, 1997 IMR Editor [Page 33] Internet Monthly Report July 1997 Windows NT Intranet Solutions Japan Makuhari Messe Tokyo, Japan Information 011 (81) 3 5642 8433 Conference: Nov 12-14, 1997 Exhibition: Nov 12-14, 1997 Networld+Interop 97 Sydney Sydney Convention Center Sydney, Australia http://www.interop.com/events Information 011 (61) 2 9369 1242 Conference: Nov 24-28, 1997 Exposition: Nov 26-28, 1997 Seybold Seminars Tokyo Makuhari Messe Tokyo, Japan http://www.seyboldseminars.com Information 011 (81) 3 5642 8433 Conference: Dec 9-12, 1997 Exposition: Dec 10-12, 1997 Help Desk Institute Regional Seminar and Expo Series Help Desk Institute offers several seminar series periodically throughout the year in various locations across the United States. For registration information, please call (800) 248-5667 or (719) 531-5138 . Regional Seminar & Expo Series http://www.HelpDeskInst.com/events Customer Service (800) 248-5667 (U.S. Only) (719) 531-5138 (International) Sheraton Washington Washington DC Seminar: July 14-18, 1997 Expo: July 16, 1997 Town & Country Resort San Diego, CA Seminar: Oct 6-10, 1997 Expo: Oct 8, 1997 IMR Editor [Page 34] Internet Monthly Report July 1997 Strategic Networks Seminars Strategic Networks offers one-day seminars for Interop Remote Access, Interop NetSwitch, Interop WAN, and Interop Secure ManageNet periodically throughout the year in various locations in the United States. For registration information, please call Strategic Networks at 800-898-7488. For sponsor opportunities, please call Strategic Networks at 800-999-7624. Interop WAN 97 Tour Planning your WAN Upgrade - Breaking Through http://www.snci.com Customer Service (800) 898-7488 (U.S. only) Washington DC Seminar: Sept 4, 1997 Newark, NJ Seminar: Sept 9, 1997 Chicago, IL Seminar: Sept 11, 1997 Boston, MA Seminar: Sept 30, 1997 Los Angeles, CA Seminar: Oct 16, 1997 Minneapolis, MN Seminar: Oct 21, 1997 San Francisco, CA Seminar: Oct 28, 1997 Atlanta, GA Seminar: Nov 6, 1997 Philadelphia, PA Seminar: Nov 13, 1997 Interop NetSwitch 97 Tour State of the Art ATM and Switched Technology http://www.snci.com Customer Service (800) 898-7488 (U.S. only) Minneapolis, MN Seminar: Sept 4, 1997 Washington DC Seminar: Sept 11, 1997 Toronto, Canada Seminar: Sept 30, 1997 Denver, CO Seminar: Oct 16, 1997 IMR Editor [Page 35] Internet Monthly Report July 1997 Hartford, CT Seminar: Oct 21, 1997 Los Angeles, CA Seminar: Oct 23, 1997 Pittsburgh, PA Seminar: Oct 30, 1997 Newark, NJ Seminar: Nov 6, 1997 Interop Secure ManageNet 97 Tour http://www.snci.com Customer Service (800) 898-7488 (U.S. only) San Francisco, CA Seminar: Sept 9, 1997 Los Angeles, CA Seminar: Sept 11, 1997 Washington DC Seminar: Oct 16, 1997 Newark, NJ Seminar: Oct 21, 1997 Chicago, IL Seminar: Oct 23, 1997 Boston, MA Seminar: Oct 28, 1997 Toronto, Canada Seminar: Oct 30, 1997 Minneapolis, MN Seminar: Nov 6, 1997 Interop ISP 97 http://www.snci.com Customer Service (800) 898-7488 (U.S. only) Chicago, IL Seminar: Sept 5, 1997 Seattle, WA Seminar: Sept 8, 1997 Atlanta, GA Seminar: Sept 10, 1997 Washington DC Seminar: Sept 19, 1997 Los Angeles, CA Seminar: Sept 22, 1997 San Francisco, CA Seminar: Sept 24, 1997 Parsippany, NJ Seminar: Sept 26, 1997 IMR Editor [Page 36] Internet Monthly Report July 1997 Dallas, TX Seminar: Sept 30, 1997 Software Support Professionals Association (SSPA) SSPA offers a variety of support programs throughout the year which include executive forums, software support conferences, and monthly on-line roundtable and executive sessions. For a description of the events and for registration information, please call SSPA at (800) 801-1354 or (719) 531-6522. Virtual Roundtables Held On-line at 10:00 A.M. PST http://www.sspa-online.com Customer Service (800) 801-1354 (U.S. only) (719) 531-6522 (International) Staffing and Scheduling Tools for Software Support July 16, 1997 Building Supportability into Products August 20, 1997 Harnessing the WWW as a Support Resource Sept 17, 1997 The Virtual Support Center Oct 22, 1997 Justifying the Benefits of CTI, IVR, and ACD Systems Nov 19, 1997 A New Training Paradigm for Software Support Dec , 1997 (TBA) Executive Forum http://www.sspa-online.com Customer Service (800) 801-1354 (U.S. only) (719) 531-6522 (International) Palm Springs, CA Forum: Dec 4-5, 1997 IMR Editor [Page 37] Internet Monthly Report July 1997 SSPA Stars Awards and Membership Meeting San Jose, CA Meeting: Dec 3, 1997 http://www.sspa-online.com Customer Service (800) 801-1354 (U.S. only) (719) 531-6522 (International) SSPAs Software Support Stars Conference http://www.sspa-online.com Customer Service (800) 801-1354 (U.S. only) (719) 531-6522 (International) San Diego, CA Conference: Oct 15-17, 1997 Executive Session Held On-line at 10:00 A.M. PST http://www.sspa-online.com Customer Service (800) 801-1354 (U.S. only) (719) 531-6522 (International) Session: July 22, 1997 Session: August 26, 1997 Session: Sept 23, 1997 Session: Oct 28, 1997 Session: Nov 25, 1997 Session: Dec 23, 1997 SOFTBANK Knowledge Interact Seminars SOFTBANK Knowledge Interact offers SkillTech Professional Seminars periodically throughout the year in various locations throughout the United States. For a calendar of 1997 events and registration information, please call SOFTBANK Knowledge Interact at 800-34-TRAIN. SOFTBANK Forums 303 Vintage Park Drive Foster City, CA 94404 (650) 578-6900 Fax: (650) 525-0194 http://www.sbforums.com IMR Editor [Page 38]   Received: from ietf.org by ietf.org id aa19984; 22 Aug 97 20:06 EDT Received: from mail1y-ext.prodigy.net by ietf.org id aa19842; 22 Aug 97 20:03 EDT Received: from default (port32.edis.prodigy.net [204.237.216.32]) by mail1y-int.prodigy.net (8.8.5/8.8.5) with SMTP id UAA53998 for ; Fri, 22 Aug 1997 20:02:10 -0400 Message-ID: <33FE52F0.65E9@prodigy.net> Date: Fri, 22 Aug 1997 20:03:12 -0700 Sender:ietf-request@ietf.org From: ANDALURI Reply-To: ANDALURI@prodigy.net Organization: Prodigy Internet X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: ietf@ietf.org Subject: remove Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa21792; 22 Aug 97 21:50 EDT Received: from user1.channel1.com by ietf.org id aa21688; 22 Aug 97 21:47 EDT Received: from endor (p11.ts24.metro.MA.tiac.com [206.119.196.140]) by user1.channel1.com (8.8.5/8.8.5) with ESMTP id VAA14145 for ; Fri, 22 Aug 1997 21:47:42 -0400 (EDT) Message-ID: <33FE4179.41798BBB@vipah.com> Date: Fri, 22 Aug 1997 21:48:41 -0400 Sender:ietf-request@ietf.org From: Brian Weed Reply-To: bweed@vipah.com Organization: Vipah Interactive X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: ietf@ietf.org Subject: Remove X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa00197; 22 Aug 97 23:59 EDT Received: from bubble.yonsei.ac.kr by ietf.org id aa00079; 22 Aug 97 23:55 EDT Received: (from binich@localhost) by bubble.yonsei.ac.kr (8.6.9H1/8.6.9) id MAA14343; Sat, 23 Aug 1997 12:55:49 +0900 Date: Sat, 23 Aug 1997 12:55:48 +0900 (KST) Sender:ietf-request@ietf.org From: Jung Young Suk To: ietf@ietf.org Subject: Remove Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa01732; 23 Aug 97 4:26 EDT Received: from shell1.aimnet.com by ietf.org id aa01375; 23 Aug 97 4:02 EDT Received: from localhost (dwm@localhost) by aimnet.com (8.8.7/8.8.6) with SMTP id BAA10732 for ; Sat, 23 Aug 1997 01:02:47 -0700 (PDT) Date: Sat, 23 Aug 1997 01:02:47 -0700 (PDT) Sender:ietf-request@ietf.org From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: ietf@ietf.org Subject: Can we PLEASE fix these double copies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. It sure would be nice if we could stop getting TWO copies of every post to this list. Surely there is someone watching this list who can do something about the problem Regards, Dave Morris   Received: from ietf.org by ietf.org id aa12893; 24 Aug 97 20:24 EDT Received: from dfw-ix6.ix.netcom.com by ietf.org id aa12698; 24 Aug 97 20:09 EDT Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id TAA01906; Sun, 24 Aug 1997 19:07:44 -0500 (CDT) Received: from kcx-ks9-13.ix.netcom.com(198.211.69.77) by dfw-ix6.ix.netcom.com via smap (V1.3) id sma001732; Sun Aug 24 19:05:57 1997 Message-ID: <34007A88.720@ix.netcom.com> Date: Sun, 24 Aug 1997 19:16:40 +0100 Sender:ietf-request@ietf.org From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.03Gold (Win16; I) MIME-Version: 1.0 To: Ellen Rony CC: Don Heath , ARIN list , IETF ORG , Global TLD's discuss , eDNS Discuss , DOMAIN-POLICY@lists.internic.net Subject: Re: ISPCON - Telage summary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Ellen and all, Notice: Official response to follow. From: Jeff Williams Director and co-Founder of IEG. INC.) Subject: IEG. INC. Official response to Mr. Don Telage NSI To: Fellow Particapants at ISPCON My response Starts here intermixed with Mr. Telage's comments. Ellen Rony wrote: ISPCON report, part 1 - Great conference again. Excellent, informative presentations. Overheard that it had 4,000 attendees (unconfirmed number). Here is a fairly lengthy summary of the comments made by Don Telage on Friday.8/22. I thought the conference room would be packed, but such was not the case. It seems that the ISPs are focused on the bottom line and do not yet realize how governance issues will affect them or why they should be involved. More work needs to be done to raise that awareness. Re: Dr. Telage: I expected he might a person who has hair on his teeth. Instead, he is articulate, informational, personable, reasonable, accessible, warm and likeable. So here are notes from his talk. No spell checker. All comments below are from Dr. Telage, not the messenger (well, one annotation). Questions from audience in brackets. A few full, exact quotes included. Will try to make time to post notes from Mockapetris, Kashpureff and DNRC sessions later. For NSI response to NOI, see August 18 NTIA posting, but it will also be posted on netsol web site, _________________________________________________ >From Dr Telage: NSI - "we're the company that everyone loves to hate" 3 objectives of talk: 1. Address the question of why are we where we are in this governance issue? Why should it not be expected? Hindsight point of view. 2. Look at some of the controversial issues. Stress areas where there are some misunderstandings. Where NSI has a view, want to present our opinion. Information/clarification phase. 3. Speculate on where whole process going? What hints do we have on where it needs to go? What should we as a community do to get a good outcome for the Internet. Find an outcome that respects the business and lets each of the stakeholders continue their function. Future direction. Policy changes that we make today are going to have impacts down the road. You should take an interest in what is being done with your Internet, because it is your Internet, no one else's. Internet was done way it was done because it served an effective purpose. Right model for the functions it had in the first 20 years. Consensus-driven work. No top down. Global skunkworks type of arrangement. Marvelous quality to it. ISPs responsible for why it needs to change. ISPs brought tens of thousands of customers who had different mind set and objectives of prior years. Brought commercial interests and priorties, conflicting interests, business priorities. and that is the reason it needs to change. its function is now changed. We have the old role, but the consensus model isn't going to work when big money and rapid time elements are involved, when laws are involved, when countries feel a stake in, that is what is generating the change. You generated an unbelievable commercial explosion. I don't think we are close to the top curve. Perspective so small in time scale. In five years, this curve will be seen as flat. Growth will be greater soon than we can ever imagine. Growth relentless. We have to make it more industrial strength to get where we need to go. Commercial operations have impacted the operational stuff at bowels of Internet, root server operators, IP registries, changed business models, too. IANA, IAB, IESG vulnerable, not indemnified not protected. "It's almost inappropriate that individuals or small collections of individuals who happen to have an historical name to them can operate in a governance role anymore." Too much to ask of these individuals. They must feel the strain.] We're in this role and it feels very threatening to us. Postel must feel very vulnerable. I don't think Jon Postal feels threatened at all, form some conversations that I have had and heard of with Jon, he feel more betrayed personaly and profesionaly. So it seems like MR. Telage, is trying to shore some things up here with the IANA, IA and the IESG. Intreating shift of emphisis in this remark. Food for thought possibly. You be the judge. Internet basically grew up in U.S. From a national point of view, with exception of RIPE and APNIC, most of critical elements are still within continental U.S. Until month ago, everyone of root servers were in the U.s. Month ago shipped a second server offshore. 2/3 of traffic volume is within U.S. Internet global in extent, but in terms of balance of infrastructure, topology and activity, it is still US-centric. We (U.S.) should take leadership role to fix things. First of all there have been two Root servers outside the US for more than a year now, so I see that Mr. Telage is a bit innaccurate with his facts. This is astounding in a way. He should know better than this. I agree that the US should take a leadership role baised on his very reasons in his next sentance, but not a dominating one. Even though the most usace and infrastructure in in the US currently, this will only be true for a small amount of time. Once China and most of asia comes online in a more significant way, our dominance will not be there. Hence, the reason for not dominating the situation now. Be open, accepting, encourgaging and inviting to the whole world. By doing this we better ourselves perportionaly. Re: Cooperative agreement. NSI feels it doesn't have a technical direction role. Agreement almost implies that IANA has the responsibility and we have always treated that to be the case. That's where policy decisions, appeals are made to IANA, network numbering policies and identifiers originate there. NSF trying to get out of its role for 2 years. IATF wouldn't let NSF out last April. Not no, but "hell no. One semblance of stability, wouldn't allow NSF to leave. Legal activity. NSI sued by PGMedia for antritrust activity. IANA told NSI it has no authority in these matters, do what you want. NSF letter on June 10 with a plan to introduce competition into the DNS, please approve or modify and respond. NSF said no, not until US govt has chance to review this entire matter. Aug 11 NSF said no again. Mr. Telage, makes a very good point here. In accordance with the Telecommunications act of 1996, NSF is mandated to allow for private enterprise to be a working partner, unincumbered reguardless of size or stature in the commercial sector. This puts NSF's Aug. 11th answer in contrast with the US congress and federal Law. SO it would seem that NSF is indeed in abayance of antitrust laws as well. More intrigue to issue: Justice Department conducting investigation into NSI antitrust behavior. Even though we are operating under govt contract, andappealed to both what we think are the authorities and have been denied approval. Being sued, denied an ability to defend ourselves (NSI), and being investigated by Justice Department. Not well informed District Court judge could order a solution tomorrow which would overrrule the contract. Not the way to do it. Needs orderly process. Well NSI and NSF had had more than a year to develope that process, to little avail. Why? Becouse it is not in NSI's intrest? Maybe? OR is it due to poor managment a feet dragging? Likely? I don't pretend to know. Reguardless, if I know that I or We (IEG. INC.) can do it, than surely NSI and the NSF could have or already should have. Airing dirty laundry. Recent snafu on Internet. Let bad root file go out. Tried to notify them. Couldn't notify root server operators because they are volunteers. Whole structure needs higher performance standers. Needs 7x24 accountability. No fail safe in the system. That whole structure needs to be put more under control. I agree. And this should have been done more than two years ago. Many warned, to no avail. So I guess, "Those who fail to manage, manage to fail". DNS Advantages: terrifically easy to use. Large name space. Easy to understand. More self funded. Resilient to growth. Disadvantages: Open to spoofing. Was a peer to peer system, not designed to deal with hostile activities. DNS security is something that is already under development by the IETF. In addition, this problem was and should have been known long ago. Many, including myself warned of this weakness, and were shruged off as being excentric. Well I guess, again failier to realize the obvious is always a rude awakener. Directory system is sorely lacking. Need to figure out how to get information easily. Average user can't get WHOIS for Germany, etc. Needs to be put together in some unified way. No uniform registration policies worldwide. Some treat it as holy grail to other extreme at NSI. We treat it as a brand, a registration identity. The Internet needs to figure out what domains are, what registration is and how it should be dealt with registration in a uniform way. This again has ben known or suspected for over two years now. Yet NSI and NSF are just now realizing it. How short sited, which again points out the poor judgment of NSI's managment and NSF's oversite. Registries have to operate in legal vacuum are hugely vulnerable. In order to protect selves have to put in policies aren't popular. But alternative, with no indemnification from any legal body, risks going out of business. Other registries haven't hit volume points so haven't seen this yet. They will, soon. "NSI supports competition of any form that the community decides is necessary, either through the addition of new TLDS or through the imposition of a shared registration concept if it is done with stability and is done orderly and it respects the legacy positions of the registries." This is a very serious problem indeed. Replacment of the lagacy DNS software is paramount to meet future demand. It is still not too late to be proactive here, but somehow I doubt this will happen in light of past history. "Sharing .com, sharing .de, sharing .net, sharing .uk, that's not a problem. Not easy to do, but we support it. Relative to adding new TLDs, no technical limit. Not issue. Issue is possible confusion in Internet space, implementation guidelines, pushing the problem up one level. Community not in agreement on this. 3 camps: 1) want to get into business, want new TLDS ; 2) trademark owners or those who got name , want no more TLDS, see this as intellectual property nightmare for them.; 3) group lost out in court battle and still lusts after name...wants new TLD so they another shot at the name and procedure. This is where the curx of many of the discussions have centered for nearly a year and a half now. I agree that there is no limit to the possibilities of TLD's that could be created if a shared system of registries in a Round Table fassion is accepted or in place. This is already underway. SOme call these services "Alternitive Registries". Alternitive or not, they exist, and are not likely to go away. SO the IANA/IETF/ISOC/POC/CORE/IAB need to find a way to work WITH these RSC's, not Flame them. We have a long way to go here. "Competition will one of the most important things that this industry needs: it will induce people to invest." NSI has invested 10s of millions of dollars into new facility. 34,000 sq ft, state of the art facility. Key question: do we want to make a change of DNS system that only affects top level. It is hierarchical system. Parallel in IP level, portability. Technically difficult to do. Issues of routability. Well I agree. And first on that list is a modification or update to RFC2050, RFC1917, RFC1918. In doint this in a open manner, and getting on with either IPv6 or IPv8, we can shoot alot of these problems very quickly. This doesn't seem to be the way ARIN and the IANA seem to want to head however. So openess and providing for the expandability in usefull way does not seem to be in their intrest. One must question this logic. If you do sharing, you will end up building another back office facility. That facility will wind up being a monopoly. Somewhere, all of this stuff needs to come together for reconciliation. Creates a wholesale monopoly back office and retail front office. I don't agree that the back office facility will end up being an monopoly at all. Most of my coleague's do not either. This sounds like another "Scare tactic" for some power freeks to control as much of the central parts of the internet as they can and use the ole "Medicare scare Tactic" argument to get tit done. Whole issue of what a gTLD is has always baffled me. Policy change should affect all elements in that class. 60 TLDS where you can register no matter you live or where your host is. What's the distinction between a gTLD and one of these guys? Volume. [comment from Rick Wesson....historical difference; gTLDs do not have a historic value and do not have association with ISO 3166] Just above Mr. Telage stated that there is no limit to the number of TLD's possible. He seems to almost conterdict himself here with saying that 60 will allow you to register no matter where you live or where your host is. This may be so, but does not answer the brending concerns. .COM is as big as it is for 2 reasons. .US not widely accepted. Ugly ducking of TLDS. Growth in Internet has been in US and it doesnt have a popular ISO 3166. .COM filled void. Problem is volume, not geography. When other TLDs start experiencing growth, they will have same problems. Hence the need to offer alternitives. As many as there is a precieved demand for. Not to mention splitting the load. Re registration pricing graphs: Tremendous variability. Charge enuf to make reasonable profit to invest and improve offerings. Other registries need to look on this as investment oriented activity. I agree. And this is something that will need to be an ongoing experiment. But I suspect as demand grows so will price, as well as costs. Hence the need to act now. [Q: could Poland start a new TLD?] No, wouldn't get included in 13 root servers. Were not taking any new applications based on NSF's directions. Bad idea! Contredictory to his previous statments on this critique as well. Mr. Telage seems to have no real direction here, nor any suggestions as to what possible directions he would like to see things go. We have a fundamental problem with iPOC initiative. We feel changes need to be evolutionary. Stakes too high to do anything too radical until we know impacts. Need managed transition period top make necessary changes to stabilize infrastructure. Shipping the problem to inexperienced international body where complexity goes up is not a wise move. Needs to be market driven at some level, needs to be internationally governed, needs to be industrial strength. Needs period of transition to evolve to another body, some U.S. agency that has skills set perhaps. Sounds like he is for NSF or some other government agency to step in here. Regulation? Lets hope that is a misevaluation on my part. Broad objectives for transition: Overarching issues: 1) Establish legal framework. Who is in charge? What is in charge? Everyone ducks the bullet. We the stakeholders are in charge, all over the world. The internet users is what is in charge, both commercial and otherwise. 2) Need to bring all the competition into the space. Only way will spur investment required to raise registries to performance levels to grow Internet globally. Profit will motivate. Things that require investment will respond to profit. 3) Fill in DNS trademark vacuum. How do domain names and trademarks relate? Must fix these first before moving whole infrastructure offshore. Will take 18-24 months. Too long. Not that big of a problem. Usage of international Tradmark law should do it just fine. Make DOmain names a tradmarkable entitity. NSI PROPOSAL: 4-layer chart. Legal layer - US government. Allows registry to derive authority from someone. Similar to N.A. Numbering Council has same model. Intl participation from stakeholders, does policy development. Governance layer - IPAG (international policy advisory gorup) intl body which accepts membership from interested stakeholder globally; membership based on usage or volume representation. operational layer - manage critical functions. nonprofit business. not highly capitalized. Need DNS manager: resp for managing the root, the dot, failsafe operations. Should move from us and other volunteers. Analog on DNS side to IP side. business layer - litkely registries and ISPs willb e the same. capital intensive. customer interface. needs incentive for investment. profit layer. To many layers here to be efectual and reactive to global stake holders needs not and certianly in the future. More streamlining is needed. Remove unneeded redundance. WOrk this like a buisness, not like a social club, from a structual point of view. This process will never be affective or work long term. Just creates a bunch of bearuacrats. Cutover from us agency to international is easy if 4 layers are in place. "We want to be a registrar. That's all we want to be.' Not realistic statment baised on this layering structure in this statment. Broad rush questions: How do we view names? Are DNS space and trademarks the same? What is business model that is needed at each layer? Does model we have chosen work operationally? What's the governance model here that I community wants? Registries in a bind. No immunity from suit but must protect selves from financial instinction. Cannot wilfully and knowingly infringe trademarks. We registered 125K names last month. With no policy in place, we would have gotten thousands of suits. As is, 30+ lawsuits naming us. 1,300 written disputes on 1.6 million registrations. Problem doesn't need to be solved by draconian means such as trademark pre-screening. Work on the exceptions. Good point here. I agree. [remaining comments in response to audience questions] NSI can't do a prepayment policy. Too many different payment arrangements. ISPs need to pay by check; companies need purchase orders. I don't agree with this at all. But I understand his point. A need to automate payment parctices is paramount to good financial tracking and managment in todays electornic age. Old payment methods can still be used, but should not be manditory. This makes fudiciary responsibility to cumbersom for many and very expensive as well. This is also anti small buisness. Dispute policy prevents lawsuits for "contributory infringement". Following advice of attorneys. Every domain registrant has signed a 2 year contract. Cannot be prorated. If registrant wants to go another registrar when that becomes available, that is your choice, but you have signed a 2 year contract (my note: which means your money won't be refunded). This is a common business practice. Good point. But what is in that two year contract. I hope it is not like the gTLD-MoU contract. SIgning theirs IS NOT GOOD BUISNESS! So I think the real story in this comment is in the fine print. In hindsight, NSI should have written the cooperative agreement differently so that NSF indemnified NSI from all policy related matters. -end Telage comments- Hindsite hell, NSI was told this by many befor they singed that contract! Pass the buck again, I see. - End of our comments and official response - -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com   Received: from ietf.org by ietf.org id aa13885; 24 Aug 97 21:45 EDT Received: from wyrsa.cs.umbc.edu by ietf.org id aa13828; 24 Aug 97 21:43 EDT Received: from lyra.cs.umbc.edu (mctr@lyra.cs.umbc.edu [130.85.100.29]) by wyrsa.cs.umbc.edu (8.8.6/8.8.6) with ESMTP id VAA14777; Sun, 24 Aug 1997 21:43:25 -0400 (EDT) Sender:ietf-request@ietf.org From: Account of Maryland Center for Telecommunications Research Received: (mctr@localhost) by lyra.cs.umbc.edu (8.8.5/8.6.12) id VAA00482; Sun, 24 Aug 1997 21:43:21 -0400 (EDT) Date: Sun, 24 Aug 1997 21:43:21 -0400 (EDT) Message-Id: <199708250143.VAA00482@lyra.cs.umbc.edu> To: ietf@ietf.org Subject: 8th Maryland Workshop on Very High Speed Networks Cc: sidhu@cs.umbc.edu Source-Info: From (or Sender) name not authenticated. *************************************************************** 8th Maryland Workshop on Very High Speed Networks November 11-12, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the 8th Maryland Workshop on Very High Speed Networks (VHSN '97) on November 11-12 1997 at the UMBC campus. The Workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers can meet to exchange ideas and report on leading- edge developments in the area of high speed networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. A registration fee of $325 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr@cs.umbc.edu. Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250. All funds for this event will be managed by the UM foundation. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- VHSN '97 REGISTRATION FORM (November 11-12, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------   Received: from ietf.org by ietf.org id aa13949; 24 Aug 97 21:45 EDT Received: from wyrsa.cs.umbc.edu by ietf.org id aa13891; 24 Aug 97 21:45 EDT Received: from lyra.cs.umbc.edu (mctr@lyra.cs.umbc.edu [130.85.100.29]) by wyrsa.cs.umbc.edu (8.8.6/8.8.6) with ESMTP id VAA14807; Sun, 24 Aug 1997 21:45:06 -0400 (EDT) Sender:ietf-request@ietf.org From: Account of Maryland Center for Telecommunications Research Received: (mctr@localhost) by lyra.cs.umbc.edu (8.8.5/8.6.12) id VAA00491; Sun, 24 Aug 1997 21:45:04 -0400 (EDT) Date: Sun, 24 Aug 1997 21:45:04 -0400 (EDT) Message-Id: <199708250145.VAA00491@lyra.cs.umbc.edu> To: ietf@ietf.org Subject: Mobile Agents and Security Workshop Cc: sidhu@cs.umbc.edu Source-Info: From (or Sender) name not authenticated. *************************************************************** Mobile Agents and Security Workshop October 27-28, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the Workshop on Mobile Agents and Security (MAAS '97) on October 27- 28, 1997 at the UMBC campus. The workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers, from academia and industry, can meet to exchange ideas and report on leading-edge developments in the use of mobile agents in implementing solutions to security pcublems in networks and systems and also to discuss security problems caused by mobile agent technology. The participation in the workshop is by invitation only and limited to active researchers and developers in the subject area of the workshop. If you have made contributions to mobile agents and security and would like to participate in the workshop, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr@cs.umbc.edu. The following hotels are closest to UMBC campus. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- MAAS '97 REGISTRATION FORM (October 27-28, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------   Received: from ietf.org by ietf.org id aa22074; 24 Aug 97 23:37 EDT Received: from uknt.kasten.co.uk by ietf.org id aa22024; 24 Aug 97 23:36 EDT Received: by uknt.kasten.co.uk with Internet Mail Service (5.0.1457.3) id ; Mon, 25 Aug 1997 04:30:47 +0100 Received: from mail.KASTENCHASE.COM by uknt.kasten.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id QZBQ1Z5P; Mon, 25 Aug 1997 04:30:42 +0100 Received: by kcnt with Internet Mail Service (5.0.1457.3) id ; Sun, 24 Aug 1997 23:40:11 -0400 Message-ID: <4163BE4E108CD0118DEF006097254321183E6F@kcnt> Sender:ietf-request@ietf.org From: Tom Cherry To: ietf@ietf.org Subject: remove Date: Sun, 24 Aug 1997 23:40:09 -0400 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Source-Info: From (or Sender) name not authenticated.   Received: from ietf.org by ietf.org id aa07390; 25 Aug 97 9:58 EDT Received: from [198.203.136.2] by ietf.org id aa07110; 25 Aug 97 9:45 EDT Received: from gms1.glat.com ([10.16.0.140]) by [198.203.136.2] via smtpd (for IETF.org [132.151.1.19]) with SMTP; 25 Aug 1997 13:45:47 UT Received: by gms1.glatfelter.com with Internet Mail Service (5.0.1457.3) id ; Mon, 25 Aug 1997 09:47:27 -0400 Message-ID: Sender:ietf-request@ietf.org From: "Cooper, Jeff R." To: "'ietf@ietf.org'" Subject: remove Date: Mon, 25 Aug 1997 09:47:25 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Source-Info: From (or Sender) name not authenticated. remove ------------------------------------------------------------ Jeff Cooper (United States) Corporate Internet/Intranet Webmaster Mailto:jcooper@glatfelter.com http://www.glatfelter.com The Truth is out There   Received: from ietf.org by ietf.org id aa08289; 25 Aug 97 10:33 EDT Received: from ietf.ietf.org by ietf.org id aa07998; 25 Aug 97 10:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-intralis-multicast-01.txt Date: Mon, 25 Aug 1997 10:28:32 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708251028.aa07998@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM Author(s) : Y. Rekhter, D. Farinacci, D. Meyer Filename : draft-ietf-ion-intralis-multicast-01.txt Pages : 6 Date : 1997-08-22 This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). The method described here is specific to Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism inherent in PIM-SM to notify routers when they should create group specific point-to-multipoint VCs. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-intralis-multicast-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-intralis-multicast-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-intralis-multicast-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970822174529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-intralis-multicast-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-intralis-multicast-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970822174529.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08306; 25 Aug 97 10:33 EDT Received: from ietf.ietf.org by ietf.org id aa08036; 25 Aug 97 10:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-callaghan-url-nfs-01.txt Date: Mon, 25 Aug 1997 10:28:43 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708251028.aa08036@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NFS URL Scheme Author(s) : B. Callaghan Filename : draft-callaghan-url-nfs-01.txt Pages : 11 Date : 1997-08-22 A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined in RFC 1738, 'Uniform Resource Locators (URL)'. This scheme uses the public filehandle and multi-component lookup [ RFC 2054, 2055] to access server data with a minimum of protocol overhead. The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3 [RFC1813], both built on ONC RPC [RFC1831] at its associated eXternal Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833]. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-callaghan-url-nfs-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-callaghan-url-nfs-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-callaghan-url-nfs-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970822183452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-callaghan-url-nfs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-callaghan-url-nfs-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970822183452.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08304; 25 Aug 97 10:33 EDT Received: from ietf.ietf.org by ietf.org id aa08016; 25 Aug 97 10:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-eastlake-local-names-00.txt Date: Mon, 25 Aug 1997 10:28:38 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708251028.aa08016@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Local DNS Names Author(s) : D. Eastlake Filename : draft-eastlake-local-names-00.txt Pages : Date : 22-Aug-97 A set of second level domain names are defined under a new top level domain name such that local private DNS zones can be maintained similar to the private IP addresses reserved in RFC 1918 but which locally appear to be part of the global DNS name tree. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eastlake-local-names-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-eastlake-local-names-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-eastlake-local-names-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970822181520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-eastlake-local-names-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-eastlake-local-names-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970822181520.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa08293; 25 Aug 97 10:33 EDT Received: from ietf.ietf.org by ietf.org id aa07977; 25 Aug 97 10:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ids@umich.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ids-dnsnames-03.txt Date: Mon, 25 Aug 1997 10:28:25 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708251028.aa07977@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Directory Services Working Group of the IETF. Title : Use of DNS Aliases for Network Services Author(s) : R. Wright, M. Hamilton Filename : draft-ietf-ids-dnsnames-03.txt Pages : 9 Date : 1997-08-22 It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programmatically discover that an organization runs, say, a World- Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as the Server Location Resource Records (DNS SRV) [RFC-2052] work. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ids-dnsnames-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ids-dnsnames-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ids-dnsnames-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970822162926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ids-dnsnames-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ids-dnsnames-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970822162926.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa09719; 25 Aug 97 11:28 EDT Received: from gateway.dlcc.com by ietf.org id aa09647; 25 Aug 97 11:26 EDT Received: from neil.dlcc.com ([192.168.0.100]) by gateway.dlcc.com with SMTP id <26498>; Mon, 25 Aug 1997 08:29:18 -0700 Received: by neil.dlcc.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCB131.9BD28430@neil.dlcc.com>; Mon, 25 Aug 1997 08:33:48 -0700 Message-ID: Sender:ietf-request@ietf.org From: mcaeser To: "'ietf@ietf.org'" Subject: remove Date:Mon, 25 Aug 1997 08:33:43 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. remove   Received: from ietf.org by ietf.org id aa11029; 25 Aug 97 12:13 EDT Received: from ftp.icst.com by ietf.org id aa10901; 25 Aug 97 12:09 EDT Received: from mailgate.icst.com by icst.com (SMI-8.6/SMI-SVR4) id MAA03984; Mon, 25 Aug 1997 12:04:44 -0400 Sender:ietf-request@ietf.org From: charan@icst.com Received: from ccMail by mailgate.icst.com (ccMail Link to SMTP R6.0) id AA872521931; Mon, 25 Aug 97 11:52:10 -0500 Message-Id: <9708258725.AA872521931@mailgate.icst.com> X-Mailer: ccMail Link to SMTP R6.0 Date: Mon, 25 Aug 97 08:26:01 -0500 To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: remove MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. remove   Received: from ietf.org by ietf.org id aa12116; 25 Aug 97 13:01 EDT Received: from ietf.ietf.org by ietf.org id aa11898; 25 Aug 97 12:58 EDT To: IETF-Announce: ; Sender:ietf-announce-request@ietf.org From: "Mike St. Johns" Subject: Nomination Committee - Second call for Volunteers.. Date: Mon, 25 Aug 1997 12:58:50 -0400 X-Orig-Sender: mbeaulie@ietf.org Message-ID: <9708251258.aa11898@ietf.org> Hi - As you may or may not know I've been tapped to head this years IAB/IESG nominating committee. This is the second call for volunteers to participate as members of that committee. If you would like to volunteer, please send me email (to stjohns@corp.home.net) with the phrase "NOMCOM VOLUNTEER" (yes - all caps) in your subject line indicating your desire to participate. Please include your snail mail and phone numbers in the body of the message. To be eligible to serve on the NOMCOM, you must have attended 2 of the last 3 IETFs. Please make sure you can spend the time required to serve. Although there won't be any face to face meetings except for the December IETF, you will have to spend about 2 hours a week on the phone during the 12 active weeks of the nominations process (starting around the December IETF) in teleconferences with the entire nominations committee. You'll also be assigned various candidates to interview as part of the nominations process. Third and last call for volunteers will be next Wednesday, the 27th of August. Cutoff for accepting volunteers will be as of 1600 PDT on the 29th of August - specifically, they have to be in my email box at that time. Once I've got the complete list of volunteers, I'll post it and also ask that the Secretariat verify eligibility. The 10 members will be selected by lot based on the sales volume of 11 stocks as of the NASDAQ market close on 19 September as reported in the San Jose Mercury News on 20 September 1997. The procedure is as follows: 1) The Secretariat will provide the final list of eligibles listed in alphabetical order and numbered from 0 sequentially increasing and will mail this to the IETF and IETF-Announce list on or before the 17th of September. 2) The sales volume figure for the NASDAQ most active stock on the 19th of Sept will be used to provide an initial offset into the list. The 10,000s and 1,000s digit from the volume figure will be used to generate a "random" number from 00 to 99 (e.g. if the sales figure is 345,009,234 shares, the number is 09). The actual offset into the list is calculated as volnumber**5 mod the length of the list. So if the volume number is 9, the length of the list is 47, the offset would be 17. 3) Each stock in turn will then be used to select a nomcom member from the list by using the same procedure of extracting the 10,000 and 1000 digits, raising them to the 5th power, adding that to the current position number and then taking that mod the length of the list. So if the first of the listed stocks sales figure was 45,923,213 and the length of the list were 47 as above, then the volume number would be 23, and the final position on the list would be (17 + 23**5) mod 47 or 39. The person with the number 39 (remembering that the list is numbered from 0 this is actually the 40th person) would become the first member. 4) Step three is repeated continuing from the current position on the list until all 10 members are selected. 5) In the event that there is a duplicate selection,simply continue down the list sequentially until you find a person who has not been selected. Continue the process from that position on the list. 6) If the most active stock is also one of the stocks I list for the selection, it will be used twice, once for the initial offset, and once for selecting a member. 7) The figures as reported in the SJMercury News are the official figures. In the event of a disagreement between the numbers in the SJMercury and any other publication, the SJMercury figures will be considered correct. 8) If any stock is not listed in the 20 September 1997 edition of the paper, it will be replaced in order by one of the alternate stocks IN ITS PLACE - e.g. the other stocks on the list will retain their specific positions, rather than having the stock deleted and having the alternate stock added to the end of the list. 9) The list of stocks is as follows: Member 1) Apple Computer (reported as AppleC) 2) @Home Corporation (reported as AtHome) 3) Cisco Systems (reported as Cisco) 4) Cyber Cash (reported as CybrCsh) 5) Excite (reported as Excite) 6) Intel (reported as Intel) 7) MCI (reported as MCI) 8) Microsoft (reported as Microsft) 9) Netcom (reported as Netcom) 10) Netscape (reported as Netscpe) Alternate 1) Quantum 2) 3Com 3) Yahoo   Received: from ietf.org by ietf.org id aa12595; 25 Aug 97 13:22 EDT Received: from ietf.ietf.org by ietf.org id aa12526; 25 Aug 97 13:20 EDT To: IETF-Announce: ; Cc: receipt@cs.utk.edu Sender:ietf-announce-request@ietf.org From: The IESG SUBJECT: Last Call: An Extensible Message Format for Message Disposition Notifications to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 25 Aug 1997 13:20:06 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708251320.aa12526@ietf.org> The IESG has received a request to consider An Extensible Message Format for Message Disposition Notifications as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 28, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-receipt-mdn-05.txt   Received: from ietf.org by ietf.org id aa12747; 25 Aug 97 13:25 EDT Received: from ietf.ietf.org by ietf.org id aa12682; 25 Aug 97 13:24 EDT To: IETF-Announce: ; Cc: rem-conf@es.net Sender:ietf-announce-request@ietf.org From: The IESG SUBJECT: Last Call: RTP Payload Format for MPEG1/MPEG2 Video to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 25 Aug 1997 13:24:34 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708251324.aa12682@ietf.org> The IESG has received a request to consider RTP Payload Format for MPEG1/MPEG2 Video as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 28, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-avt-mpeg-new-01.txt   Received: from ietf.org by ietf.org id aa19793; 25 Aug 97 16:15 EDT Received: from mailgate.nortel.ca by ietf.org id aa19456; 25 Aug 97 16:03 EDT Received: from zrchh190.us.nortel.com (actually 47.158.65.22) by bcarsde4.localhost; Mon, 25 Aug 1997 15:06:10 -0400 Received: from zrchb161.bnr.ca (actually zrchb161.rich.nt.com) by zrchh190.us.nortel.com; Mon, 25 Aug 1997 14:05:50 -0500 Received: by zrchb161.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCB15F.E5B5AEF0@zrchb161.bnr.ca>; Mon, 25 Aug 1997 14:05:09 -0500 Message-ID: Sender:ietf-request@ietf.org From: David Trammell To: "'ietf@ietf.org'" Subject: FW: Can we PLEASE fix these double copies Date: Mon, 25 Aug 1997 14:05:12 -0500 Return-Receipt-To: X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Please remove from your mailing list. >---------- >From: David W. Morris[SMTP:dwm@xpasc.com] >Sent: Saturday, August 23, 1997 3:02 AM >To: ietf@ietf.org >Subject: Can we PLEASE fix these double copies > > >It sure would be nice if we could stop getting TWO copies of every >post to this list. Surely there is someone watching this list who >can do something about the problem > >Regards, > Dave Morris > >   Received: from ietf.org by ietf.org id aa20156; 25 Aug 97 16:23 EDT Received: from ns1.vrx.net by ietf.org id aa20060; 25 Aug 97 16:21 EDT Received: from mbv1-ipl-ri10.kos.net(really [206.186.41.50]) by vrx.net via sendmail with smtp id for ; Mon, 25 Aug 1997 16:20:35 -0400 (EDT) (Smail-3.2.0.92 1997-Feb-9 #2 built 1997-Apr-8) Message-Id: Date: Mon, 25 Aug 1997 16:20:35 -0400 (EDT) X-Sender: rsexton@vrx.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jeff Williams Sender:ietf-request@ietf.org From: "Richard J. Sexton" Subject: "Internet governence" Cc: Ellen Rony , Don Heath , ARIN list , IETF ORG , Global TLD's discuss , eDNS Discuss , rsc@ah.net, domain-policy@lists.internic.net Source-Info: From (or Sender) name not authenticated. (Please understand that I'm not trying to initiate a discussion onany of these lists, and please do not reply to any of them directly unless it is pertinent and within the charter of the list to do so) On the subject of "Internet governence", or "administration of an end to end protocol" I have one comment: http://vrx.net/declaration.html Have a nice day. -- richard@sexton.org Bannockburn, Ontario, CANADA, K0K 1Y0 +1 (613) 473 1719   Received: from ietf.org by ietf.org id aa20415; 25 Aug 97 16:31 EDT Received: from cctvw02.cctec.com by ietf.org id aa20311; 25 Aug 97 16:29 EDT Received: from laptop (node40-cmh.kdcinc.com [206.183.244.40]) by cctvw02.cctec.com (8.7.3 Version 1.1 Build 565/8.7.3) with SMTP id QAA00036 for ; Mon, 25 Aug 1997 16:27:32 -0400 (Eastern Daylight Time) Message-Id: <3.0.32.19970825162724.007759a8@207.87.243.20> X-Sender: overlord@207.87.243.20 X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 25 Aug 1997 16:27:33 -0400 To: ietf@ietf.org Sender:ietf-request@ietf.org From: Eric Germann Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. Somebody is forwarding the list back to itself. First copy of message headers: Received: from ietf.org (ietf.org [132.151.1.19]) by cctvw02.cctec.com (8.7.3 Version 1.1 Build 565/8.7.3) with SMTP id UAA00144 for ; Fri, 22 Aug 1997 20:18:50 -0400 (Eastern Daylight Time) Received: from ietf.org by ietf.org id aa19477; 22 Aug 97 19:47 EDT Received: from zephyr.isi.edu by ietf.org id aa19451; 22 Aug 97 19:47 EDT Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 22 Aug 1997 16:47:19 -0700 Message-Id: <199708222347.AA19446@zephyr.isi.edu> To: ietf@ietf.org, imr@isi.edu Subject: Internet Monthly Report for July, 1997 Cc: imr-ed@isi.edu Date: Fri, 22 Aug 97 16:51:26 PDT Sender: ietf-request@ietf.org From: IMR Editor Source-Info: From (or Sender) name not authenticated. Second copy of message headers: Received: from ietf.org (ietf.org [132.151.1.19]) by cctvw02.cctec.com (8.7.3 Version 1.1 Build 565/8.7.3) with SMTP id WAA00144 for ; Fri, 22 Aug 1997 22:17:10 -0400 (Eastern Daylight Time) Received: from ietf.org by ietf.org id aa21023; 22 Aug 97 21:04 EDT Received: from csj053.emirates.net.ae by ietf.org id aa20972; 22 Aug 97 21:02 EDT Received: (from root@localhost) by aituae.com (8.7.5/8.7.3) id FAA14968; Sat, 23 Aug 1997 05:00:42 +0400 X-POP3-Rcpt: m_ait@netidentity Received: from net-master.com (root@ns1.net-master.com [208.138.158.10] (may be forged)) by netidentity.com (8.8.7/8.7.2) with ESMTP id FAA06222 for ; Sat, 23 Aug 1997 05:40:15 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by net-master.com (8.8.6/8.7.2) with SMTP id QAA31226 for ; Fri, 22 Aug 1997 16:47:15 -0700 Received: from ietf.org by ietf.org id aa19465; 22 Aug 97 19:47 EDT Received: from zephyr.isi.edu by ietf.org id aa19451; 22 Aug 97 19:47 EDT Received: from akamai-a.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 22 Aug 1997 16:47:19 -0700 Message-Id: <199708222347.AA19446@zephyr.isi.edu> ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann@cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider   Received: from ietf.org by ietf.org id aa20820; 25 Aug 97 16:51 EDT Received: from ietf.ietf.org by ietf.org id aa20725; 25 Aug 97 16:48 EDT To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: int-serv@isi.edu, rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: The IESG Subject: Protocol Action: The Use of RSVP to Proposed Standard Date: Mon, 25 Aug 1997 16:48:03 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708251648.aa20725@ietf.org> The IESG has approved of the following the Internet-Drafts as Proposed Standards: o Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification o RSVP Cryptographic Authentication o RSVP Management Information Base o RSVP Extensions for IPSEC Data Flows The IESG also approved publication of the following Internet-Drafts as Informational RFCs: o Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement o Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules These documents are products of the Resource Reservation Setup Protocol Working Group. The IESG contact persons are Scott Bradner and Allyn Romanow. Technical Summary This set of documents describes RSVP, a unicast and multicast signalling protocol, designed to install and maintain reservation state information in routers along the path of a stream of data, along with technology to ensure the security of the signaling protocol and MIBs to support SNMP management of RSVP systems. Hosts can use RSVP to request specific qualities of service (QoS) from a network for particular application data streams or flows. Routers can use RSVP to forward these requests along the data path and to maintain the state required to provide the requested QoS. Quality of service is implemented for a particular data flow by mechanisms collectively called "traffic control". These mechanisms include (1) a packet classifier, (2) admission control, and (3) a "packet scheduler" or some other link-layer-dependent mechanism to determine when particular packets are forwarded. The "packet classifier" determines the QoS class (and perhaps the route) for each packet. For each outgoing interface, the "packet scheduler" or other link-layer-dependent mechanism achieves the promised QoS. Traffic control implements QoS service models defined by the Integrated Services Working Group. Because RSVP and the integrated services mark a significant change to the service model of IP networks, RSVP has received considerable interest and press in advance of its release as a standards track RFC. At present, many vendors of operating systems and routers are incorporating RSVP and integrated services into their products for near-future availability. The goal of the accompanying applicability statement is to describe those uses of the current RSVP specification that are known to be feasible, and to identify areas of known limitations. Working Group Summary The documents have been extensively discussed in the rsvp working group and on various mailing lists. The current set of documents accurately reflects working group consensus. A few comments were received during IETF last-call about the clarity of some of the documents and about the security considerations sections. The documents have been updated to reflect the comments. Protocol Quality The documents were reviewed for the IESG by Scott Bradner and Allison Mankin.   Received: from ietf.org by ietf.org id aa21907; 25 Aug 97 17:17 EDT Received: from ietf.ietf.org by ietf.org id aa21779; 25 Aug 97 17:15 EDT To: IETF-Announce: ; Cc: applmib@emi-summit.com Sender:ietf-announce-request@ietf.org From: The IESG SUBJECT: Last Call: Definitions of System-Level Managed Objects for Applications to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 25 Aug 1997 17:15:29 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708251715.aa21779@ietf.org> The IESG has received a request from the Application MIB Working Group to consider Definitions of System-Level Managed Objects for Applications as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-applmib-sysapplmib-08.txt   Received: from ietf.org by ietf.org id aa23869; 25 Aug 97 18:37 EDT Received: from [192.70.231.5] by ietf.org id aa23778; 25 Aug 97 18:35 EDT Received: from mogate.sps.mot.com by spsem02.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA04758 for ietf@ietf.org; Mon, 25 Aug 97 15:35:17 MST Received: from email56.sps.mot.com by mogate.sps.mot.com (4.1/SMI-4.1/Email-2.0) id AA09066 for ietf@ietf.org; Mon, 25 Aug 97 15:35:12 MST Message-Id: Date: 25 Aug 1997 15:30:27 -0700 Sender:ietf-request@ietf.org From: Davis Hartman Subject: ietf@ietf.org%INTERNET To: "ietf@ietf.org%INTERNET" X-Mailer: Mail*Link SMTP-QM 4.1.0 Source-Info: From (or Sender) name not authenticated. REMOVE   Received: from ietf.org by ietf.org id aa25492; 25 Aug 97 20:26 EDT Received: from nw.com by ietf.org id aa25413; 25 Aug 97 20:23 EDT Received: (from mkl@localhost) by nw.com (8.8.5/8.8.5) id RAA19528 for ietf@ietf.org; Mon, 25 Aug 1997 17:22:50 -0700 (PDT) Date: Mon, 25 Aug 97 17:22:49 PDT Sender:ietf-request@ietf.org From: Mark Lottor To: ietf@ietf.org Subject: Internet Domain Survey results, July 1997 Message-ID: Source-Info: From (or Sender) name not authenticated. Internet Domain Survey Network Wizards July 1997 The Domain Survey attempts to discover every host on the Internet by doing a complete search of the Domain Name System. The latest results gathered during late July 1997 are listed. For more information see RFC 1296; for more data see the zone directory on ftp.nw.com, or http://nw.com -- Mark Lottor Number of Hosts and Domains advertised in the Domain Name System Replied Date | Hosts Domains To Ping* ------+---------------------------------- Jul 97| 19,540,000 1,301,000 4,314,410 Jan 97| 16,146,000 828,000 3,392,000 Jul 96| 12,881,000 488,000 2,569,000 Jan 96| 9,472,000 240,000 1,682,000 Jul 95| 6,642,000 120,000 1,149,000 Jan 95| 4,852,000 71,000 970,000 Jul 94| 3,212,000 46,000 707,000 Jan 94| 2,217,000 30,000 576,000 [* estimated by pinging 1% of all hosts]   Received: from ietf.org by ietf.org id aa06308; 26 Aug 97 10:03 EDT Received: from ietf.ietf.org by ietf.org id aa06102; 26 Aug 97 9:51 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipcdn@terayon.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipcdn-ipover-802d14-00.txt Date: Tue, 26 Aug 1997 09:51:18 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708260951.aa06102@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Logical IP Subnetworks over IEEE 802.14 Services Author(s) : M. Laubach Filename : draft-ietf-ipcdn-ipover-802d14-00.txt Pages : 13 Date : 1997-08-01 This memo defines an initial application of classical IP and ARP in an IEEE 802.14 Community Access Television (CATV) Residential Access Network environment. IEEE 802.14 services provide two independent link layer service interfaces which are available to support IP residential access networking services: traditional Ethernet bridging (via IEEE 802.1D layer services) and residential ATM networking services. In this memo, the term Logical IP Subnetwork (LIS) is defined to apply to Classical IP over ATM LIS's operating over IEEE 802.14 services as well as traditional IP over Ethernet operating over IEEE 802.14 services. The recommendations in this draft rely on existing IETF standards for the family of Classical IP and ARP over ATM (IPOA) services and for IP and ARP over Broadcast Ethernet networks. The tree-based hierarchic nature of the IEEE 802.14 MAC subnetwork permits convenient extensions to Classical IPOA model for broadcast and multicast in the downstream direction of the CATV plant. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-ipover-802d14-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipcdn-ipover-802d14-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-ipover-802d14-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970825134625.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-ipover-802d14-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-ipover-802d14-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825134625.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06537; 26 Aug 97 10:04 EDT Received: from ietf.ietf.org by ietf.org id aa06381; 26 Aug 97 10:02 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-khana-00.txt Date: Tue, 26 Aug 1997 10:02:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708261002.aa06381@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PPP for Asynchronous PAD to Synchronous X.25 access Author(s) : V. Khanna Filename : draft-rfced-info-khana-00.txt Pages : 6 Date : 1997-08-25 The PPP protocol allows data transfer thru asynchronous or synchronous connections. But the prevalent Public Switched Data Networks (PSDNs) support connections between asynchronous and synchronous protocols. This document defines extensions to the PPP protocol to support asynchronous PAD to synchronous X.25 protocols on PSDNs. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rfced-info-khana-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-khana-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-khana-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970825104031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-khana-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-khana-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825104031.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06539; 26 Aug 97 10:04 EDT Received: from ietf.ietf.org by ietf.org id aa06344; 26 Aug 97 10:02 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-viswanathan-mpls-rsvp-00.txt Date: Tue, 26 Aug 1997 10:02:23 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708261002.aa06344@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Soft State Switching A Proposal to Extend RSVP for Switching RSVP Flows Author(s) : A. Viswanathan, S. Blake, V. Srinivasan Filename : draft-viswanathan-mpls-rsvp-00.txt Pages : 13 Date : 1997-08-25 This memo describes a mechanism for establishing a switched path with guaranteed Quality of Service for RSVP [1] flows in a MultiProtocol Label Switching (MPLS) environment. It proposes an extension to the RSVP protocol that allows the establishment of a sequence of label switched hops along the hop-by-hop routed path by enabling adjacent nodes to exchange MPLS labels [11]. The labels may correspond to information that identifies a layer 2 virtual connection; for example, the VPI/VCI value in the case of an ATM-based infrastructure. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-viswanathan-mpls-rsvp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-viswanathan-mpls-rsvp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-viswanathan-mpls-rsvp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970825174911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-viswanathan-mpls-rsvp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-viswanathan-mpls-rsvp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825174911.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06543; 26 Aug 97 10:04 EDT Received: from ietf.ietf.org by ietf.org id aa06409; 26 Aug 97 10:02 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-robert-00.txt Date: Tue, 26 Aug 1997 10:02:42 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708261002.aa06409@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MAPPING OF AIRLINE TRAFFIC OVER IP Author(s) : A. Robert Filename : draft-rfced-info-robert-00.txt Pages : 19 Date : 1997-08-25 This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rfced-info-robert-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-robert-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-robert-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970825174146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-robert-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-robert-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825174146.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06541; 26 Aug 97 10:04 EDT Received: from ietf.ietf.org by ietf.org id aa06323; 26 Aug 97 10:02 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dns-security@tis.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-secext2-01.txt Date: Tue, 26 Aug 1997 10:02:18 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708261002.aa06323@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Title : Domain Name System Security Extensions Author(s) : D. Eastlake Filename : draft-ietf-dnssec-secext2-01.txt Pages : 48 Date : 1997-08-25 Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided even through non-security aware DNS servers in many cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback from implementors and potential users to RFC 2065. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-secext2-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext2-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-secext2-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970825171850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-secext2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-secext2-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825171850.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa19067; 26 Aug 97 19:09 EDT Received: from wyrsa.cs.umbc.edu by ietf.org id aa18974; 26 Aug 97 19:03 EDT Received: from lyra.cs.umbc.edu (mctr@lyra.cs.umbc.edu [130.85.100.29]) by wyrsa.cs.umbc.edu (8.8.6/8.8.6) with ESMTP id TAA17445; Tue, 26 Aug 1997 19:03:48 -0400 (EDT) Sender:ietf-request@ietf.org From: Account of Maryland Center for Telecommunications Research Received: (mctr@localhost) by lyra.cs.umbc.edu (8.8.5/8.6.12) id TAA02078; Tue, 26 Aug 1997 19:03:53 -0400 (EDT) Date: Tue, 26 Aug 1997 19:03:53 -0400 (EDT) Message-Id: <199708262303.TAA02078@lyra.cs.umbc.edu> To: ietf@ietf.org Subject: CORRECTION: 8th Maryland Workshop on Very High Speed Networks Cc: mctr@cs.umbc.edu Source-Info: From (or Sender) name not authenticated. !!!!!!! NOTE: PLEASE NOTE NEW DATES FOR THIS WORKSHOP !!!!!! *************************************************************** 8th Maryland Workshop on Very High Speed Networks November 12-13, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the 8th Maryland Workshop on Very High Speed Networks (VHSN '97) on November 12-13 1997 at the UMBC campus. The Workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers can meet to exchange ideas and report on leading- edge developments in the area of high speed networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. A registration fee of $325 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr@cs.umbc.edu. Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250. All funds for this event will be managed by the UM foundation. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- VHSN '97 REGISTRATION FORM (November 12-13, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------   Received: from cnri by ietf.org id aa23303; 26 Aug 97 22:47 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA08893; Tue, 26 Aug 1997 22:50:02 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id UAA00400 for cat-ietf-redist; Tue, 26 Aug 1997 20:50:39 -0400 (EDT) Message-Id: From: "Mike Swift (NT)" To: Marc Horowitz , cat-ietf@mit.edu Subject: RE: Comments on snego-06 Date: Tue, 26 Aug 1997 17:50:34 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Precedence: bulk I agree with these comments. - Rather than having separate OIDs for options within a mechanism, the mechanism should negotiate options on its own or through the context requirement bits in the initial token. - It is also useful to avoid an extra leg of authentication. In the optimistic case SPNEGO should not cost any more round trips than the mechanism it is negotiating. - The policy for choosing a package really should be a local matter - defining it just so it is easier to compare implementations isn't a good enough reason. I would like to see any changes to SPNEGO wrapped up quickly. Mike Swift > -----Original Message----- > From: Marc Horowitz [SMTP:marc@cygnus.com] > Sent: Friday, August 22, 1997 1:12 PM > To: cat-ietf@mit.edu > Subject: Comments on snego-06 > > The snego-06 draft still has several problems. Some are technical, > others are just editorial. > > ** Severe technical problems (I believe these must be fixed before we > go to last call): > > In section 2, there is still text about specifying a single option to > a mechanism by adding to the end of the mech OID. I thought this was > going to be removed. This technique has two problems. First, if you > want to specify two options, you can't. Second, there is nothing > preventing the owner of a bit of OID arc from defining two mechanisms > having OID's A.B.C.D and A.B.C.D.E. This makes it impossible to > distinguish the second mechanism from the first mechanism with option > E. In general, if we want to have a protocol for specifying mechanism > options outside the mechanism, I think we should do so in such a way > which does not require use of snego. > > Section 3.1 describes the policy for the acceptor to choose a > mechanism. I thought we had decided that policy issues were a local > matter. > > Section 3.2: if the acceptor does not understand the negotiation > mechanism, GSS_S_BAD_MECH, not GSS_S_FAILURE, should be returned. > > In the current text, the mechListMic is only in the NegTokenTarg, not > in the NegTokenInit. This means that if the client provides the last > token, then an additional message is necessary, just to carry the MIC. > This is wasteful; mechListMIC should be in NegTokenInit, and the MIC > should be in the same message as the final preferredToken, whether > generated by the initiator or acceptor. > > ** Minor technical problems (I believe these should be fixed, but they > won't break the spec in any significant way if not): > > The negResult field is unnecessary. The initiator can determine if > the acceptor accepted a mechanism by checking for the presence of the > supportedMech field. Even if it was necessary, having two accept > values is redundant, as the initiator can tell from the underlying > mechanisms's return value from GSS_Init_sec_context if additional > further are necessary. > > What is MechSpecInfo used for? I'd like to hear a concrete example > about how it is intended to be used, or see it removed from the draft. > As far as I can tell, whenever this sort of functionality might be > needed, it should be inside the preferredToken, and invisible to > snego. > > ** Editorial issues: > > In section 2, the draft describes negotiation tokens as "new GSS-API > context-level tokens". This is not accurate; they are simply > mechanism context-level tokens, like any other. > > Appendix A: the functions' descriptions should explain how the > cred_handle is used by them. > > Marc   Received: from cnri by ietf.org id aa08323; 27 Aug 97 11:43 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA10453; Wed, 27 Aug 1997 11:46:47 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id JAA11307 for cat-ietf-redist; Wed, 27 Aug 1997 09:46:20 -0400 (EDT) Message-Id: <3.0.1.32.19970827093526.007ef3e0@world.std.com> X-Sender: linn@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 27 Aug 1997 09:35:26 -0400 To: minutes@ietf.org From: John Linn Subject: CAT-WG minutes, Munich IETF Cc: cat-ietf@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk Notes from Common Authentication Technology (CAT) meeting, Munich IETF, 13 August 1997, compiled by John Linn (with thanks to Rich Graveman (Bellcore) for access to his notes from the session and to Cliff Neuman (ISI) for providing copies of his presentation slides in text form). (This version contains a few detail-level clarifications relative to the previous draft sent to the mailing list, per comments received from WG members.) The CAT WG met for one session at the Munich IETF. REVIEW OF ONGOING WORK ITEMS: FTP SECURITY FTP Security (draft-ietf-cat-ftpsec-09) is in IESG hands and had been inadvertently delayed in its IESG consideration, but is reportedly on the agenda to be considered for Proposed Standard status at the next IESG conference call. REVIEW OF ONGOING WORK ITEMS: GSS-V2 AND C BINDINGS Re GSS-V2, the proposed approach is to integrate the RFC2078bis changes list into an updated GSS-V2 base Internet-Draft during September, and then (following a WG Last-Call period) to submit the resulting RFC2078bis and the GSS C bindings as an aligned set to the IESG, requesting their advancement to Proposed Standards; this proposed approach was acceptable to session attendees. No more than very minor changes to the C bindings are anticipated. REVIEW OF ONGOING WORK ITEMS: SNEGO Approximately 6 attendees indicated that they had reviewed draft-ietf-cat-snego-06; approximately 15 indicated familiarity with this or previous snego versions. It had been believed that draft-ietf-cat-snego-06 represented WG consensus for advancement, but Marc Horowitz (Cygnus) and Bill Sommerfeld (HP) indicated a position that draft-ietf-cat-snego-06 does not reflect previously established WG consensus in certain areas, and were to detail the specifics of their dissent to the WG list during the IETF meeting week. No other snego-related comments were indicated in the session. Follow-up discussion is underway on the mailing list. FTP AND DSA, KEA/SKIPJACK William Nace (NSA) presented a pair of recently-distributed documents, concerning, respectively, FTP with DSA (draft-ietf-cat-ftpdsaauth-00-txt), and FTP with KEA/Skipjack algorithms (draft-ietf-cat-ftpkeaskj-00.txt). Other contributors include Peter Yee and Russ Housley. Given the status of KEA/Skipjack (currently classified), the document authors are targeting this document for informational status. Discussion within the session suggested informational status for the DSA document as well, but (given the fact of unconstrained DSA specification) the DSA document could be admissible for subsequent standards-track consideration by the WG. Approximately three attendees indicated familiarity with the drafts; a concern was indicated that the algorithms applied may constitute national-level solutions. The DSA draft provides FIPS-196 authentication for FTP. Unilateral DSA signature-based authentication was discussed in the session, though support for both unilateral and mutual cases is defined within the specification. The KEA/Skipjack draft provides confidentiality for both the data and command streams; labels are also implemented. Encrypted data are base-64 encoded. KERBEROS PK-INIT AND PK-CROSS Brian Tung (ISI) presented and discussed the recently-revised kerberos-pk-init and kerberos-pk-cross drafts. Brian noted that Kerberos open issues are being identified at http://gost.isi.edu/info/kerberos. KERBEROS PK-INIT AND PK-CROSS: PK-INIT Approximately 4 attendees indicated they had read pk-init-04; approximately 15 were familiar with one or more pk-init versions. Document contributors include Ari Medvinsky and Matt Hur (CyberSafe), Jon Trostle (Novell), Brian Tung and Cliff Neuman (ISI), and John Wray (Digital). In draft-ietf-cat-kerberos-pk-init-04, a convention was added for translating between X.500 and Kerberos names. Mike Swift (Microsoft) questioned why base-64 encoding was applied in name translation rather than using the new name type being defined in 1510bis. Ted Ts'o (MIT) observed that the base-64 approach avoids the need to recognize X.500 semantics within Kerberos. In pk-init-04, a client's realm comes from a certificate, not a KDC. A client's principal name also comes from a certificate. A KDC's principal name was added as an X.509 v3 attribute. Diffie-Hellman specification was imported from PKCS #3, specification was added for checksummed encryption, and more specific errors were defined. Support within pk-init for SPEKE, an algorithm with which approximately 3 attendees indicated familarity, had been proposed on the mailing list. Ted Ts'o believed that SPEKE was patent-pending, but terms were unknown; Cliff Neuman believed that patent or patent-pending status should not be a bar to consideration as long as an algorithm's implementation is not mandatory for conformance with the specification. Brian Tung is to continue discussion of SPEKE on the mailing list. Mike Swift observed that Microsoft's CAPI supports PKCS formats rather than bare-level public-key encryption, and would like to be able to support pk-init functions with PKCS-level objects. Ted Ts'o agreed that this suggestion appeared reasonable, noting the broad existing base of code supporting PKCS formats. Brian Tung will raise this issue to the list for further discussion. A suggestion was made that use of X.509 AltSubjectName be considered. KERBEROS PK-INIT AND PK-CROSS: PK-CROSS Brian Tung described draft-ietf-cat-kerberos-pk-cross-02 as including minor changes relative to its predecessor. Approximately 2 attendees indicated that they had read pk-cross-02; approximately 7 indicated familiarity with one or more pk-cross revisions. In pk-cross-02, the remote realm now determines the lifetime of a shared key. Matt Hur has suggested using pk-init to do pk-cross, which would be a major change. Mike Swift noted that Microsoft was evaluating usage of DNS as a means to locate KDCs; this was considered to be a form of existing practice which may warrant codification in RFC1510bis. Mike Swift also reiterated his recommendation, as made relevant to pk-init, to allow public-key operations to be performed using PKCS objects. KERBEROS-REVISIONS (RFC1510BIS) Cliff Neuman (ISI) discussed status and issues relative to the Kerberos RFC1510bis document, draft-ietf-cat-kerberos-revisions-00. Approximately 4 attendees indicated that they had reviewed this draft. Changes and issues had previously been summarized to the CAT list. It was noted in discussion that the currently pending issues list includes the addition of key derivation procedures for 3DES support. Document-related comments were solicited, to krb-protocol@mit.edu for protocol-related issues and via http://gost.isi.edu/info/kerberos (as also used for pk-init, pk-cross, and pktapp). An HTML/SGML version is in progress, targeted for completion by 1 September; its content will correspond to a new I-D (kerberos-revisions-01) to be submitted. As revisions of the HTML versions proceed, corresponding I-Ds will also be issued and will remain authoritative. Major changes considered since the kerberos-revisions-00 I-D, and discussed at the session, are: - Authorization data field: Elements are of type AuthorizationData (new terminology). New element types include: kdc-issued (checksummed with application server's key, vouched for by the KDC of that application server's realm), intended-for-server and intended-for-application-class (identifying targets or sets thereof for which a ticket is intended), if-relevant, and Boolean combinations of authorization elements ("or" is currently proposed; "and" was considered appropriate as well). If a kdc-issued element occurs in an inter-realm environment, a receiving KDC reads and (if acceptable) reissues the element; it is not passed through without reissuance and, were a passed-through element to occur, that element would be ignored. Each of the intended-for-server, intended-for-application-class, and if-relevant attribute types carries a sequence of elements. If intended-for-server or intended-for-application-class attributes are not understood at a targeted recipient, their enclosing ticket is to be rejected; if received elsewhere, they may be ignored. If if-relevant attributes are not understood at a targeted recipient, they may be ignored. In the interests of simplicity, and without perceived loss of needed function, it was agreed in discussion that kdc-issued should be limited to appear at the top nesting level only, and should not nest recursively. Backwards compatibility with existing code incapable of recognizing these newly-defined elements was considered important; Cliff Neuman is to propose text to the mailing list discussing the circumstances under which these elements should be included. One suggestion was that they be included at the level of a ticket element. - Extensions field to ticket: This is an optional sequence, allowing additional data to be linked to the ticket so that it follows the ticket throughout the system. It is located in a ticket's cleartext portion at the end of the ticket, is typed opaque, is linked from within the authorization data field, and contains a flag as to whether it is OK to be removed. It can be used for PK-CROSS to distribute the inter-realm key, or can be used to distribute authorization data which is integrity protected but not confidential, plaintext ticket data, or accompanying authorization credentials. Placement of the extensions field in the ticket's cleartext portion allows unnecessary encryption of ancillary data to be avoided. - Optional client version in pre-auth: This identifies the version of kinit, in a manner considered analogous to an HTTP version string. The intended concept is to use this for backwards compatibility when changes are made. These numbers are not registered and vendor dependent; vendors or users of this field are admonished to pick version identifiers unlikely to conflict with those of other vendors. No corresponding server version identfier is provided, so as not to advertise known and exploitable bugs. RFC2078BIS, RFC1964 ISSUES John Linn led discussion on some specific issues related to RFC2078bis and RFC1964. Specific items cited: Re sequence number setup in RFC1964, John Wray's working proposal for the context acceptor to use the initiator's ISN in the single-hop case was accepted (recognizing that a separate reflection indicator is included in the protocol). Re gss_display_status and CONTINUE_NEEDED: some clarification was desired as to whether these can be used together or not. Some existing implementations return CONTINUE_NEEDED when iterating through successive messages returned from gss_display_status, but this had not been contemplated in RFC-2078. The sense of the discussion was that CONTINUE_NEEDED should be returned only by gss_init_sec_context and gss_accept_sec_context; this intent (along with commentary on the residual portability issue) should be cited in RFC-2078bis and defensive callers should ignore CONTINUE_NEEDED if returned by calls other than gss_init_sec_context and gss_accept_sec_context. If a name of the type GSS_C_NT_EXPORT_NAME is imported with an unrecognized mechanism (OID) in the framing defined by Section 3.2, GSS_S_BAD_MECH is to be returned." RFC-2078 contains MIT arc OIDs for some, but not all, of the generic name types; this was considered benign and the sense of the discussion was to retain these OIDs to avoid backward compatibility issues. For the case of host-based service, where an IANA arc OID had been assigned for use in preference to its predecessor MIT arc OID, it was recommended that both OIDs be accepted with equivalent effect but that the MIT arc OID be emitted on output; the sense of discussion was to reverse the prior recommendation preferring the IANA arc OID over the MIT arc OID representing the same type, in order to avoid backward compatibility issues with existing implementations. RFC-2078bis needs (per discussion re snego) to add facilities for informatory conf_req, integ_req inputs to gss_init_sec_context. The conjunction of supplementary info bits and non-zero routine errors was discussed briefly. The goal is to tighten up the list of possible cases. This topic was deferred to discussion on the list. RFC1964 EXTENSIONS Mike Swift solicited interest in two possible areas of extension to RFC-1964, user-user authentication and initial authentication via a dial-up access server. Mike noted that user-user authentication would be useful for DCOM, and suggested support for Kerberos user-user authentication as a submechanism within RFC-1964. Marc Horowitz believed that it would be more appropriately supported as a separate mechanism with its own OID; snego could be used to select between RFC-1964 Kerberos and a user-user mechanism. Generic resolution of name discovery for the user-user environment was believed to be a difficult issue, but there appeared to be interest in investigating and potentially drafting a specification for user-user authentication support. Mike also solicited interest in specification of initial authentication via a dial-up server (as in pktapp), where an initial request is forwarded through an access server. Ted Ts'o commented that Derek Atkins' Charon thesis had addressed essentially this problem some years previously. OTHER DISCUSSION Bengt Ackzell (Generic Systems) noted that, per the Memphis CAT minutes, IDUP had been planned for placement into WG Last Call following the Munich meeting if no comments were pending. Recent IDUP on-list discussion has been quiet, the base specification has not been recently revised, and issuance of corresponding C bindings remains pending. Upon further review, it appeared that further revision or on-list discussion of pending comments was needed before proceeding. --jl   Received: from ietf.org by ietf.org id aa11302; 27 Aug 97 14:36 EDT Received: from poptart.svr.home.net by ietf.org id aa11109; 27 Aug 97 14:31 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.corp.home.net (Netscape Mail Server v2.02) with ESMTP id AAA2734; Wed, 27 Aug 1997 11:31:11 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id LAA10757; Wed, 27 Aug 1997 11:31:10 -0700 (PDT) Message-Id: <199708271831.LAA10757@lock.eos.home.net> X-Mailer: exmh version 1.6.7 5/3/96 To: ietf@ietf.org cc: scoya@CNRI.Reston.VA.US Subject: Third and last call for volunteers - Nominations Committee. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 11:31:05 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. *****LAST CALL!!!!!!! LAST CALL!!!!!!!!***** *****List closes 1600 PDT 29 August 1997**** [Steve - please reflect onto the IETF-Announce list] [This document has some changes from prior announcements, note the change in the list of stocks for the selection process, also includes list of people with expiring terms. - Mike] Hi - As you may or may not know I've been tapped to head this years IAB/IESG nominating committee. This is the second call for volunteers to participate as members of that committee. If you would like to volunteer, please send me email (to stjohns@corp.home.net) with the phrase "NOMCOM VOLUNTEER" (yes - all caps) in your subject line indicating your desire to participate. Please include your snail mail and phone numbers in the body of the message. To be eligible to serve on the NOMCOM, you must have attended 2 of the last 3 IETFs. Please make sure you can spend the time required to serve. Although there won't be any face to face meetings except for the December IETF, you will have to spend about 2 hours a week on the phone during the 12 active weeks of the nominations process (starting around the December IETF) in teleconferences with the entire nominations committee. You'll also be assigned various candidates to interview as part of the nominations process. Third and last call for volunteers will be next Wednesday, the 27th of August. Cutoff for accepting volunteers will be as of 1600 PDT on the 29th of August - specifically, they have to be in my email box at that time. Once I've got the complete list of volunteers, I'll post it and also ask that the Secretariat verify eligibility. The 10 members will be selected by lot based on the sales volume of 11 stocks as of the NASDAQ market close on 19 September as reported in the San Jose Mercury News on 20 September 1997. The procedure is as follows: 1) The Secretariat will provide the final list of eligibles listed in alphabetical order and numbered from 0 sequentially increasing and will mail this to the IETF and IETF-Announce list on or before the 17th of September. 2) The sales volume figure for the NASDAQ most active stock on the 19th of Sept will be used to provide an initial offset into the list. The 10,000s and 1,000s digit from the volume figure will be used to generate a "random" number from 00 to 99 (e.g. if the sales figure is 345,009,234 shares, the number is 09). The actual offset into the list is calculated as volnumber**5 mod the length of the list. So if the volume number is 9, the length of the list is 47, the offset would be 17. 3) Each stock in turn will then be used to select a nomcom member from the list by using the same procedure of extracting the 10,000 and 1000 digits, raising them to the 5th power, adding that to the current position number and then taking that mod the length of the list. So if the first of the listed stocks sales figure was 45,923,213 and the length of the list were 47 as above, then the volume number would be 23, and the final position on the list would be (17 + 23**5) mod 47 or 39. The person with the number 39 (remembering that the list is numbered from 0 this is actually the 40th person) would become the first member. 4) Step three is repeated continuing from the current position on the list until all 10 members are selected. 5) In the event that there is a duplicate selection,simply continue down the list sequentially until you find a person who has not been selected. Continue the process from that position on the list. 6) If the most active stock is also one of the stocks I list for the selection, it will be used twice, once for the initial offset, and once for selecting a member. 7) The figures as reported in the SJMercury News are the official figures. In the event of a disagreement between the numbers in the SJMercury and any other publication, the SJMercury figures will be considered correct. 8) If any stock is not listed in the 20 September 1997 edition of the paper, OR HAS LESS THAN 100,000 in sales for the day, it will be replaced in order by one of the alternate stocks IN ITS PLACE - e.g. the other stocks on the list will retain their specific positions, rather than having the stock deleted and having the alternate stock added to the end of the list. 9) The list of stocks is as follows: Member 1) Apple Computer (reported as AppleC) 2) TCI Incorporated - Ticker: TCOMA (Replaces @Home) 3) Cisco Systems (reported as Cisco) 4) Cyber Cash (reported as CybrCsh) 5) Excite (reported as Excite) 6) Intel (reported as Intel) 7) MCI (reported as MCI) 8) Microsoft (reported as Microsft) 9) Netcom (reported as Netcom) 10) Netscape (reported as Netscpe) Alternate 1) Quantum 2) 3Com 3) Yahoo Expiring Terms: I believe these are the folks who's terms expire in March '98 In the IESG: Fred Baker IETF Chair Jeff Burgan Internet Joel Halpern Routing Keith Moore Applications Mike O'Dell Operations & Management Joyce K. Reynolds User Services Allyn Romanow Transport Jeff Schiller Security In the IAB: Brian Carpenter Steve Bellovin Jon Crowcroft Robert Elz John Klensin Radia Perlman   Received: from ietf.org by ietf.org id aa12722; 27 Aug 97 15:58 EDT Received: from ietf.ietf.org by ietf.org id aa12582; 27 Aug 97 15:49 EDT To: IETF-Announce: ; Subject: Third and last call for volunteers - Nominations Committee Date: Wed, 27 Aug 1997 15:49:02 -0400 Sender:ietf-announce-request@ietf.org From: Steve Coya Message-ID: <9708271549.aa12582@ietf.org> *****LAST CALL!!!!!!! LAST CALL!!!!!!!!***** *****List closes 1600 PDT 29 August 1997**** [This document has some changes from prior announcements, note the change in the list of stocks for the selection process, also includes list of people with expiring terms. - Mike] Hi - As you may or may not know I've been tapped to head this years IAB/IESG nominating committee. This is the second call for volunteers to participate as members of that committee. If you would like to volunteer, please send me email (to stjohns@corp.home.net) with the phrase "NOMCOM VOLUNTEER" (yes - all caps) in your subject line indicating your desire to participate. Please include your snail mail and phone numbers in the body of the message. To be eligible to serve on the NOMCOM, you must have attended 2 of the last 3 IETFs. Please make sure you can spend the time required to serve. Although there won't be any face to face meetings except for the December IETF, you will have to spend about 2 hours a week on the phone during the 12 active weeks of the nominations process (starting around the December IETF) in teleconferences with the entire nominations committee. You'll also be assigned various candidates to interview as part of the nominations process. Third and last call for volunteers will be next Wednesday, the 27th of August. Cutoff for accepting volunteers will be as of 1600 PDT on the 29th of August - specifically, they have to be in my email box at that time. Once I've got the complete list of volunteers, I'll post it and also ask that the Secretariat verify eligibility. The 10 members will be selected by lot based on the sales volume of 11 stocks as of the NASDAQ market close on 19 September as reported in the San Jose Mercury News on 20 September 1997. The procedure is as follows: 1) The Secretariat will provide the final list of eligibles listed in alphabetical order and numbered from 0 sequentially increasing and will mail this to the IETF and IETF-Announce list on or before the 17th of September. 2) The sales volume figure for the NASDAQ most active stock on the 19th of Sept will be used to provide an initial offset into the list. The 10,000s and 1,000s digit from the volume figure will be used to generate a "random" number from 00 to 99 (e.g. if the sales figure is 345,009,234 shares, the number is 09). The actual offset into the list is calculated as volnumber**5 mod the length of the list. So if the volume number is 9, the length of the list is 47, the offset would be 17. 3) Each stock in turn will then be used to select a nomcom member from the list by using the same procedure of extracting the 10,000 and 1000 digits, raising them to the 5th power, adding that to the current position number and then taking that mod the length of the list. So if the first of the listed stocks sales figure was 45,923,213 and the length of the list were 47 as above, then the volume number would be 23, and the final position on the list would be (17 + 23**5) mod 47 or 39. The person with the number 39 (remembering that the list is numbered from 0 this is actually the 40th person) would become the first member. 4) Step three is repeated continuing from the current position on the list until all 10 members are selected. 5) In the event that there is a duplicate selection,simply continue down the list sequentially until you find a person who has not been selected. Continue the process from that position on the list. 6) If the most active stock is also one of the stocks I list for the selection, it will be used twice, once for the initial offset, and once for selecting a member. 7) The figures as reported in the SJMercury News are the official figures. In the event of a disagreement between the numbers in the SJMercury and any other publication, the SJMercury figures will be considered correct. 8) If any stock is not listed in the 20 September 1997 edition of the paper, OR HAS LESS THAN 100,000 in sales for the day, it will be replaced in order by one of the alternate stocks IN ITS PLACE - e.g. the other stocks on the list will retain their specific positions, rather than having the stock deleted and having the alternate stock added to the end of the list. 9) The list of stocks is as follows: Member 1) Apple Computer (reported as AppleC) 2) TCI Incorporated - Ticker: TCOMA (Replaces @Home) 3) Cisco Systems (reported as Cisco) 4) Cyber Cash (reported as CybrCsh) 5) Excite (reported as Excite) 6) Intel (reported as Intel) 7) MCI (reported as MCI) 8) Microsoft (reported as Microsft) 9) Netcom (reported as Netcom) 10) Netscape (reported as Netscpe) Alternate 1) Quantum 2) 3Com 3) Yahoo Expiring Terms: I believe these are the folks who's terms expire in March '98 In the IESG: Fred Baker IETF Chair Jeff Burgan Internet Joel Halpern Routing Keith Moore Applications Mike O'Dell Operations & Management Joyce K. Reynolds User Services Allyn Romanow Transport Jeff Schiller Security In the IAB: Brian Carpenter Steve Bellovin Jon Crowcroft Robert Elz John Klensin Radia Perlman   Received: from ietf.org by ietf.org id aa13143; 27 Aug 97 16:15 EDT Received: from poptart.svr.home.net by ietf.org id aa13050; 27 Aug 97 16:14 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.corp.home.net (Netscape Mail Server v2.02) with ESMTP id AAA14240 for ; Wed, 27 Aug 1997 13:14:02 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id NAA11304 for ; Wed, 27 Aug 1997 13:14:01 -0700 (PDT) Message-Id: <199708272014.NAA11304@lock.eos.home.net> X-Mailer: exmh version 1.6.7 5/3/96 To: ietf@ietf.org Subject: List of nomcom volunteers and Acks! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 13:13:56 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. I'll be posting the list of volunteers I've received after 1600PDT on Friday. If you're not on the list and you think you are supposed to be, you can send me email up through the following Tuesday with some evidence that you actually sent the first email and I'll have you added to the list. Thanks - Mike   Received: from cnri by ietf.org id aa15168; 27 Aug 97 18:27 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA12073; Wed, 27 Aug 1997 18:31:02 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id QAA24451 for cat-ietf-redist; Wed, 27 Aug 1997 16:54:09 -0400 (EDT) To: cat-ietf@mit.edu From: Joe Salowey Subject: telnet and GSSAPI Date: Wed, 27 Aug 1997 13:52:55 -0700 Message-Id: <970827205255.930.392f.31009@Machiavelli.wrq.com.686DAB4DBCE948FB> X-Mailer: WRQ Reflection Mail Version 6.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Hi, I'm trying to find out if there is a spec or implementation of telnet that uses kerberos via GSSAPI. I've heard rumors that one exists and I've also heard that it's not possible. Any information would be appreciated. Thanks, Joe   Received: from cnri by ietf.org id aa04579; 28 Aug 97 7:57 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA13147; Thu, 28 Aug 1997 08:00:20 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id FAA04881 for cat-ietf-redist; Thu, 28 Aug 1997 05:44:21 -0400 (EDT) Message-Id: <3404B112.3483@frcl.bull.fr> Date: Wed, 27 Aug 1997 15:58:26 -0700 From: Denis Pinkas Reply-To: D.Pinkas@frcl.bull.fr Organization: Bull X-Mailer: Mozilla 3.01 [fr] (Win16; I) Mime-Version: 1.0 To: CAT-IETF WG , sommerfeld@apollo.hp.com, marc@cygnus.com Subject: SNEGO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk After reviewing a pile of 406 messages waiting for me, I am giving a top priority to the messages along SNEGO. I have taken a quick look at these messages. First of all, I am grateful to Bill for his upfront statement : "First, I would like to apologize for not having had the time to review snego-06 until the time of the meeting in munich; unfortunately, since the last IETF, my job has involved very little work related to GSSAPI or other CAT-area standards." Unfortunately, I did not get a similar statement from Marc. :-( John Linn wrote in a mesage from August 18 : " I'd like to propose the following plan on behalf of the WG: the concerns mentioned at the meeting (accompanied, if possible, by specific proposed changes to snego-06 text in order to reconcile those concerns) are to be identified to the mailing list no later than Wednesday, 27 August in order to enable review and discussion by the snego-06 document editors and the WG generally." At this time I would appreciate specific proposed changes to the current text. See later. > In section 2, there is still text about specifying a single option to > a mechanism by adding to the end of the mech OID. I thought this was > going to be removed. This technique has two problems. First, if you > want to specify two options, you can't. Second, there is nothing > preventing the owner of a bit of OID arc from defining two mechanisms > having OID's A.B.C.D and A.B.C.D.E. This makes it impossible to > distinguish the second mechanism from the first mechanism with option > E. In general, if we want to have a protocol for specifying mechanism > options outside the mechanism, I think we should do so in such a way > which does not require use of snego. I agree in principle with his comment but since that section is more than one page long, I would like to know where a change should be done and what kind of change would be satisfactory for Marc. > Section 3.1 describes the policy for the acceptor to choose a > mechanism. I thought we had decided that policy issues were a local > matter. About the section 3.2. concerning the policy for the acceptor, Marc thought that we had decided that policy issues were a local matter. IMHO, this has been one opinion raised a long time ago. Since then, several arguments have been exchanged which resulted in an algorithm which is described as the result of the discussion and at that time no one has complained. I am reluctant to re-open the discussion on this matter at this time. > Section 3.2: if the acceptor does not understand the negotiation > mechanism, GSS_S_BAD_MECH, not GSS_S_FAILURE, should be returned. O.K. > In the current text, the mechListMic is only in the NegTokenTarg, not > in the NegTokenInit. This means that if the client provides the last > token, then an additional message is necessary, just to carry the MIC. > This is wasteful; mechListMIC should be in NegTokenInit, and the MIC > should be in the same message as the final preferredToken, whether > generated by the initiator or acceptor. Bill adds at that matter: > Most importantly, the showstopper issue is that -06 adds an > unnecessary message to the exchange if the last message in the > underlying mechanism is in the initiator->acceptor direction. while I > don't have my notes handy, if I recall correctly, the `mechListMic > OPTIONAL' field was present in both message types (or perhaps in all > messages save the first, with the 2nd and subsequent i->a messages > using NegTokenTarg to encapsulate the inner mechanism; I believe we > discussed both possibilities). I read these messages twice and I have difficulties to understand the rational. May be my brain is still close by the Indian Ocean (where I had my vacations) while my body is in my office :-) I am not very keen to incorporate the OPTIONAL mechListMIC in NegTokenInit. When mechListMIC is in NegTokenTarg it is computed with the agreed mechanism, so it can always be there and useful. When mechListMIC is in the NegTokenInit, it is computed with the preferred mechanism from the client that can be not supported by the target and thus be unuseful. Anyway if Marc, Bill or some one else feels that it is a very important matter, could they provide an example first and then some more arguments ? > The negResult field is unnecessary. The initiator can determine if > the acceptor accepted a mechanism by checking for the presence of the > supportedMech field. Even if it was necessary, having two accept > values is redundant, as the initiator can tell from the underlying > mechanisms's return value from GSS_Init_sec_context if additional > further are necessary. As far as I recall, negResult had originally two values that were expanded to three values as the result of a question raised by John Linn. I have not browsed through all my E-mails to find it but simply speaking, I would expect that removing it would raised the concern of John Linn again. May be it would be good to add the rational for the existence of the three values (May John help on that topic ?) In any case removing would not be the right solution. > What is MechSpecInfo used for? I'd like to hear a concrete example > about how it is intended to be used, or see it removed from the draft. > As far as I can tell, whenever this sort of functionality might be > needed, it should be inside the preferredToken, and invisible to > snego. You asked for an example. Here it is : we use it to transmit one or more X.509 Certificates, that can be useful for the client as it avoids a lookup in a Directory, prior to any exchange of mechanism specific tokens. > In section 2, the draft describes negotiation tokens as "new GSS-API > context-level tokens". This is not accurate; they are simply > mechanism context-level tokens, like any other. O.K. > Appendix A: the functions' descriptions should explain how the > cred_handle is used by them. Could you explain more and provide text about it ? Denis -- Denis Pinkas Bull S.A. E-mail : D.Pinkas@frcl.bull.fr Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87 78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21   Received: from ietf.org by ietf.org id aa06906; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06058; 28 Aug 97 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: roamops@tdmx.rutgers.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-roamops-actng-03.txt Date: Thu, 28 Aug 1997 09:18:30 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280918.aa06058@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Roaming Operations Working Group of the IETF. Title : Session Record Accounting in Roaming Author(s) : J. Vollbrecht, B. Aboba, D. Lidyard Filename : draft-ietf-roamops-actng-03.txt Pages : 19 Date : 1997-08-26 This document describes the problems arising in session record accounting in roaming systems, and proposes a standard accounting record format. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-roamops-actng-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-actng-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-roamops-actng-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826111519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-roamops-actng-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-roamops-actng-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826111519.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06920; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06191; 28 Aug 97 9:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ietf-fax@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wing-smtp-session-00.txt Date: Thu, 28 Aug 1997 09:19:15 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280919.aa06191@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Immediate Delivery over SMTP Author(s) : N. Joffe, D. Wing, L. Masinter Filename : draft-wing-smtp-session-00.txt Pages : 12 Date : 26-Aug-97 This memo defines an extension to SMTP [RFC821] which provides a mechanism for immediate message delivery over ESMTP, bypassing SMTP's normal store-and-forward behavior. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wing-smtp-session-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-wing-smtp-session-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-wing-smtp-session-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826150906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wing-smtp-session-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wing-smtp-session-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826150906.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06918; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06161; 28 Aug 97 9:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: pmp@pwg.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-printmib-job-monitor-05.txt Date: Thu, 28 Aug 1997 09:19:01 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280919.aa06161@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Printer MIB Working Group of the IETF. Title : Job Monitoring MIB - V0.85 Author(s) : T. Hasting, H. Lewis, S. Isaacson, R. Bergman Filename : draft-ietf-printmib-job-monitor-05.txt Pages : 100 Date : 1997-08-26 This Internet-Draft specifies a small set of read-only SNMP MIB objects for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job. This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-printmib-job-monitor-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-printmib-job-monitor-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-printmib-job-monitor-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826145454.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-printmib-job-monitor-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-printmib-job-monitor-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826145454.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06926; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06142; 28 Aug 97 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kim-tld-class-00.txt Date: Thu, 28 Aug 1997 09:18:56 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280918.aa06142@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DNS Top Level Domain Name Classification and Structure Author(s) : J. Kim Filename : draft-kim-tld-class-00.txt Pages : 15 Date : 26-Aug-97 This document specifies a structural organization of Internet top level domain names based on the International Schedule of Classes of Goods and Services. This structure intends to provide a framework for classification such that web content providers can differentiate their goods and services and minimize the probability of name confusion and collision. Under each class, as specified by the International Schedule of Classes of Goods and Services, single or multiple top level domain names should be specified each appropriately partitioning the class of goods or service into an appropriate sub-categorization. A method will further be described to incorporate additions/modifications as becomes necessary by as of yet unforseen future developments. This document does not address the delegation or the administration of top level domain names which the author feels should be considered separately. However, the author does acknowledge that some form of centralized authority should be in place to properly control the structure to be described. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kim-tld-class-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-kim-tld-class-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kim-tld-class-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826144916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kim-tld-class-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kim-tld-class-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826144916.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06922; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06015; 28 Aug 97 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-radius@livingston.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radius-auth-clientmib-00.txt Date: Thu, 28 Aug 1997 09:18:18 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280918.aa06015@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Authentication Client MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-auth-clientmib-00.txt Pages : Date : 26-Aug-97 This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-auth-clientmib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-radius-auth-clientmib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-radius-auth-clientmib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826110612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-clientmib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-clientmib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826110612.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06908; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06230; 28 Aug 97 9:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ion@nexen.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ion-mars-mib-02.txt Date: Thu, 28 Aug 1997 09:19:24 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280919.aa06230@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks Author(s) : M. Greene, C. Chung Filename : draft-ietf-ion-mars-mib-02.txt Pages : 63 Date : 1997-08-26 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI 3.0/3.1 based ATM Networks' [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ion-mars-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-mars-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ion-mars-mib-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826172540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-mars-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ion-mars-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826172540.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06915; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06076; 28 Aug 97 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: mobile-ip@smallworks.com, ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-montenegro-tsp-00.txt Date: Thu, 28 Aug 1997 09:18:35 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280918.aa06076@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tunnel Set-up Protocol (TSP) Author(s) : G. Montenegro Filename : draft-montenegro-tsp-00.txt Pages : 19 Date : 26-Aug-97 Remote access over the internet and IP mobility are currently being addressed as two separate problems. The L2TP specification is defining a protocol, or rather a tunnel control mechanism to solve the remote access problem. On the other hand, the Mobile IP working group has been solving the mobility problem. Nevertheless, the same solution applies to both problems, namely, tunneling. This document defines a Tunnel Set-up Protocol (TSP) that solves both problems using a common approach. TSP is heavily based on the control messages defined by Mobile IP. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-montenegro-tsp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-montenegro-tsp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-montenegro-tsp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826112743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-tsp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-tsp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826112743.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06919; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa05995; 28 Aug 97 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-radius@livingston.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radius-acc-servmib-00.txt Date: Thu, 28 Aug 1997 09:18:09 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280918.aa05995@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Accounting Server MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-acc-servmib-00.txt Pages : 10 Date : 26-Aug-97 This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-acc-servmib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-radius-acc-servmib-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-radius-acc-servmib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826110240.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-servmib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-servmib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826110240.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa06905; 28 Aug 97 9:36 EDT Received: from ietf.ietf.org by ietf.org id aa06248; 28 Aug 97 9:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-md5-05.txt Date: Thu, 28 Aug 1997 09:19:31 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280919.aa06248@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Title : RSVP Cryptographic Authentication Author(s) : F. Baker Filename : draft-ietf-rsvp-md5-05.txt Pages : 15 Date : 1997-08-26 This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-md5-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-md5-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-md5-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826172226.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-md5-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-md5-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826172226.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07189; 28 Aug 97 9:43 EDT Received: from ietf.ietf.org by ietf.org id aa06118; 28 Aug 97 9:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-acap+@andrew.cmu.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-acap-anon-01.txt Date: Thu, 28 Aug 1997 09:18:51 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280918.aa06118@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Configuration Access Protocol Working Group of the IETF. Title : Anonymous SASL Mechanism Author(s) : C. Newman Filename : draft-ietf-acap-anon-01.txt Pages : 4 Date : 1997-08-26 It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-acap-anon-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-acap-anon-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-acap-anon-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826142408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-acap-anon-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-acap-anon-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826142408.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id ab07189; 28 Aug 97 9:43 EDT Received: from ietf.ietf.org by ietf.org id aa06179; 28 Aug 97 9:19 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org cc: ietf-fax@imc.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-wing-smtp-capabilities-00.txt Date: Thu, 28 Aug 1997 09:19:12 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708280919.aa06179@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Capabilities Exchange over SMTP Author(s) : N. Joffe, D. Wing Filename : draft-wing-smtp-capabilities-00.txt Pages : 7 Date : 1997-08-26 This document describes an extension to SMTP [RFC821] which provides a mechanism for capabilities exchange so the sender knows the capabilities of the ultimate recipient or the ESMTP server itself. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-wing-smtp-capabilities-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-wing-smtp-capabilities-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-wing-smtp-capabilities-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970826150620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-wing-smtp-capabilities-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-wing-smtp-capabilities-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970826150620.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07943; 28 Aug 97 10:14 EDT Received: from ietf.ietf.org by ietf.org id aa07819; 28 Aug 97 10:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rfced-info-stanislevic-00.txt Date: Thu, 28 Aug 1997 10:10:37 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708281010.aa07819@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : End-to-End Throughput and Response Time Testing With HTTP User Agents and the JavaScript Language Author(s) : H. Stanislevic Filename : draft-rfced-info-stanislevic-00.txt Pages : 19 Date : 25-Aug-97 This memo describes two simple metrics and a methodology for testing end-to-end one-way data throughput and two-way response time at the application layer utilizing HTTP [1] (web) servers and user agents (web browsers). Two Interactive Hypertext Transfer Test (IHTTT) implementations are described in detail. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rfced-info-stanislevic-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-stanislevic-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-rfced-info-stanislevic-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970825104927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rfced-info-stanislevic-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rfced-info-stanislevic-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970825104927.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa14221; 28 Aug 97 15:37 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA14392; Thu, 28 Aug 1997 15:40:45 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id NAA21437 for cat-ietf-redist; Thu, 28 Aug 1997 13:36:04 -0400 (EDT) Message-Id: <3.0.1.32.19970828133344.007de710@world.std.com> X-Sender: linn@world.std.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 28 Aug 1997 13:33:44 -0400 To: D.Pinkas@frcl.bull.fr, CAT-IETF WG From: John Linn Subject: Re: SNEGO In-Reply-To: <3404B112.3483@frcl.bull.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk At 03:58 PM 8/27/97 -0700, Denis Pinkas wrote, excerpting: >> The negResult field is unnecessary. The initiator can determine if >> the acceptor accepted a mechanism by checking for the presence of the >> supportedMech field. Even if it was necessary, having two accept >> values is redundant, as the initiator can tell from the underlying >> mechanisms's return value from GSS_Init_sec_context if additional >> further are necessary. > >As far as I recall, negResult had originally two values that were >expanded to three values as the result of a question raised by John >Linn. I have not browsed through all my E-mails to find it but simply >speaking, I would expect that removing it would raised the concern of >John Linn again. May be it would be good to add the rational for the >existence of the three values (May John help on that topic ?) In any >case removing would not be the right solution. > I think the following is the point I'd made (in April, against then-current snego-04) which led to adding a third value for negResult. Date: Wed, 30 Apr 1997 12:01:41 -0400 From: John Linn Here are some comments and questions on snego-04: A fairly subtle point strikes me regarding the 4th paragraph on page 3. Consider the possibility that the target accepts the preferred mechanism but does not perform optimistic negotiation so doesn't process the enclosed preferredToken; such a target would respond with a negResult of "accept" and a supportedMech indicating the preferred mechanism. For the case of a preferred mechanism which (a) employs a single-token context setup and (b) does not support the integrity facility which would cause a mechListMIC to be generated and enclosed, how does the initiator disambiguate whether such a reply constitutes successfully completed context establishment or whether it must instead resend (or regenerate) the mechanism's token for transfer in what one might describe as "pessimistic fallback mode"? --jl   Received: from cnri by ietf.org id aa15702; 28 Aug 97 16:51 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA14604; Thu, 28 Aug 1997 16:54:10 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id NAA22731 for cat-ietf-redist; Thu, 28 Aug 1997 13:49:21 -0400 (EDT) Message-Id: <199708281749.AA15726@sap-ag.de> From: Martin Rex Subject: Re: SNEGO To: D.Pinkas@frcl.bull.fr Date: Thu, 28 Aug 1997 19:48:29 +0200 (MESZ) Cc: cat-ietf@mit.edu, marc@cygnus.com In-Reply-To: <3404B112.3483@frcl.bull.fr> from "Denis Pinkas" at Aug 27, 97 03:58:26 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Denis Pinkas wrote: > Marc Horowitz wrote: > > Section 3.1 describes the policy for the acceptor to choose a > > mechanism. I thought we had decided that policy issues were a local > > matter. > > About the section 3.2. concerning the policy for the acceptor, Marc > thought that we had decided that policy issues were a local matter. > IMHO, this has been one opinion raised a long time ago. Since then, > several arguments have been exchanged which resulted in an algorithm > which is described as the result of the discussion and at that time no > one has complained. I am reluctant to re-open the discussion on this > matter at this time. Here's what I remember: You had an explicit policy for how to select a common mechanism in your document and Mike Swift brought up a strong argument against it. I think it was something like: "Microsoft would like to use a different policy for selection and when retaining an explicit selection policy in the spec, this would make their implementation "non-conforming". But a mandated selection policy is not needed for interoperability. I don't remember any substantial argument for mandating an explicit selection policy from the discussion on the list, so I would agree with Marc: there is "rough consensus" for making it a local matter, since the valid argument against mandating it wasn't removed. It may be that this was never "formally summarized" and listed as a pending issue against your draft until Marc's latest comment. > > > Section 3.2: if the acceptor does not understand the negotiation > > mechanism, GSS_S_BAD_MECH, not GSS_S_FAILURE, should be returned. > > O.K. > > > In the current text, the mechListMic is only in the NegTokenTarg, not > > in the NegTokenInit. This means that if the client provides the last > > token, then an additional message is necessary, just to carry the MIC. > > This is wasteful; mechListMIC should be in NegTokenInit, and the MIC > > should be in the same message as the final preferredToken, whether > > generated by the initiator or acceptor. > > Bill adds at that matter: > > > Most importantly, the showstopper issue is that -06 adds an > > unnecessary message to the exchange if the last message in the > > underlying mechanism is in the initiator->acceptor direction. while I > > don't have my notes handy, if I recall correctly, the `mechListMic > > OPTIONAL' field was present in both message types (or perhaps in all > > messages save the first, with the 2nd and subsequent i->a messages > > using NegTokenTarg to encapsulate the inner mechanism; I believe we > > discussed both possibilities). > > I read these messages twice and I have difficulties to understand the > rational. May be my brain is still close by the Indian Ocean (where I > had my vacations) while my body is in my office :-) > > I am not very keen to incorporate the OPTIONAL mechListMIC in > NegTokenInit. When mechListMIC is in NegTokenTarg it is computed with > the agreed mechanism, so it can always be there and useful. When > mechListMIC is in the NegTokenInit, it is computed with the preferred > mechanism from the client that can be not supported by the target and > thus be unuseful. It is about as useless as the optimistic token. If the optimistic token is useful, then the mechListMIC is equally useful. The whole point about the optimistic stuff is to retain the minimum number of exchanges that would be required even without spnego. The "protected negotiation" was proposed after the "optimistic negotiation", and therefore applying optimistic protection of the negotiation seems rather logical to me. I'm more an gssapi application user than a gssapi mechanism provider and hesitant to touch ASN.1 compilers, so I didn't examine the details in this part of the spec -- I'm sorry. > > Anyway if Marc, Bill or some one else feels that it is a very important > matter, could they provide an example first and then some more arguments > ? Since I'm not going to implement spnego in the forseeable future and can't comment on the ASN.1-related impact on complexity, let me at least state that the request sounds very reasonable to me. > > > What is MechSpecInfo used for? I'd like to hear a concrete example > > about how it is intended to be used, or see it removed from the draft. > > As far as I can tell, whenever this sort of functionality might be > > needed, it should be inside the preferredToken, and invisible to > > snego. > > You asked for an example. Here it is : we use it to transmit one or more > X.509 Certificates, that can be useful for the client as it avoids a > lookup in a Directory, prior to any exchange of mechanism specific > tokens. Your example is certainly a valid goal. Using an otherwise semantically undefined field in the spec might not be the best approach. The spec should provide for broad interoperability. Having a field with no semantics is bound to cause interoperability problems. In case that field is to be retained at all, it should receive an additional identifier for the acutal contents where specific semantics can be indicated (at least one may have to be documented to justify the existence of the field...). I agree with Marc; extenstions that are completely implementation defined should preferably be completely hidden in the implementation. -Martin   Received: from ietf.org by ietf.org id aa16553; 28 Aug 97 17:36 EDT Received: from ietf.ietf.org by ietf.org id aa16403; 28 Aug 97 17:28 EDT To: IETF-Announce: ; Subject: S/MIME and the IETF Sender:ietf-announce-request@ietf.org From: "Jeffrey I. Schiller" Date: Thu, 28 Aug 1997 17:28:26 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9708281728.aa16403@ietf.org> There has been a lot of coverage in the press recently about the relationship of S/MIME and the IETF. The purpose of this note is to clarify the situation from my perspective and to show the way into the future. Back last April at the Memphis meeting I attended and addressed the 2nd S/MIME BOF session. As you are probably aware, the IETF process permits a group of people to meet as a BOF for two session prior to either disbanding or deciding to propose a charter for a formal IETF Working Group. The primary purpose of BOF sessions is to gauge interest in the standardization of a solution for a particular technology problem. At that BOF meeting I informed the group of the ground rules and pne-conditions that I felt were necessary for the IETF to be willing to charter a Working Group in the S/MIME arena. To push things along I established a deadline of last July 1st for the group to either produce a proposed charter or decide to not pursue an S/MIME within the IETF standard. July came and went without such a charter being proposed. At the recent Munich meeting a BOF was held on "Open PGP" and that group agreed to quickly put together a charter for an "Open PGP/MIME" Working Group. That effort is ongoing. Since then the S/MIME proponents have come back to me claiming that they misunderstood the nature of the July 1st deadline and expnessed an interest in pursuing an S/MIME Working Group charter. Given that some of the key S/MIME participants were not pnesent at the meeting in Memphis and the results of that meeting were variously reported, it is quite possible that reasonable people misunderstood what was required. The IESG discussed this situation at our teleconference this morning and we agreed on the following position: 1. We are pnepared to set aside the July 1st deadline on the grounds that there is sufficient confusion that reasonable people may not have understood what was required. 2. Before the IESG would consider chartering a working group on S/MIME RSA Data Security (or appropriate parent company) needs to execute an agreement with the Internet Society along the lines of the agreement between Sun Microsystems and the ISOC as documented in RFC1790. 3. Note: The IESG/IAB is not making a commitment to charter the group at this time. Point (2) is a pne-requisite, not a quid-pro-quo. At such time that a charter is proposed to the IESG/IAB, we will evaluate that proposal on its merits (as we do all proposed charters) and make a decision at that time. -Jeff   Received: from ietf.org by ietf.org id aa07508; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06581; 29 Aug 97 9:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-stager-pdc-netapp-backup-03.txt Date: Fri, 29 Aug 1997 09:55:56 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290955.aa06581@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PDC/NetApp Backup Protocol Author(s) : D. Hitz, R. Stager Filename : draft-stager-pdc-netapp-backup-03.txt Pages : 114 Date : 1997-08-28 The Network Data Management Protocol ('NDMP') is an open protocol for enterprise-wide network based backup. The NDMP architecture allows network-attached file servers to ship with a 'universal agent,' which can be used by any NDMP-compliant backup administration application. This same universal agent architecture is also used for network-attached backup devices, such as a tape drives and tape libraries. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-stager-pdc-netapp-backup-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-stager-pdc-netapp-backup-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-stager-pdc-netapp-backup-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828154647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stager-pdc-netapp-backup-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-stager-pdc-netapp-backup-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828154647.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07537; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06735; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-guaranteed-mib-04.txt Date: Fri, 29 Aug 1997 09:56:38 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06735@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Integrated Services Management Information Base Guaranteed Service Extensions Author(s) : F. Baker Filename : draft-ietf-intserv-guaranteed-mib-04.txt Pages : 14 Date : 28-Aug-97 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-intserv-guaranteed-mib-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-guaranteed-mib-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828160334.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-guaranteed-mib-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828160334.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07514; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06636; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: tn3270e@list.nih.gov Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-tn3270e-tn3270-mib-02.txt Date: Fri, 29 Aug 1997 09:56:08 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06636@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telnet TN3270 Enhancements Working Group of the IETF. Title : Base Definitions of Managed Objects for TN3270E Using SMIv2 Author(s) : K. White Filename : draft-ietf-tn3270e-tn3270-mib-02.txt Pages : 29 Date : 1997-08-28 The purpose of this memo is to define a Management Information Base (MIB) for configuring and managing TN3270E Servers. The MIB defined by this memo is intended to provide generic support for both Host and Gateway TN3270E Server implementations. It is the intent that the MIB defined herein be extended by subsequent memos to provide non-generic configuration support and to enable TN3270E Response Time Collection. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of the Simple Network Management Protocol Version (refer to RFC1902, reference [1]). Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tn3270e-tn3270-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-tn3270e-tn3270-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-tn3270e-tn3270-mib-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828133553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tn3270e-tn3270-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tn3270e-tn3270-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828133553.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07491; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06672; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-newman-tls-imappop-00.txt Date: Fri, 29 Aug 1997 09:56:15 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06672@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protecting IMAP4 and POP3 Connections Author(s) : C. Newman Filename : draft-newman-tls-imappop-00.txt Pages : 9 Date : 28-Aug-97 The TLS protocol [TLS] (formerly known as SSL) provides a way to secure a connection from tampering and evesdropping. Obviously, such security is desirable for IMAP [IMAP4] and POP [POP3]. Although advanced authentication mechanisms [IMAP-AUTH, POP-AUTH] can provide this service with less complexity than TLS, TLS is useful in combination with plaintext password logins and other simple mechanisms as it doesn't require a site to upgrade its authentication database. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-newman-tls-imappop-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-tls-imappop-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-newman-tls-imappop-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828142554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-newman-tls-imappop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-newman-tls-imappop-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828142554.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07490; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06562; 29 Aug 97 9:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-simpson-spki-shrinkwrap-00.txt Date: Fri, 29 Aug 1997 09:55:54 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290955.aa06562@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPKI: ShrinkWrap Author(s) : W. Simpson, A. Keromytis Filename : draft-simpson-spki-shrinkwrap-00.txt Pages : 7 Date : 28-Aug-97 This protocol facilitates the use of Simple Public Key Infrastructure [SPKI] certificate chains with Internet Protocol Security [IPS] key management protocols. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-simpson-spki-shrinkwrap-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-spki-shrinkwrap-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-simpson-spki-shrinkwrap-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828134845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-simpson-spki-shrinkwrap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-spki-shrinkwrap-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828134845.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07534; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06739; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: int-serv@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-intserv-mib-10.txt Date: Fri, 29 Aug 1997 09:56:43 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06739@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Services Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Integrated Services Management Information Base Author(s) : F. Baker, J. Krawczyk Filename : draft-ietf-intserv-mib-10.txt Pages : 29 Date : 28-Aug-97 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-intserv-mib-10.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-mib-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-intserv-mib-10.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828160557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-intserv-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-intserv-mib-10.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828160557.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07533; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06691; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-ppp@merit.edu, l2tp@zendo.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-06.txt Date: Fri, 29 Aug 1997 09:56:25 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06691@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Layer Two Tunneling Protocol 'L2TP' Author(s) : W. Palter, T. Kolar, G. Pall, M. Littlewood, A. Valencia, K. Hamzeh, W. Verthein, J. Taarud, W. Townsley Filename : draft-ietf-pppext-l2tp-06.txt Pages : 79 Date : 1997-08-28 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2tp-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828143852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828143852.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07512; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06609; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ogawa-responder-shortcut-path-00.txt Date: Fri, 29 Aug 1997 09:56:05 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06609@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Responder-Initiated Shortcut Path Protocol (RISP) Author(s) : Y. Chen, J. Ogawa Filename : draft-ogawa-responder-shortcut-path-00.txt Pages : Date : 28-Aug-97 This memo describes a peer-to-peer protocol to set up shortcut paths in an environment where an internetworking (L3) protocol, such as IP, overlays a link-layer (L2) protocol such as ATM. In such a network, L3 routing is the default mechanism for data transfer but it is also possible to set up direct L2 paths such as ATM VCs, that bypass L3 routing, so as to expedite the transfer of data. The protocol described in this memo can be applied as an inter-LIS (Logical IP Subnetwork) shortcut protocol when an L2 subnetwork is configured into multiple LISs. It can also be used as an independent protocol to set up direct L2 paths. In this way, it operates without L2 address resolution servers and allows the use of conventional routers (those without address resolution function) in the network. Therefore, it is useful for networks that have no available L2 address resolution service. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ogawa-responder-shortcut-path-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ogawa-responder-shortcut-path-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ogawa-responder-shortcut-path-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828113250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ogawa-responder-shortcut-path-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ogawa-responder-shortcut-path-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828113250.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07505; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06654; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-newman-msgheader-originfo-02.txt Date: Fri, 29 Aug 1997 09:56:12 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06654@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Originator-Info Message Header Author(s) : C. Newman Filename : draft-newman-msgheader-originfo-02.txt Pages : 7 Date : 1997-08-28 This proposal is an attempt to provide a standard header to indicate information about the message originator without implying that there is a deliverable mailbox or mandating that internal network information be revealed. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-newman-msgheader-originfo-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-newman-msgheader-originfo-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-newman-msgheader-originfo-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828135519.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-newman-msgheader-originfo-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-newman-msgheader-originfo-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828135519.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07511; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06710; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-apple-schema-rqmts-list-01.txt Date: Fri, 29 Aug 1997 09:56:30 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06710@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Directory Schema Listing Requirements Author(s) : C. Apple Filename : draft-apple-schema-rqmts-list-01.txt Pages : 12 Date : 1997-08-28 This memo documents requirements for listing directory services schemas in a centrally operated, administered, and maintained repository. This repository will be available as a resource to directory protocol and service implementors to facilitate schema discovery. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-apple-schema-rqmts-list-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-apple-schema-rqmts-list-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-apple-schema-rqmts-list-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828144831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-apple-schema-rqmts-list-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-apple-schema-rqmts-list-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828144831.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07503; 29 Aug 97 10:18 EDT Received: from ietf.ietf.org by ietf.org id aa06601; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: dhcp-v4@bucknell.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-authentication-04.txt Date: Fri, 29 Aug 1997 09:56:01 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06601@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Authentication for DHCP Messages Author(s) : R. Droms Filename : draft-ietf-dhc-authentication-04.txt Pages : 8 Date : 28-Aug-97 The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-authentication-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-authentication-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dhc-authentication-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828101139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-authentication-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-authentication-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828101139.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa07768; 29 Aug 97 10:23 EDT Received: from ietf.ietf.org by ietf.org id aa06771; 29 Aug 97 9:56 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: rsvp@isi.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rsvp-mib-10.txt Date: Fri, 29 Aug 1997 09:56:49 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9708290956.aa06771@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Reservation Setup Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : RSVP Management Information Base Author(s) : F. Baker, J. Krawczyk, A. Sastry Filename : draft-ietf-rsvp-mib-10.txt Pages : 83 Date : 28-Aug-97 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for managing the Resource Reservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu. This memo does not, in its draft form, specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rsvp-mib-10.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-rsvp-mib-10.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970828160828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rsvp-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rsvp-mib-10.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970828160828.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa11151; 29 Aug 97 13:14 EDT Received: from poptart.svr.home.net by ietf.org id aa11075; 29 Aug 97 13:11 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.corp.home.net (Netscape Mail Server v2.02) with ESMTP id AAA26139; Fri, 29 Aug 1997 10:11:40 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id KAA20206; Fri, 29 Aug 1997 10:11:40 -0700 (PDT) Message-Id: <199708291711.KAA20206@lock.eos.home.net> X-Mailer: exmh version 1.6.7 5/3/96 To: ietf@ietf.org cc: scoya@CNRI.Reston.VA.US Subject: Revised nomcom selection algorithm Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 10:11:34 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. [Steve please reflect onto the IETF-Announce list] I've been approached by a few of the statisticians in our ranks who have pointed out some possible biases in the mechanism for generating the next nom-com. Specifically that for certain lengths of the candidate list, certain people on the list (when ordered alphabetically) have a much greater chance of being selected. So... here's version two. Still uses the stock market, but needs double the number of stocks to get enough randomness. The 10 members will be selected by lot based on the sales volume of 21 stocks as of the NASDAQ market close on 19 September as reported in the San Jose Mercury News on 20 September 1997. The procedure is as follows: 1) The Secretariat will provide the final list of eligibles listed in alphabetical order and numbered from 0 sequentially increasing and will mail this to the IETF and IETF-Announce list on or before the 17th of September. 2) The sales volume figure for the NASDAQ most active stock on the 19th of Sept will be used to provide an initial offset into the list. The 100,000s, 10,000s, 1,000s and 100s digits from the volume figure will be used to generate a "random" number from 0000 to 9999 (e.g. if the sales figure is 345,209,234 shares, the number is 2092). The actual offset into the list is calculated as volnumber mod the length of the list. So if the volume number is 2092, the length of the list is 47, the offset would be 24. 3) Each pair of stocks in turn will then be used to select a nomcom member from the list by using the same procedure of extracting the 10,000s, 1,000s, and 100s digits from the first stock and concatenating them with the same digits from the second stock to give a number from 000000 to 999999, adding that to the current position number and then taking that mod the length of the list. So if the first of the listed stocks sales figure was 45,923,213, the second was 190,231, and the length of the list was 47 as above, then the volume number would be 232902, and the final position on the list would be (24+23902) mod 47 or 41. The person with the number 41 (remembering that the list is numbered from 0 this is actually the 42nd person) would become the first member. 4) Step three is repeated continuing from the current position on the list until all 10 members are selected. 5) In the event that there is a duplicate selection,simply continue down the list sequentially until you find a person who has not been selected. Continue the process from that position on the list. 6) If the most active stock is also one of the stocks I list for the selection, it will be used twice, once for the initial offset, and once for selecting a member. 7) The figures as reported in the SJMercury News (stock listings, not Market Roundup) are the official figures. In the event of a disagreement between the numbers in the SJMercury and any other publication, the SJMercury figures will be considered correct. 8) If any stock is not listed in the 20 September 1997 edition of the paper, it will be replaced in order by one of the alternate stocks IN ITS PLACE - e.g. the other stocks on the list will retain their specific positions, rather than having the stock deleted and having the alternate stock added to the end of the list. 9) The list of stocks is as follows: Member 1) Apple Computer (reported as AppleC) & Ascend 2) TCI Incorporated - (reported as TeleComA) & Micro Age 3) Cisco Systems (reported as Cisco) & Intuit 4) Biogen & Dell Computer (reported as DellCpt) 5) Excite (reported as Excite) & UglyDuck 6) Intel (reported as Intel) & Qualcom 7) MCI (reported as MCI) & Adobe Systems (reported as AdobeSy) 8) Microsoft (reported as Microsft) & Infoseek 9) Netcom (reported as Netcom) & Cirrus 10) Netscape (reported as Netscpe) & CompuServe (reported as CmpuSrv) Alternate 1) Quantum 2) 3Com 3) Yahoo Sample numbers from the 29 August SJMercury Most active: Altera - 18349500 == 3495 1) 542544 2) 158772 3) 383596 4) 468349 5) 205069 6) 544218 7) 020558 8) 552796 9) 976000 10) 278829 Expiring Terms: I believe these are the folks who's terms expire in March '98 In the IESG: Fred Baker IETF Chair Jeff Burgan Internet Joel Halpern Routing Keith Moore Applications Mike O'Dell Operations & Management Joyce K. Reynolds User Services Allyn Romanow Transport Jeff Schiller Security In the IAB: Brian Carpenter Steve Bellovin Jon Crowcroft Robert Elz John Klensin Radia Perlman   Received: from ietf.org by ietf.org id aa11485; 29 Aug 97 13:28 EDT Received: from zipper.cisco.com by ietf.org id aa11432; 29 Aug 97 13:26 EDT Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by zipper.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id KAA05620; Fri, 29 Aug 1997 10:25:57 -0700 (PDT) X-Sender: bstewart@zipper.cisco.com Message-Id: In-Reply-To: <199708291711.KAA20206@lock.eos.home.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Aug 1997 13:25:18 -0400 To: "Mike St. Johns" Sender:ietf-request@ietf.org From: Bob Stewart Subject: Re: Revised nomcom selection algorithm Cc: ietf@ietf.org, scoya@CNRI.Reston.VA.US Source-Info: From (or Sender) name not authenticated. Circa 10:11 AM -0700 8/29/97, Mike St. Johns bitwhacked: >I've been approached by a few of the statisticians in our ranks who have >pointed out some possible biases in the mechanism for generating the next >nom-com. Technology is fun but when it gets complicated it has unintended consequences. I like the approach of having an unimpeachable, disinterested person pick names out of a hat. Then you only have to worry about having the slips of paper the same size, mixing them up well, and holding the hat high enough. Bob   Received: from cnri by ietf.org id aa11738; 29 Aug 97 13:43 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA17376; Fri, 29 Aug 1997 13:46:22 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id MAA28139 for cat-ietf-redist; Fri, 29 Aug 1997 12:12:59 -0400 (EDT) Date: Fri, 29 Aug 1997 12:12:43 -0400 Message-Id: <199708291612.MAA29214@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Joe Salowey Cc: cat-ietf@mit.edu In-Reply-To: Joe Salowey's message of Wed, 27 Aug 1997 13:52:55 -0700, <970827205255.930.392f.31009@Machiavelli.wrq.com.686DAB4DBCE948FB> Subject: Re: telnet and GSSAPI Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Joe Salowey Date: Wed, 27 Aug 1997 13:52:55 -0700 I'm trying to find out if there is a spec or implementation of telnet that uses kerberos via GSSAPI. I've heard rumors that one exists and I've also heard that it's not possible. Any information would be appreciated. There certainly isn't a public specification for how it would be done. Some folks at (I think) TIS were looking into doing a telnet implementation that would use GSSAPI as part of the FORTEZZA project, but I don't know if that ever got anywhere or not. The problem with using GSSAPI with the telnet protocol is that you really somewhich can handle efficient encryption of a stream, and GSSAPI is very block-oriented. You could call gss_wrap() for every character, but there might be as much as a 32 byte (or even higher) overhead PER CHARACTER. This is definitely something you wouldn't want to use over a dialup connection! As a result, the published specification for how to use Kerberos with telent does not use the GSSAPI, but instead uses Kerberos to negotiate the session key, and then uses DES directly to handle the encryption of the stream. One could do the same with the GSSAPI --- use GSSAPI to set up a security context, then using crypto code outside the GSSAPI library, generate a random session key, which is sent over the wire using gss_wrap(), and then encrypt the rest of the session using that key and crypto code which is all outside the GSSAPI. However, you lose a lot of the point of the GSSAPI by doing this, so why bother? - Ted   Received: from ietf.org by ietf.org id aa12413; 29 Aug 97 14:09 EDT Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa12350; 29 Aug 97 14:08 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA11448; Fri, 29 Aug 97 14:08:19 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id OAA07473; Fri, 29 Aug 1997 14:08:14 -0400 Date: Fri, 29 Aug 1997 14:08:14 -0400 Message-Id: <199708291808.OAA07473@dcl.MIT.EDU> Sender:ietf-request@ietf.org From: "Theodore Y. Ts'o" To: Bob Stewart Cc: "Mike St. Johns" , ietf@ietf.org, scoya@CNRI.Reston.VA.US In-Reply-To: Bob Stewart's message of Fri, 29 Aug 1997 13:25:18 -0400, Subject: Re: Revised nomcom selection algorithm Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Source-Info: From (or Sender) name not authenticated. Date: Fri, 29 Aug 1997 13:25:18 -0400 From: Bob Stewart I like the approach of having an unimpeachable, disinterested person pick names out of a hat. Then you only have to worry about having the slips of paper the same size, mixing them up well, and holding the hat high enough. That works fine as long as you can find someone which is unimeachable to everyone in the IETF. We tried using a local clergy person but people still didn't believe that the fix wasn't in. I suppose we could use a committe of clerics from (say) Islam, Eastern Orthordox, Roman Cathlog, and Jewish faiths. Now how do you find someone to represent those of agnostic or atheistic pursuasions? :-) - Ted   Received: from ietf.org by ietf.org id aa12640; 29 Aug 97 14:18 EDT Received: from poptart.svr.home.net by ietf.org id aa12587; 29 Aug 97 14:17 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.corp.home.net (Netscape Mail Server v2.02) with ESMTP id AAA3858; Fri, 29 Aug 1997 11:17:20 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id LAA20540; Fri, 29 Aug 1997 11:17:19 -0700 (PDT) Message-Id: <199708291817.LAA20540@lock.eos.home.net> X-Mailer: exmh version 1.6.7 5/3/96 To: "Theodore Y. Ts'o" cc: Bob Stewart , ietf@ietf.org, scoya@CNRI.Reston.VA.US Subject: Re: Revised nomcom selection algorithm In-reply-to: Your message of Fri, 29 Aug 1997 14:08:14 -0400. <199708291808.OAA07473@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 11:17:14 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. > Now how do you find someone to represent those of > agnostic or atheistic pursuasions? :-) > > - Ted Here come da' judge..   Received: from ietf.org by ietf.org id aa13962; 29 Aug 97 15:32 EDT Received: from harrier.cisco.com by ietf.org id aa13844; 29 Aug 97 15:29 EDT Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by harrier.cisco.com (8.6.12/8.6.5) with ESMTP id MAA16088 for ; Fri, 29 Aug 1997 12:28:58 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199708291711.KAA20206@lock.eos.home.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Aug 1997 12:16:58 -0700 To: ietf@ietf.org Sender:ietf-request@ietf.org From: Fred Baker Subject: Re: Revised nomcom selection algorithm Source-Info: From (or Sender) name not authenticated. At 10:11 AM -0700 8/29/97, Mike St. Johns wrote: >I've been approached by a few of the statisticians in our ranks who have >pointed out some possible biases in the mechanism for generating the next >nom-com. Gee whiz; some of your predecessors (most of them, I think) wrote the names on equal-sized bits of paper, put them in a hat, and got some reputed-to-be-trustworthy soul to pull out the requisite number. We're getting to the point that we need to go on the Lotto TV show, write the names on golf balls, and have the world watch while a dozen or so randomly bounce out of a juggling cage - to the sound of some guy in the audience wondering aloud if all the balls were identical. Seems like we're putting as much work into the selection procedure for the nomcom than the nomcom will put into the selection of nominees :^) A call for peace here: I think there are quite a few folks who themselves are trying very hard to be above reproach, and who are getting very little trust or support from the rest of us. The remarks of one Jim Fleming come to mind; if the folks in leadership positions in the IETF and IANA were doing 1% of what he can't seem to send a single email without accusing them of, they would all be in jail for long sentences and there would be nothing left to discuss. I'll vouch for Mike's integrity here; I wouldn't have recommended him for the job without being able to do so without a thought. There's no ballot-box-fixing going on here. Can he, please, just get the right number of names picked and get on with it? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "There is no limit to what can be accomplished if it doesn't matter who gets the credit" Ralph Waldo Emerson   Received: from cnri by ietf.org id aa14090; 29 Aug 97 15:39 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA17873; Fri, 29 Aug 1997 15:43:00 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id OAA09651 for cat-ietf-redist; Fri, 29 Aug 1997 14:07:28 -0400 (EDT) To: "Theodore Y. Ts'o" Cc: Joe Salowey , cat-ietf@mit.edu Subject: Re: telnet and GSSAPI References: <199708291612.MAA29214@dcl.MIT.EDU> From: Mark Eichin Date: 29 Aug 1997 14:07:17 -0400 In-Reply-To: "Theodore Y. Ts'o"'s message of "Fri, 29 Aug 1997 12:12:43 -0400" Message-Id: Lines: 4 X-Mailer: Gnus v5.4.56/Emacs 19.34 Precedence: bulk Wasn't there a suggestion that a "quality of service" option be used to provide a way to tell the GSSAPI layer to do low-data-overhead encryption? I think it's on the list of things I've heard mentioned as "really should get written up some day"...   Received: from ietf.org by ietf.org id aa14306; 29 Aug 97 15:49 EDT Received: from poptart.svr.home.net by ietf.org id aa14254; 29 Aug 97 15:48 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.corp.home.net (Netscape Mail Server v2.02) with ESMTP id AAA14479; Fri, 29 Aug 1997 12:48:12 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id MAA21023; Fri, 29 Aug 1997 12:48:11 -0700 (PDT) Message-Id: <199708291948.MAA21023@lock.eos.home.net> X-Mailer: exmh version 1.6.7 5/3/96 To: Fred Baker cc: ietf@ietf.org Subject: Re: Revised nomcom selection algorithm In-reply-to: Your message of Fri, 29 Aug 1997 12:16:58 -0700. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 12:48:06 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. > At 10:11 AM -0700 8/29/97, Mike St. Johns wrote: > >I've been approached by a few of the statisticians in our ranks who have > >pointed out some possible biases in the mechanism for generating the next > >nom-com. > > Gee whiz; some of your predecessors (most of them, I think) wrote the names > on equal-sized bits of paper, put them in a hat, and got some > reputed-to-be-trustworthy soul to pull out the requisite number. We're > getting to the point that we need to go on the Lotto TV show, write the > names on golf balls, and have the world watch while a dozen or so randomly > bounce out of a juggling cage - to the sound of some guy in the audience > wondering aloud if all the balls were identical. Seems like we're putting > as much work into the selection procedure for the nomcom than the nomcom > will put into the selection of nominees :^) Hi Fred - I didn't really take it as an affront to my integrity, as opposed to my ability to do statistics! Based on the language in the current poised ID, I wanted to create an algorithm that was without bias and independently verifiable. The first go around had the property that for certain list lengths, it was heavily biased towards certain slots on the list. So the algorithm had to go. The statistician says: There's still a bias toward including sets of alphabetically consecutive people: for a pool of around 50, on average 0.9 members will be chosen because they came alphabetically next after someone who was previously chosen. However, any bias for or against specific individuals is down to the level of 0.005%. For a pool of around 100, cut the 0.9 in half and double the 0.005%. -------- Given that the length of the list is also a random number, I think we can live with the small (10e-4) bias. Unless there's a great outcry, this is the algorithm for this years go around. Mike   Received: from ietf.org by ietf.org id aa14378; 29 Aug 97 15:50 EDT Received: from mocha.Bunyip.Com by ietf.org id aa14336; 29 Aug 97 15:49 EDT Received: from expresso.bunyip.com (expresso.Bunyip.Com [192.197.208.2]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id PAA08266; Fri, 29 Aug 1997 15:48:40 -0400 (EDT) Message-Id: <199708291948.PAA08266@mocha.bunyip.com> Received: by expresso.bunyip.com (NX5.67c/NX3.0X) id AA06043; Fri, 29 Aug 97 15:46:21 -0400 Sender:ietf-request@ietf.org From: Peter Deutsch Date: Fri, 29 Aug 1997 15:46:20 -0400 In-Reply-To: Fred Baker's message as of Aug 29, 12:16 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Fred Baker , ietf@ietf.org Subject: Re: Revised nomcom selection algorithm Source-Info: From (or Sender) name not authenticated. [ Fred Baker wrote: ] . . . } I'll vouch for Mike's integrity here; I wouldn't have recommended him for } the job without being able to do so without a thought. There's no } ballot-box-fixing going on here. Can he, please, just get the right number } of names picked and get on with it? Just a thought - consider what happens if the level of hassle is such that not enough people want the grief and we end up with fewer candidates than positions. Wouldn't that be a hoot? When I saw the "patch" for the random generator function I was laughing out loud, thinking that only the IETF community could come up with such a complex and technical means of drawing names out of a hat. Now I see that it was to some degree in response to the lack of trust some people have with the integrity of the nomcom process and I'm disappointed. I believe we should have more gratitude and trust for the people who volunteer on our behalf. As a non-appointed member of the agnostic and atheistic community, I would willingly accept the papers and hat solution with a clergy/rabbi/imman/etc of the nomcom chair's choice if it meant that instead everyone would spend the same energy on solving the DNS crisis!! ;-) - peterd -- ------------------------------------------------------------------------------ Peter Deutsch, (514) 875-8611 (phone) Bunyip Information Systems Inc. (514) 875-8134 (fax) http://www.bunyip.com "...I'm not afraid of storms, for I'm learning how to sail my ship" (Louisa May Alcott, 1868) ------------------------------------------------------------------------------   Received: from cnri by ietf.org id aa15167; 29 Aug 97 16:28 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA18094; Fri, 29 Aug 1997 16:31:17 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id OAA10266 for cat-ietf-redist; Fri, 29 Aug 1997 14:13:02 -0400 (EDT) Date: Fri, 29 Aug 1997 14:12:50 -0400 Message-Id: <199708291812.OAA07798@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Mark Eichin Cc: "Theodore Y. Ts'o" , Joe Salowey , cat-ietf@mit.edu In-Reply-To: Mark Eichin's message of 29 Aug 1997 14:07:17 -0400, Subject: Re: telnet and GSSAPI Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Mark Eichin Date: 29 Aug 1997 14:07:17 -0400 Wasn't there a suggestion that a "quality of service" option be used to provide a way to tell the GSSAPI layer to do low-data-overhead encryption? I think it's on the list of things I've heard mentioned as "really should get written up some day"... I havne't heard that suggestion before, but it's certainly an interesting for someone to document and try implementing.... - Ted   Received: from cnri by ietf.org id aa15539; 29 Aug 97 16:41 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA18127; Fri, 29 Aug 1997 16:44:14 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id OAA11134 for cat-ietf-redist; Fri, 29 Aug 1997 14:20:52 -0400 (EDT) Message-Id: <199708291821.AA05865@sap-ag.de> From: Martin Rex Subject: Re: telnet and GSSAPI To: "Theodore Y. Ts'o" Date: Fri, 29 Aug 1997 20:20:31 +0200 (MESZ) Cc: cat-ietf@mit.edu In-Reply-To: <199708291612.MAA29214@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Aug 29, 97 12:12:43 pm Reply-To: Martin.Rex@sap-ag.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Theodore Y. Ts'o wrote: > > From: Joe Salowey > Date: Wed, 27 Aug 1997 13:52:55 -0700 > > I'm trying to find out if there is a spec or implementation of telnet > that uses kerberos via GSSAPI. I've heard rumors that one exists and > I've also heard that it's not possible. Any information would be > appreciated. > > There certainly isn't a public specification for how it would be done. > > Some folks at (I think) TIS were looking into doing a telnet > implementation that would use GSSAPI as part of the FORTEZZA project, > but I don't know if that ever got anywhere or not. > > The problem with using GSSAPI with the telnet protocol is that you > really somewhich can handle efficient encryption of a stream, and GSSAPI > is very block-oriented. You could call gss_wrap() for every character, > but there might be as much as a 32 byte (or even higher) overhead PER > CHARACTER. This is definitely something you wouldn't want to use over > a dialup connection! For dialup connections this is probably a significant impact, since there usually is some compression involved and the gssapi tokens will hardly be compressible. On the LAN, on the other hand, many of the datagrams are padded up to the minimum length (64 byte on the ethernet, isn't it), so that the worst case overhead on the LAN may only be around 50%. On the other hand ... if I remeber correctly, SPKM does support the use of "true digital signatures" for a MIC, so when using a 1024 RSA-Key, the MIC part in the wrap token alone will take 128 Bytes, I assume. :-( But in general there isn't a specific requirement in GSS-API that gss_wrap() has to add significant bloat to small data. A first-time random confounder, a simple (like a 12-byte HMAC) on all successor gss_wrap output tokens and a sliding window on the encrypted data (when using a block cipher) should be ok with the GSS-API spec, I assume. It should even be possible to add this as an extension of the existing Kerberos 5 Mechanism spec for a specific QOP-value that has to be used for gss_wrap() without even violating the GSS-API v2 spec or backwards compatibility. The (required) sequencing semantics on the context could probably be enforced with an HMAC that covers not only the current data, but also some of history of the data stream. ...but this is all just a wild guess of mine. -Martin   Received: from ietf.org by ietf.org id aa15962; 29 Aug 97 16:55 EDT Received: from pop.netgate.net by ietf.org id aa15835; 29 Aug 97 16:51 EDT Received: from slimnote (d101.netgate.net [205.214.160.139]) by pop.netgate.net (8.8.5/8.8.5) with SMTP id OAA02502 for ; Fri, 29 Aug 1997 14:54:04 -0700 (PDT) Message-Id: <3.0.3.32.19970829135010.0324bfc8@ng.netgate.net> X-Sender: dcrocker@ng.netgate.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 29 Aug 1997 13:50:10 -0700 To: IETF@ietf.org Sender:ietf-request@ietf.org From: Dave Crocker Subject: Re: Revised nomcom selection algorithm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. >everyone in the IETF. We tried using a local clergy person but people >still didn't believe that the fix wasn't in. I suppose we could use a The above is offerred as a blanket assessment, rather than as applying to a (tiny) minority. I believe that there is not, and never has been, any significant community mistrust of the selection process. As with each and every activity and action in our wonderfully open community, Somebody Somewhere Says Something Bad. This does not mean that we need to pay attention to those inadequately still and inadequately small voices. Given the real and difficult problems associated with doing nomcom well, it is very unfortunate that this aspect of it has diverted so much energy. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org, http://www.imc.org Member, interim Policy Oversight Committee http://www.gtld-mou.org   Received: from cnri by ietf.org id aa16604; 29 Aug 97 17:23 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA18288; Fri, 29 Aug 1997 17:26:57 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id PAA19219 for cat-ietf-redist; Fri, 29 Aug 1997 15:41:12 -0400 (EDT) Date: Fri, 29 Aug 1997 15:40:55 -0400 Message-Id: <199708291940.PAA11545@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Martin.Rex@sap-ag.de Cc: cat-ietf@mit.edu In-Reply-To: Martin Rex's message of Fri, 29 Aug 1997 20:20:31 +0200 (MESZ), <199708291821.AA05865@sap-ag.de> Subject: Re: telnet and GSSAPI Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Precedence: bulk From: Martin Rex Date: Fri, 29 Aug 1997 20:20:31 +0200 (MESZ) But in general there isn't a specific requirement in GSS-API that gss_wrap() has to add significant bloat to small data. It's not required in the GSS-API spec, but it's a common implementation strategy to put the mechanism OID at the beginning of every gss_wrap() token. In fact, there was even those who wanted to have that be enforced, which would guarantee that the overhead would always be there, but fortunately we didn't decide to go that route. - Ted   Received: from ietf.org by ietf.org id aa17139; 29 Aug 97 17:38 EDT Received: from gungnir.fnal.gov by ietf.org id aa17086; 29 Aug 97 17:37 EDT Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA12583; Fri, 29 Aug 1997 16:36:50 -0500 Message-Id: <199708292136.QAA12583@gungnir.fnal.gov> To: IETF@ietf.org Sender:ietf-request@ietf.org From: Matt Crawford Subject: Re: Revised nomcom selection algorithm In-reply-to: Your message of Fri, 29 Aug 1997 13:50:10 PDT. <3.0.3.32.19970829135010.0324bfc8@ng.netgate.net> Date: Fri, 29 Aug 1997 16:36:50 -0500 X-Orig-Sender: crawdad@gungnir.fnal.gov Source-Info: From (or Sender) name not authenticated. For whatever reason, the poisson-nomcom draft calls for the nomcom to be selected "using a method that can be independently verified to be unbiased and fair." It's too bad that the poisson wg stopped short of providing the method. (It's not hard.) The previous Nomcom operational document moved, I believe, from draft to RFC sometime during the operation of last year's Nomcom, so I don't think anyone can fault Mike for operating according to the current draft. (Gee, I hope it isn't in conflict with the RFC anywhere!) Hence Mike is taking all this pain, rather than passing the hat. He's bearing up well under it, and there's no added inconvenience to the Nomcom volunteers, so let's take any remaining comments to poisson. Matt Crawford   Received: from ietf.org by ietf.org id aa20229; 29 Aug 97 19:15 EDT Received: from poptart.svr.home.net by ietf.org id aa20166; 29 Aug 97 19:13 EDT Received: from lock.eos.home.net ([24.0.16.84]) by poptart.corp.home.net (Netscape Mail Server v2.02) with ESMTP id AAA7452; Fri, 29 Aug 1997 16:13:37 -0700 Received: from lock.eos.home.net (localhost [127.0.0.1]) by lock.eos.home.net (8.8.5/8.7.3) with ESMTP id QAA22125; Fri, 29 Aug 1997 16:13:36 -0700 (PDT) Message-Id: <199708292313.QAA22125@lock.eos.home.net> X-Mailer: exmh version 1.6.7 5/3/96 To: ietf@ietf.org cc: scoya@CNRI.Reston.VA.US Subject: IETF Nomcom - Volunteer List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Aug 1997 16:13:31 -0700 Sender:ietf-request@ietf.org From: "Mike St. Johns" Source-Info: From (or Sender) name not authenticated. As of 1600 PDT 29 August I had received volunteer messages from the following people (57). If you are not listed and believe you should be, please contact me by next Friday (5 August) with some evidence that you had emailed me ahead of the deadline. I want to thank all of you who have volunteered. Stay tuned for the selection lottery on the 20th of September. Mike [Steve, please reflect to the IETF-Announce list and you can start your eligibilty confirmation process - thanks] Alex Conta Avri Doria Bernard Aboba Bill Manning Bill Sommerfeld Bob Fink Borje Ohlman Bruce Greenblatt Charlie Kaufman Chris Newman Dave Crocker David M. Meyer Deirdre Kostick Derya Cansever Donald E. Eastlake 3rd Dorn Hetzel E. Paul Love Einar Stefferud Eric W Gray Evi Nemeth Glen Zorn John Boudreaux John Tavs Keith McCloghrie Lixia Zhang Manu Kaycee Marshall Rose Matt Holdrege Michael Mealling Miriam Kadansky Neal McBurnett Ned Freed Olafur Gudmundsson Ole J. Jacobsen Paul Ferguson Paul Hoffman Paul Mockapetris Perry E. Metzger Pete Resnick Philip J. Nesser II Randall Gellens Rik Drummond Scott Huddle Sig Handelman" Stephen Kent Steve Hanna Steve Hole Ted Wolf Jr Theodore Y. Ts'o Tony Genovese Tony Li Uri Blumenthal Vab Goel Vito P. Jokubaitis William Allen Simpson William B. Norton   Received: from cnri by ietf.org id aa20267; 29 Aug 97 19:17 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA18699; Fri, 29 Aug 1997 19:21:04 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id RAA03021 for cat-ietf-redist; Fri, 29 Aug 1997 17:59:18 -0400 (EDT) To: "Theodore Y. Ts'o" Cc: Martin.Rex@sap-ag.de, cat-ietf@mit.edu Subject: Re: telnet and GSSAPI References: <199708291940.PAA11545@dcl.MIT.EDU> From: Marc Horowitz Date: 29 Aug 1997 17:59:16 -0400 In-Reply-To: "Theodore Y. Ts'o"'s message of Fri, 29 Aug 1997 15:40:55 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.3/Emacs 19.34 Precedence: bulk "Theodore Y. Ts'o" writes: >> But in general there isn't a specific requirement in GSS-API that >> gss_wrap() has to add significant bloat to small data. >> >> It's not required in the GSS-API spec, but it's a common implementation >> strategy to put the mechanism OID at the beginning of every gss_wrap() >> token. In fact, there was even those who wanted to have that be >> enforced, which would guarantee that the overhead would always be there, >> but fortunately we didn't decide to go that route. Robustness vs efficiency is a standard engineering tradeoff. I think it would be fine to have a QOP which dropped the initial OID in favor of low overhead. Marc   Received: from ietf.org by ietf.org id aa07288; 30 Aug 97 11:59 EDT Received: from [198.200.139.16] by ietf.org id aa07079; 30 Aug 97 11:48 EDT Received: from wwt.com by wwt.com (SMI-8.6/SMI-SVR4) id KAA25528; Sat, 30 Aug 1997 10:41:54 -0500 Received: from HeadQuarters-Message_Server by wwt.com with Novell_GroupWise; Sat, 30 Aug 1997 10:50:04 -0500 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sat, 30 Aug 1997 09:04:39 -0500 Sender:ietf-request@ietf.org From: Bob Olwig To: ietf@ietf.org Subject: Remove Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Source-Info: From (or Sender) name not authenticated. Please remove my address from your distribution list. Thank you.   Received: from ietf.org by ietf.org id aa09886; 30 Aug 97 15:30 EDT Received: from jekyll.piermont.com by ietf.org id aa09809; 30 Aug 97 15:27 EDT Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.8.6/8.6.12) with SMTP id PAA12537; Sat, 30 Aug 1997 15:27:11 -0400 (EDT) Message-Id: <199708301927.PAA12537@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: [[UNIX: localhost]] didn't use HELO protocol To: Peter Deutsch cc: Fred Baker , ietf@ietf.org Subject: Re: Revised nomcom selection algorithm In-reply-to: Your message of "Fri, 29 Aug 1997 15:46:20 EDT." <199708291948.PAA08266@mocha.bunyip.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 30 Aug 1997 15:27:10 -0400 Sender:ietf-request@ietf.org From: "Perry E. Metzger" Source-Info: From (or Sender) name not authenticated. Peter Deutsch writes: > When I saw the "patch" for the random generator function I > was laughing out loud, thinking that only the IETF > community could come up with such a complex and technical > means of drawing names out of a hat. Actually, the mechanism is very reminiscent of the way that illegal "numbers games" are run in many places, although typically they use "random numbers" taken from horseracing results and not the stock market. The mechanisms are of just about of equal complexity, and are designed for the same purpose -- to assure that a "widely witnessed event" that no individual has control over is the selection mechanism. I rather like it, frankly! Its not too difficult, either, IMHO. Perry   Received: from cnri by ietf.org id aa11221; 30 Aug 97 17:22 EDT Received: from pad-thai.cam.ov.com (pad-thai.cam.ov.com [192.231.148.11]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA19995; Sat, 30 Aug 1997 17:25:52 -0400 (EDT) Received: (from daemon@localhost) by pad-thai.cam.ov.com (8.8.6/8.8.6) id PAA28470 for cat-ietf-redist; Sat, 30 Aug 1997 15:24:54 -0400 (EDT) Date: Sat, 30 Aug 1997 15:24:53 -0400 (EDT) From: Rich Salz Message-Id: <199708301924.PAA18251@sulphur.osf.org> To: eichin@cygnus.com, tytso@mit.edu Subject: Re: telnet and GSSAPI Cc: cat-ietf@mit.edu, joes@wrq.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk FWIW, in a GSSAPI+DCEized rlogin/rsh someone here did for a client, we did asymmetric sign/seal. I think it was 8bytes from client, and 64 or 128 from server. Assuming client is user who types little compared to system output. Seems to work well in production use. User(client) had new tilde-sequences to control the packet sizes.   Received: from ietf.org by ietf.org id aa05773; 31 Aug 97 10:30 EDT Received: from cs.columbia.edu by ietf.org id aa05599; 31 Aug 97 10:13 EDT Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.19.141]) by cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA14738; Sun, 31 Aug 1997 10:13:43 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.5/8.6.6) with ESMTP id KAA13678; Sun, 31 Aug 1997 10:13:43 -0400 (EDT) X-Orig-Sender: hgs@cs.columbia.edu Message-ID: <34097C17.8E564B35@cs.columbia.edu> Date: Sun, 31 Aug 1997 10:13:43 -0400 Sender:ietf-request@ietf.org From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.02 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Mark Lottor CC: ietf@ietf.org Subject: Re: Internet Domain Survey results, July 1997 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Two small observations: - The ratio of hosts to domains has declined steadily, from 73.9 to 14.9. This would seem to be the result of virtual hosting and arrangements of a small number of external (WWW, email) servers/company. - The ratio of ping'able hosts to hosts in the DNS has held remarkably steady at around 17 to 22%, with a low in 1995 and a slow climb since then. Henning (see http://www.cs.columbia.edu/~hgs/internet/growth.html for the numbers.) Mark Lottor wrote: > > > Internet Domain Survey Network Wizards July 1997 > > The Domain Survey attempts to discover every host on the Internet by doing > a complete search of the Domain Name System. The latest results gathered > during late July 1997 are listed. For more information see RFC 1296; > for more data see the zone directory on ftp.nw.com, or http://nw.com > -- Mark Lottor > > > Number of Hosts and Domains advertised in the Domain Name System > > Replied > Date | Hosts Domains To Ping* > ------+---------------------------------- > Jul 97| 19,540,000 1,301,000 4,314,410 > Jan 97| 16,146,000 828,000 3,392,000 > > Jul 96| 12,881,000 488,000 2,569,000 > Jan 96| 9,472,000 240,000 1,682,000 > > Jul 95| 6,642,000 120,000 1,149,000 > Jan 95| 4,852,000 71,000 970,000 > > Jul 94| 3,212,000 46,000 707,000 > Jan 94| 2,217,000 30,000 576,000 > > [* estimated by pinging 1% of all hosts] > -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 (@Bell Labs: 908 949 8344) Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs   Received: from ietf.org by ietf.org id aa11666; 31 Aug 97 19:03 EDT Received: from hitiij.hitachi.co.jp by ietf.org id aa11565; 31 Aug 97 18:57 EDT Received: from missun1.musashi.hitachi.co.jp by hitiij.hitachi.co.jp (8.8.5+2.7Wbeta5/3.5W-hitiij) id HAA01157; Mon, 1 Sep 1997 07:52:42 +0900 (JST) Sender:ietf-request@ietf.org From: ujinoy@cm.musashi.hitachi.co.jp Received: from cm.musashi.hitachi.co.jp ([158.212.213.206]) by missun1.musashi.hitachi.co.jp (8.7.4+2.6Wbeta6+NAGATA1.24/SICD-MAILGW2.5) with SMTP id HAA00478 for ; Mon, 1 Sep 1997 07:57:25 +0900 (JST) Received: from ccMail by cm.musashi.hitachi.co.jp (ccMail Link to SMTP R6.00.02) id AA873068278; Mon, 01 Sep 97 07:58:02 +0900 Message-Id: <9709018730.AA873068278@cm.musashi.hitachi.co.jp> X-Mailer: ccMail Link to SMTP R6.00.02 Date: Mon, 01 Sep 97 07:56:40 +0900 To: ietf@ietf.org MMDF-Warning: Parse error in original version of preceding line at ietf.org Subject: remove MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Please remove my address from your distribution list. Thank you. Yoshiaki Ujino