[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
We are seeking about 50 geographically distributed volunteers to install the
Network Probe Daemon (NPD) on their Unix machine. NPD is a unix daemon that
issues traceroute commands to other NPD hosts sites. The end result is a
matrix of network paths. The matrix is processed in various ways,
specifically noting routing anomalies and otherwise unexpected results. The
load on the machine is minimal and security is accomplished using an
authentication key. This is a continuation of the work done by Vern Paxson
(LBL).
If you would like to volunteer, please download the software at:
ftp://nic.merit.edu/routing.arbiter/tools/npd-1.0.tar.Z
and send e-mail to dunl at merit.edu. The INSTALL file has all the information
needed to install the NPD software.
When you contact Dun, he will then verify that the software was installed
correctly. We expect to start the routing stability measures during the
next few weeks in August, so please don't delay.
Thanks!
Bill Norton & Dun Liu
----------------------------------------------------------------------
William B. Norton<wbn at merit.edu>(313) 936-2656
Received: from ietf.org by ietf.org id aa15402; 15 Aug 96 15:29 EDT
Received: from cnri by ietf.org id aa15261; 15 Aug 96 15:23 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa12270;
15 Aug 96 15:23 EDT
Received: from rags.rutgers.edu by venera.isi.edu (5.65c/5.61+local-25)
id <AA26776>; Thu, 15 Aug 1996 12:22:57 -0700
Received: (from badri at localhost) by rags.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) id PAA25905; Thu, 15 Aug 1996 15:22:30 -0400
Date: Thu, 15 Aug 1996 15:22:30 -0400
Sender:ietf-request at ietf.org
From: Br Badrinath <badri at cs.rutgers.edu>
Message-Id: <199608151922.PAA25905 at rags.rutgers.edu>
To: ieeetcpc at ccvm.sunysb.edu, orcs-l%osuvm1.BITNET at searn.sunet.se,
glynn at leland.stanford.edu, ietf-announce at CNRI.Reston.VA.US,
mobile-ip <mobile-ip%tadpole.com.end2end-interest at isi.edu>,
f-troup at aurora.cis.upenn.edu, rem-conf-request at es.net,
cost237-transport at comp.lancs.ac.uk, reres at laas.fr,
hipparch at sophia.inria.fr, xtp-relay at cs.concordia.ca, rem-conf at es.net,
sigmedia at bellcore.com, arpanet-bboard at mc.lcs.mit.edu,
cnom at meatro.bellcore.com, globecom at signet.com.sig, ietf at isi.edu,
tccc at cs.umass.edu
Subject: Advanced Program, Mobicom96
Source-Info: From (or Sender) name not authenticated.
ACM/IEEE Present
MOBICOM'96
Advance Program
The Second Annual International Conference on
Mobile Computing and Networking
November 10-12, 1996
Rye Hilton
Rye, New York, USA
=================================================================
| Sponsored by: |
| |
| ACM CESDIS NASA IEEE |
| Sigmobile, Sigcomm, Sigmetrics, ComSoc |
| Sigops, Sigact |
==================================================================
TUTORIAL PROGRAM
Sunday, November 10 8:30 A.M. to 5:00 P.M.
All tutorials will be half-day tutorials (4 hours each).
Tutorials I and II will be in the morning (8:30 am-- 12:30pm)
T1 Disconnected Browsing : WWW & Mobile Computing
Anupam Joshi, Purdue University
T2 Air Interface Standards
Li Fung Chang, Bellcore
Tutorials III and IV will be in the afternoon (1:30 -5:30 pm)
T3 Secure Mobile Communications
Yacov Yacobi, Bellcore
T4 Mobile Networking within the IETF
Charlie Perkins, IBM
Welcome Reception 7:00 P.M. to 9:00 P.M.
Hosted by IBM
-------------------------
MONDAY, NOVEMBER 11
8:45 A.M.
Opening Remarks
Keynote Address:
DR. VICTOR B. LAWRENCE,
DIRECTOR OF ADVANCED COMMUNICATIONS TECHNOLOGY,
Bell Laboratories of Lucent Technologies (formerly AT&T
Bell Laboratories)
10:00 A.M. Break
10:30 A.M.
Technical Sessions
------------------------------------------------------------------
Session No. 1: Mobile and Wireless TCP/IP
Chair: Jim Freebersyser, ARO
* Low-loss TCP/IP Header Compression for Wireless Networks,
M. Degermark, M. Engan, B. Nordgren, and S. Pink,
Lulea University and the
Swedish Institute of Computer Science, Sweden
(Student Paper Award)
* TCP Extensions for Space Communications,
R.C. Durst, G.J. Miller, The MITRE Corporation,
and E.J. Travis, Gemini Industries
* Mobility Support in IPv6,
C.E Perkins, IBM T.J. Watson Research Center,
and D.B. Johnson, Carnegie Mellon University
------------------------------------------------------------------
12:00 Noon
Conference Lunch
Luncheon Talk: Mobile Computing: Where's the Tofu?
M. Satyanarayanan, CMU
1:45 P.M.
Session No. 2: Mobility Management
Chair: Ray Pickholz, GWU
* Efficient and Flexible Location Management
Techniques for Wireless Communication Systems,
J. Jannink, D. Lam, N. Shivakumar, J. Widom, D.C. Cox,
Stanford University
* On Resource Discovery in Distributed Systems with Mobile
Hosts,
D. Awduche, A. Gaylord, and A. Ganz,
University of Massachusetts, Amherst
* Fast and Scalable Handoffs for Wireless Internetworks,
R. Caceres, Bell Labs, Lucent Technologies
and V.N. Padmanabhan, UC Berkeley
------------------------------------------------------------------
3:15 P.M.
Session No. 3: PANEL 1
"Software Architectures for Mobile Networks,"
Session Chair: Aurel Lazar, Columbia Univ.
Participants:
D. Raychaudhuri, NEC C&C Labs
Andrew T. Campbell, Columbia University,
Krishan Sabnani, Bell Labs,
Arvind Krishna, IBM T.J. Watson Research Center,
Louis-Francois Pau, Ericsson,
Glenford Mapp, Olivetti.
4:30 P.M. BREAK
5:00 P.M.
Session No. 4: Resource Allocation and Sharing
Chair: Siamak S. Tabrizi, Rome Laboratory
* Spectrum Sharing Under The Asynchronous UPCS Etiquette:
The Performance Of Collocated Systems Under Heavy Load,
I. Vukovic and J. McKown, Motorola Wireless Data Group
* Dynamic Loadbalancing Strategies for Channel Assignment
Using Selective Borrowing in Cellular Mobile Environments
S.K. Das, S.K. Sen, and R. Jayaram, University of North Texas
* Lossless Handover for Wireless ATM
H. Mitts, H. Hansen, and J. Immonen,
VTT Information Technology, Finland
7:00 - 9:00 Conference Dinner Banquet
TUESDAY, NOVEMBER 12
=============================================================================
8:30 A. M.
Session No. 5: Mobile Applications
Chair: Mahmoud Naghshineh, IBM
* Rapid Prototyping of Mobile Context-Aware Applications:
The Cyberguide Case Study
S. Long, R. Kooper, G. Abowd and C. Atkeson,
Georgia Institute of Technology
* WebExpress: A System for Optimizing Web Browsing in a
Wireless Environment
B.C. Housel and D.B. Lindquist, IBM Corporation
* Building Fault-Tolerant Mobile-Aware Applications using
the Rover Toolkit,
A.D. Joseph and M.F. Kaashoek, MIT
------------------------------------------------------------------
10:00 A.M. Break
10:30 A.M.
Session No. 6: Issues in Mobile Computing
Chair: Rabinder Madan, ONR
* A Dynamic Disk Spin-down Technique for Mobile Computing,
D. Helmbold, D. Long, and B. Sherrod, UC Santa Cruz
* Reducing Processor Power Consumption by Improving Processor
Time Management in a Single-User Operating System
J.R. Lorch and A.J. Smith, UC Berkeley
* Security on the Move: Indirect Authentication
using Kerberos
A. Fox and S. Gribble, UC Berkeley
------------------------------------------------------------------
12:00 P.M. Conference Lunch
1:45 P.M.
Session No. 7: LAN, MAC, and ATM
Chair: Kevin Mills, DARPA
* Wireless ATM MAC Performance Evaluation: HIPERLAN Type 1
Versus Modified MDR,
L. Nenonen, Nokia Research Center /
Nokia Telecommunications, Finland, and
J. Mikkonen, Nokia Mobile Phones, Finland
* A Scalable Wireless Virtual LAN,
Z. Liu, M. Veeraraghavan, and K.Y. Eng,
Bell Labs, Lucent Technologies
* Floor Acquisition Multiple Access with Collision Resolution,
R. Garces and J.J. Garcia-Luna-Aceves, UC Santa Cruz
3:15 Break
3:45
Session No. 8: PANEL 2
"Multimedia Mobile Wireless Networks - is Anytime, Anywhere, Anything a Dream
or a Reality," organized by Jacob Sharony, Hazeltine.
Participants:
Jim Freebersyser - ARO
Kevin Mills - DARPA
Ambatipudi Sastry - SRI
Martha Steenstrup - BBN
Bezalel Gavish - Vanderbilt University
5:15 PM Conference Adjourns
===============================================================================
Mobicom'96 Tutorials November 10th
All tutorials will be half-day tutorials (4 hours each).
Tutorials I and II will be in the morning from 8:30 am -- 12:30pm
Tutorials III and IV will be in the afternoon 1:30 pm -- 5:30 pm
Tutorial I
----------------
Disconnected Browsing : WWW & Mobile Computing
---------------------------------------------------
The objective of this tutorial will be to familiarize the audience
with the basics as well as the state of the art in disconnected
browsing. We use this term to describe both the general
aspects of accessing distributed multimedia data from limited
capability and bandwidth platforms, as well as the specifics of
browsing the Web from mobile (wirelessly networked) computers. The
issues involved here lead to challenging problems in research that
need to be addressed by the community, as well as interesting
practical systems that will be useful in everything from battlefield
management, tele-medicine, and education, inter alia.
We will begin the tutorial from a general overview of the challenges
posed by mobile systems to a wide variety of computer science
disciplines, such as networking, data management, user interfaces etc.
We will describe how the problems in these areas affect disconnected
information browsing. We will also provide a short overview of the Web -- http,
html and Java. Using the web as an example, we will describe and
analyze the issues involved in creating systems for disconnected
browsing. These involve mobile client server and proxy-scion
architectures, disconnection management, information fusion,
cooperative information gathering and multimedia transformation. We
will describe application scenario, and conclude with a critical
review of systems, including those
worked on by the instructor, such as InfoPad, SciencePad, Odyssey,
and Milktruck.
Instructor:
Anupam Joshi is a (Visiting) Assistant Professor of Computer
Sciences at Purdue University, from where he received a Ph.D. degree
in Computer Science in 1993. His research interests span the broad
areas of computational intelligence, distributed AI and
Networked/Mobile computing. He works on using AI/CI techniques to help
in the creation of Intelligent, Ubiquitous Problem Solving
Environments. Allowing such systems to be accessible from mobile
platforms is an important aspect of this work, and is supported by an
NSF award to Profs. Houstis and Joshi. He is also the PI of a grant
from Intel which seeks to address related problems in disconnected
browsing - mobile access to distributed data such as that on the
Web. This effort collaborates with the work being done by
Profs. Elmagarmid and Helal in multidatabases and mobile systems. His
other interests include computational vision and computer mediated
(distance) learning. For the last 2 semesters, he has taught a seminar
course in mobile computing at Purdue, and received 5.0/5.0 on student
evaluations. He is a member of IEEE, IEEE-CS, ACM and UPE.
Tutorial II
---------------
Air Interface Standards: An Overview
--------------------------------------
In this tutorial, we will first give a brief descriptions of
impairments of wireless link, possible mitigations schemes and their
impact on wireless data communications. We will then discuss
difference and features of the "high tier" system vs. the "low tier"
system. High tier systems are designed for high mobility vehicular
services. Typical characteristics of a high tier system are large
base station antenna heights, high transmission power, large coverage
area, etc. Low tier systems are targeted for low speed pedestrian and
indoor usage. A low tier system uses small inexpensive base stations
for pole or wall mounting with low transmit power. Wireless
technologies designed to operate in these systems will be quite
different. We will give an overview of several air interface
standards (both U.S. and worldwide) designed for the emerging Personal
Communications Services (PCS). Some are designed for high-tier (e.g.
GSM/DCS1900, IS-95 CDMA, etc.) and some are for low-tier (e.g.
PACS-Personal Access Communication System, PHS-Personal Handyphone
System, DECT-Digital European Cordless Telephone) systems. In
particular, we will focus on the data communication capabilities of
the air interface standards.
Instructor:
Li Fung Chang received the B.S. degree from the National Taiwan Normal
University in 1978 and the M.S., Ph.D. degrees from the University of
Illinois in 1983 and 1985, respectively. She joined Bell
Communications Research in August 1985 as a member of technical staff
in Radio Research Division. She is now a director and project manager
of broadband wireless program. Her research efforts and interests are
mainly in the area of wireless communications. Her early research
works involved in the application of channel coding for wireless
digital radio communications system. She has worked on the ARQ
protocols, architecture for wireless data communications; link level
performance evaluations of TDMA (Time-Division Multiple Access), CDMA
(Code-Division Multiple Access), FHMA (Frequency-Hopping Multiple
Access) wireless communication systems; privacy/authentication for
wireless digital radio communications system; and protocol designs and
system performance evaluations of the PACS for TDD operations for
in-building application. She is also involved in design and network
architecture for the interoperability of the high mobility cellular
system and low mobility PCS system. Currently, she manages a research
group working on protocol design and network performance evaluation of
PCS mobility management on ATM transport and mobile IP over ATM. Dr.
Chang holds three US patents in the aforementioned areas, five pending
patents and has numerous publications. She has given short courses in
PCS at National Chiao-Tung Univ. Taiwan, 1992, and 1995, respectively.
She is a senior member of IEEE, Phi Kappa Phi and Phi Tau Phi Chinese
honor society. Currently, she is chair of the communication chapter,
IEEE NJ Coast Section.
Tutorial III
--------------
Secure mobile communications
----------------------------------
This 3 hours tutorial is intended for general MS/EE engineers
and does not assume prior knowledge of cryptography or system security.
It will cover:
1. Basic cryptography: The Shannon Model; and modern (complexity
based, public key) cryptography.
2. Requirements for mobile security.
3. Special techniques for low-cost terminals.
4. Digital payment mechanisms.
5. Standards.
Instructor:
Dr. Yacov Yacobi has a Ph.D. in EE from Technion, IIT. He was a
Senior Scientist at the Mathematics and Cryptography Group at Bellcore
until recently, and is now with Microsoft Corp. He is the author of
over 30 published papers, and over 10 patents in Cryptography, and a
member of the Editorial Boards of IEEE Personal Communication
Magazine, and The Journal of Computer Security.
TUTORIAL IV
------------------
Mobile Networking within the IETF
------------------------------------
Within the Internet Engineering Task Force (IETF) there are
a number of development activities for protocols which are relevant
to mobile networking. Included among them are mobile-IP, DHCP,
PPP, mobile-IPv6, and the Service Location Protocol. A description of
these efforts will be given, including protocol details, current
status information, and clarifying their relationships.
The tutorial will explain the details of the mobile-IP model, as
well as the registration protocols and tunneling mechanisms. When
mobile computers attach themselves to new networks within the
Internet, they can use mobile-IP as a means to achieve seamless
roaming -- transparently to application software. Using mobile-IP, a
mobile client supplies information to a router, called its home agent,
about its current whereabouts using a simple registration protocol.
Once the basic operation has been shown, additional mechanisms will be
described to avoid the need for routing packets through the (possibly
distant) home agent, providing a faster route between mobile clients
and their correspondents.
The Dynamic Host Configuration Protocol (DHCP) will then be
introduced and its usefulness for mobile users explained. After
describing the basic DHCP client/server model, I'll apply it
in some likely scenarios for mobile computing, and show the
advantages and the disadvantages of using DHCP. Perhaps even
more than static computers, mobile computers will be used by
people uninterested in performing administrative duties, and
I will describe the use of a new option for DHCP which allows
the acquisition of IP addresses appropriately configured for use
with the mobile-IP protocols.
Having covered the basics of mobility for IP version 4,
I will describe IP version 6 and its provisions for mobile computing.
I'll give enough details about IPv6 to make the discussion self
contained, and then describe in detail the mobility messages.
Architectural differences between IPv4 and IPv6 mobility will be
presented, and the requirements for IPv6 hosts, routers, and
mobile nodes will be enumerated. Interactions between mobility
for IPv6 and other parts of the IPv6 protocol suite (such as
Neighbor Discovery) will also be described.
A final description will be of the Service Location Protocol (SLP),
designed to eliminate additional configuration requirements that
otherwise might require manual configuration by the users. For
instance, a user would often need to find out which local printers
can handle Postscript output, and where local mount points can be
found for local libraries and other support data.
Instructor
---------------------
Charles Perkins (perk at watson.ibm.com)
is a research staff member at IBM T.J. Watson Research,
investigating mobile and ad-hoc networking, resource discovery,
and automatic configuration for mobile computers.
He is serving as the document editor for the mobile-IP
working group of the Internet Engineering
Task Force (IETF), and serves on the editorial boards
for ACM/IEEE Transactions on Networking,
ACM Wireless Networks, and IEEE Personal Communications.
Charles holds a B.A. in mathematics and a M.E.E. degree from Rice
University, and a M.A. in mathematics from Columbia University.
Mobicom96 Local Information
Hotel/Accommodations
The Rye Town HILTON Phone:+1 800 445 8667
699, Westchester Avenue or +1 914 939 6300
Rye Brook, NY 10573 Fax: +1 914 939 5328
The
hotel offers a wide variety of complimentary amenities and services available
for your use:
-Resort complex set on 45 acres of beautifully landscaped countryside.
-Indoor pool
-Full Service Fitness Center
-Year round tennis
-Jacuzzis, spas, and saunas
-Hair salon and barber shop on property
-Two award winning restaurants
-The Den Lounge - open daily w/nightly entertainment.
-Convention Services department to assist in any special needs that may
arise.
To make reservations at the hotel, contact reservations
by October 20, 1996.
As an attendee to the MOBICOM Conference, your guest room rate is $110.00 per
night, based on single or double occupancy. To make reservations, please
call 1-800-HILTONS. Please be sure to identify yourself as being with the
ACM MobiCom Conference in order to receive the special room rate.
Transportation
For those needing transportation via any of the major airports (JFK,
LaGuardia, or Newark), MARK 1 Limousine Company provides the most affordable
option. Reservations for this service should be made in advance by calling
1-800-309-7070.
FROM LAGUARDIA AIRPORT - Grand Central Parkway to Route 678 over Whitestone
Bridge. Follow to Hutchinson River Parkway North to Exit 26 East
(Westchester Avenue, Rye). Continue on Westchester Avenue counting 6 lights.
Turn left at 6th light into hotel driveway.
FROM KENNEDY AIRPORT - Van Wyck Expressway North to Whitestone Expressway
over Whitestone Bridge. Follow same directions from LaGuardia Airport.
FROM ROUTE 95, HEADING NORTH - Route 95 north to Exit 21. Rollow Route 287
West to Exit 10 (Webb Avenue, Bowman Avenue). Straight off the exit ramp to
your second traffic light. Bear right onto Westchester Avenue. Proceed to
your third traffic light and turn left at hotel entrance.
FROM ROUTE 95, HEADING SOUTH - Route 95 south to Exit 21 (in New York).
Follow Route 287 West to exit 10 (Webb Avenue, Bowman Avenue). Follow above
directions.
FROM NEW YORK CITY - West Side Highway to Henry Hudson Parkway to Saw Mill
River Parkway. Follow to Cross County Parkway East. Proceed to Hutchinson
River Parkway North and continue to Exit 26 East (Westchester Avenue, Rye).
Follow above directions.
FROM TAPPAN ZEE BRIDGE - Route 287 East to Exit 10. Go straight off exit
ramp through 4 lights. At the 4th light, make a left into hotel entrance.
BY TRAIN - Transportation is available on the Metro-North Railroad line from
New York City and Connecticut to the Rye Station.
On-site registration
On-site Registration will be available on Sunday, November 10th
between 8:00 A. M. And 5:00 P.M. and 7:00 P.M. On Monday,
November 11th it will be held between 8:00 A.M - 5:00 P. M. and on
Tuesday, November 12th between 8:00 A. M. -- 12:00 Noon.
================================================================
Exhibits
========
We will be hosting a small number of novel hardware and software exhibits
relevant to mobile computing. The exhibits may be research prototypes or
commercial products.
Interested parties should contact Peter Honeyman (honey at citi.umich.edu) to
reserve space.
For more Information
Web Page:http://www.acm.org/sigmobile/conf/mobicom96/
E-mail: Badri at cs.rutgers.edu
Publicity chair:
Badrinath, B. R., Rutgers University
Phone: 908-445-2082
Mobicom96 Registration Form
Tutorials (Check each tutorial attending)
[] T1 Disconnected Browsing : WWW & Mobile Computing
[] T2 Air Interface Standards
[] T3 Secure Mobile Communications
[] T4 Mobile Networking within the IETF
Early Late
Registration Registration
Before After
10/18/96 10/18/96
Fee for each Tutorial
ACM Members: $180____ $225____
Non-members: $220____ $265____
Full-time students: $100____ $125____
Total fee for Tutorials _____ _______
Conference Registration*
ACM Members: $320____ $370____
Non-members: $400____ $450____
Full-time students#: $125____ $155____
Extra Dinner Banquet: $55_____ $55_____
Extra Proceedings: $45_____ $45_____
*includes proceedings, sessions, reception, lunches and banquet
#includes proceedings, sessions, reception and lunches
Total Fees $________ $_________
Vegetarian Meals: Yes _____ No _______
___________________________________________________________
Special needs: (Please describe)
Please type or print clearly
_____________________________________________________________
Last name
____________________________________________________________
First Name
_____________________________________________________________
Company/Organization
_____________________________________________________________
Address
_____________________________________________________________
_____________________________________________________________
______________________________________________________________
Country
______________________________________________________________
Telephone Number
______________________________________________________________
Fax number
______________________________________________________________
e-mail address
______________________________________________________________
Name desired for your name tag
ACM Member No. _____________________________
Payment Information
[] Check or money order payable to MobiCom'96
[] VISA [] MasterCard
Card Number _______________________________________
Expiration Date ___________________________________
___________________________________________________
Print name above as it appears on card
Please complete and send form and a check, credit card info or money orders
(no purchase orders) to the registration chair. Registration accepted via
postal mail, fax, or e-mail only. Fax and Email registration require credit
card info. The registration fees must be paid in U.S. dollars.
Send Payment To: MobiCom'96
Attn: Pravin Bhagwat
IBM, TJ Watson Research Center
US Mail PO Box 704
Yorktown Heights, NY 10598
Street Address 30 Saw Mill River Road
for express Mail Hawthorne, N.Y. 10532
E-mail pravin at watson.ibm.com
Fax 914-784-6205
Note: Written requests for refunds must be postmarked no later than November 1, 1996.
Refunds are subject to a US$50 service charge. Participants with confirmed
registration who fail to attend or notify MobiCom registration of cancelation
before the refund date are subject to the full fee. Substitutions are allowed
at any time. Registrations received after November 1, 1996 will be processed
on-site.
Mobicom'96 Executive committee
GENERAL CO-CHAIRS:
HAMID AHMADI RANDY KATZ
IBM T. J. Watson Research Center,NY UC Berkeley, CA
PROGRAM CO-CHAIRS
IAN F. AKYILDIZ ZYGMUNT J. HAAS
Georgia Tech, GA Cornell University
TUTORIAL CHAIR LOCAL CHAIR
ARVIND KRISHNA BOB FLYNN, Polytechnic University
IBM T.J. Watson Research Center
VICE CHAIR
TOM LaPORTA, Bell Labs. (Lucent Tech.)
TREASURER PUBLICITY CHAIR
RAVI JAIN, Bellcore B.R. BADRINATH, Rutgers Univ.
REGISTRATION CHAIR
Pravin Bhagwat
IBM, TJ Watson Research Center
STEERING COMMITTEE CHAIR
IMRICH CHLAMTAC, Boston Univ.
PROGRAM COMMITTEE
Rafael Alonso, Matsushita Labs Victor Bahl, DEC
Brian Bershad, U. of Washington Ramon Caceres, Bell Labs (Lucent Tech.)
Imrich Chlamtac, Boston U. Tony Dahbura, Motorola
John Daigle, U. of Mississippi Maurizio Decina, CEFRIEL
JJ Garcia Luna, UC Santa Cruz Mario Gerla, UCLA
Peter Honeyman, U. of Michigan Pierre Humblet, Eurecom
Tom Imielinski, Rutgers U. David Johnson, CMU
Phil Karn, Qualcomm Mark Karol, Bell labs (Lucent Tech.)
Jay Kistler, DEC Barry Leiner, ARPA
Jason Ying Bin Lin, NCTU Teresa Meng, Stanford U.
Mahmoud Naghshineh, IBM TJ Peter O'Reilly, GTE Labs
Charlie Perkins, IBM TJ Ray Pickholtz, GWU
Dhiraj Pradhan, Texas A&M Chris Rose, Rutgers U.
Krishan Sabnani, Bell Labs(Lucent Tech.) Mischa Schwartz, Columbia U.
Martha Steenstrup, BBN Gordon Stuber, GaTech
David Tennenhouse, MIT Marvin Theimer, XEROX
Mehmet Ulema, Bellcore Newman Wilson, D. Sarnoff RC
Parviz Yegani, Qualcomm
Received: from ietf.org by ietf.org id aa15846; 15 Aug 96 15:39 EDT
Received: from cnri by ietf.org id aa15841; 15 Aug 96 15:39 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12476;
15 Aug 96 15:39 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <TAA08576 at pad-thai.cam.ov.com>; Thu, 15 Aug 1996 19:01:17 GMT
Received: from quasar.CSUChico.EDU by MIT.EDU with SMTP
id AA15487; Thu, 15 Aug 96 15:01:14 EDT
Received: from kittykat.CSUChico.EDU by quasar.csuchico.edu with SMTP
(1.38.193.4/16.2) id AA01320; Thu, 15 Aug 1996 11:57:35 -0700
Message-Id: <321372A9.6A0C at quasar.csuchico.edu>
Date: Thu, 15 Aug 1996 11:55:37 -0700
Sender:ietf-archive-request at ietf.org
From: Kay Schenk <kschenk at quasar.csuchico.edu>
Reply-To: kschenk at quasar.csuchico.edu
Organization: Cal. State U., Chico
X-Mailer: Mozilla 3.0b5aGold (WinNT; I)
Mime-Version: 1.0
To: cat-ietf at mit.edu
Subject: GSS-API spec for SPKM
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This document has now expired--July 19--are there any new updates???
Received: from ietf.org by ietf.org id aa18035; 15 Aug 96 17:05 EDT
Received: from cnri by ietf.org id aa18031; 15 Aug 96 17:05 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13692;
15 Aug 96 17:05 EDT
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <UAA11659 at pad-thai.cam.ov.com>; Thu, 15 Aug 1996 20:23:26 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA14120; Thu, 15 Aug 96 16:23:25 EDT
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <UAA11652 at pad-thai.cam.ov.com>; Thu, 15 Aug 1996 20:23:08 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id QAA01476; Thu, 15 Aug 1996 16:23:07 -0400
Message-Id: <199608152023.QAA01476 at winkl.cam.ov.com>
To: kschenk at quasar.csuchico.edu
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: Re: GSS-API spec for SPKM
Date: Thu, 15 Aug 1996 16:23:06 -0400
Sender:ietf-archive-request at ietf.org
From: John Linn <linn at cam.ov.com>
Re:
>This document has now expired--July 19--are there any new updates???
Per the attached announcement from last month, the most recent SPKM
draft (-06) has been approved to become a Proposed Standard RFC, and
is pending action therefor by the RFC editor.
--jl
Received: from ietf.org by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA13113 at pad-thai.cam.ov.com>; Thu, 18 Jul 1996 13:42:23 GMT
Received: from ietf.org by ietf.org id aa06836; 18 Jul 96 9:05 EDT
Received: from ietf.cnri.reston.va.us by ietf.org id aa06809; 18 Jul 96 9:05 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07926;
18 Jul 96 9:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06628;
18 Jul 96 9:04 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07920;
18 Jul 96 9:04 EDT
To: ;@IETF-Announce
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: cat-ietf at mit.edu
Sender: ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: The Simple Public-Key GSS-API Mechanism (SPKM) to
Proposed Standard
Date: Thu, 18 Jul 96 09:04:46 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9607180904.aa07920 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "The Simple Public-Key GSS-API
Mechanism (SPKM)" <draft-ietf-cat-spkmgss-06.txt> as a Proposed Standard.
This document is the product of the Common Authentication Technology
Working Group. The IESG contact person is Jeffrey Schiller.
Technical Summary
This document describes a mechanism to be used with the Generic
Security Service API (GSSAPI, RFC1508, RFC1509). It provides for
authentication, integrity, confidentiality and non-repudiation within
the context of GSSAPI. It is based on the use of public key encryption
technology for digital signatures and key distribution. It provides
for the negotiation of the actual cryptographic algorithms to be
employed between communicating entities.
It makes use of X.509 style certificates but does not specify a
particular key hierarchy. The two end points communicating must have a
common hierarchy in common in order for this mechanism to operate,
however a particular hierarchy is not legislated by this document.
Working Group Summary
The CAT working group came to consensus reasonably quickly on these
documents and no comments were received during IETF last call.
Protocol Quality
Jeff Schiller reviewed this document for the IESG and found it to be
competent and reasonable. By adding a public key based mechanism to
the repertoire of mechanisms available under the GSSAPI, this document
adds value to GSSAPI itself.
Received: from ietf.org by ietf.org id aa20044; 15 Aug 96 18:14 EDT
Received: from zephyr.isi.edu by ietf.org id aa19710; 15 Aug 96 18:07 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA28604>; Thu, 15 Aug 1996 15:07:43 -0700
Message-Id: <199608152207.AA28604 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1970 on Neighbor Discovery for IP Version 6 (IPv6)
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 15 Aug 96 15:10:23 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1970:
Title: Neighbor Discovery for IP Version 6 (IPv6)
Author: T. Narten, E. Nordmark & W. Simpson
Date: August 1996
Mailbox: narten at vnet.ibm.com, nordmark at sun.com,
bsimpson at MorningStar.com
Pages: 82
Characters: 197,632
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1970.txt
This document specifies the Neighbor Discovery protocol for IP Version
6. IPv6 nodes on the same link use Neighbor Discovery to discover
each other's presence, to determine each other's link-layer addresses,
to find routers and to maintain reachability information about the
paths to active neighbors. This RFC is the product of the IPNG
Working Group of the IETF.
This 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960815150756.RFC at ISI.EDU>
SEND /rfc/rfc1970.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1970.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960815150756.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20151; 15 Aug 96 18:14 EDT
Received: from ietf.org by ietf.org id aa20037; 15 Aug 96 18:14 EDT
Received: from zephyr.isi.edu by ietf.org id aa19564; 15 Aug 96 18:02 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA28198>; Thu, 15 Aug 1996 15:02:40 -0700
Message-Id: <199608152202.AA28198 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1888 on OSI NSAPs and IPv6
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 15 Aug 96 15:05:20 PDT
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1888:
Title: OSI NSAPs and IPv6
Author: J. Bound, B. Carpenter, D. Harrington,
J. Houldsworth & A. Lloyd
Date: August 1996
Mailbox: bound at zk3.dec.com, brian at dxcoms.cern.ch,
dan at netrix.lkg.dec.com,
j.houldsworth at ste0906.wins.icl.co.uk,
alan.lloyd at datacraft.com.au
Pages: 16
Characters: 36,469
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1888.txt
This document recommends that network implementors who have planned or
deployed an OSI NSAP addressing plan, and who wish to deploy or
transition to IPv6, should redesign a native IPv6 addressing plan to
meet their needs. However, it also defines a set of mechanisms for
the support of OSI NSAP addressing in an IPv6 network. These
mechanisms are the ones that MUST be used if such support is required.
This document also defines a mapping of IPv6 addresses within the OSI
address format, should this be required. This RFC is the product of
the IPNG Working Group of the IETF.
This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960815150202.RFC at ISI.EDU>
SEND /rfc/rfc1888.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1888.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960815150202.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20153; 15 Aug 96 18:14 EDT
Received: from ietf.org by ietf.org id aa20036; 15 Aug 96 18:14 EDT
Received: from zephyr.isi.edu by ietf.org id aa19797; 15 Aug 96 18:10 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA28843>; Thu, 15 Aug 1996 15:10:06 -0700
Message-Id: <199608152210.AA28843 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1971 on IPv6 Stateless Address Autoconfiguration
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 15 Aug 96 15:12:47 PDT
X-Orig-Sender:ietf-announce-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1971:
Title: IPv6 Stateless Address Autoconfiguration
Author: S. Thomson & T. Narten
Date: August 1996
Mailbox: set at thumper.bellcore.com, narten at vnet.ibm.com
Pages: 23
Characters: 56,890
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1971.txt
This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its
uniqueness on a link, determining what information should be
autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they should be obtained through the
stateless mechanism, the stateful mechanism, or both. This document
defines the process for generating a link-local address, the process
for generating site-local and global addresses via stateless address
autoconfiguration, and the Duplicate Address Detection procedure. The
details of autoconfiguration using the stateful protocol are
specified elsewhere. This RFC is the product of the Address
Autoconfiguration Working Group of the IETF.
This 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960815151032.RFC at ISI.EDU>
SEND /rfc/rfc1971.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1971.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960815151032.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20389; 15 Aug 96 18:19 EDT
Received: from zephyr.isi.edu by ietf.org id aa20271; 15 Aug 96 18:18 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA29457>; Thu, 15 Aug 1996 15:17:59 -0700
Message-Id: <199608152217.AA29457 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1972 on Transmission of IPv6 Packets Over Ethernet
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 15 Aug 96 15:20:39 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1972:
Title: A Method for the Transmission of IPv6 Packets over
Ethernet Networks
Author: M. Crawford
Date: August 1996
Mailbox: crawdad at fnal.gov
Pages: 4
Characters: 6,353
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1972.txt
This memo specifies the frame format for transmission of IPv6 packets
and the method of forming IPv6 link-local addresses on Ethernet
networks. It also specifies the content of the Source/Target
Link-layer Address option used the the Router Solicitation, Router
Advertisement, Neighbor Solicitation, and Neighbor Advertisement
messages described in RFC 1970, when those messages are transmitted on
an Ethernet. This RFC is the product of the IPNG Working Group of the
IETF.
This 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960815151739.RFC at ISI.EDU>
SEND /rfc/rfc1972.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1972.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960815151739.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25091; 15 Aug 96 23:05 EDT
Received: from cnri by ietf.org id aa25087; 15 Aug 96 23:05 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa17988; 15 Aug 96 23:05 EDT
Received: from ietf.org by ietf.org id aa25080; 15 Aug 96 23:04 EDT
Received: from cnri by ietf.org id aa25066; 15 Aug 96 23:04 EDT
Received: from callc2.competitive.com by CNRI.Reston.VA.US id aa17967;
15 Aug 96 23:04 EDT
Received: by callc2.competitive.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5)
id <01BB8AFD.91341850 at callc2.competitive.com>; Thu, 15 Aug 1996 23:00:35 -0400
Message-ID: <c=US%a=_%p=Competitive_Comp%l=CALLC2-960816030033Z-422 at callc2.competitive.com>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: JohnM <JohnM at competitive.com>
To: 'Paul Ferguson' <pferguso at cisco.com>
Cc: "'davidc at APNIC.NET'" <davidc at apnic.net>, "'dfk at RIPE.NET'" <dfk at ripe.net>,
"'kimh at internic.net'" <kimh at internic.net>,
"'markk at internic.net'" <markk at internic.net>,
"'Postel at ISI.EDU'" <Postel at isi.edu>, 'Jim Browning' <jfbb at atmnet.net>
Cc: 'CIDRD List' <cidrd at iepg.org>, 'IESG' <iesg at CNRI.Reston.VA.US>,
'IETF' <ietf at CNRI.Reston.VA.US>
Subject: GPS info in IP addresses
Date: Thu, 15 Aug 1996 23:00:33 -0400
Return-Receipt-To: <JohnM at Competitive.Com>
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
You are right - to attempt to use gps information for routing based on
the current wiring scheme would not be easily feasible. However,
including gps information along with currently manually managed
numbering schemes in the ip address would allow both routing and device
location identification to occur. I know that is not what I stated in
my earlier communique. I apologize for the misleading statement.
The benefit of placing geographic information in the IP address, despite
the fact that we cannot (yet) use this info for routing, is that various
network devices will be locatable within a physical space. This will be
a real benefit for people trying to locate devices that need service,
etc. in a large network. No protocol to date provides such information.
But one day some protocol will. ;-)
>----------
>From:Paul Ferguson[SMTP:pferguso at cisco.com]
>Sent:Monday, July 29, 1996 2:59 PM
>To: JohnM
>Cc: 'davidc at APNIC.NET'; 'dfk at RIPE.NET'; 'kimh at internic.net';
>'markk at internic.net'; 'Postel at ISI.EDU'; 'Jim Browning'; 'CIDRD List'; 'IESG';
>'IETF'
>Subject:RE: draft-hubbard-registry-guidelines-03.txt
>
>At 11:08 AM 7/29/96 -0400, JohnM wrote:
>
>>
>>Consider the Internet-draft that would allow all IP addresses to be
>>created and used dynamically. Addresses would be created primarily by
>>using global positioning (latitude-longitude-altitude) information
>>coupled with MAC addresses (network interface card manufacturer/serial
>>numbers).
>>
>
>Out of morbid curiousity, what happens to the plethora of devices which
>are backhauled?
>
>(For what its worth, I like Kim Hubbard's [et al.] draft.)
>
>- paul
>
>
Received: from ietf.org by ietf.org id aa02810; 16 Aug 96 2:10 EDT
Received: from cnri by ietf.org id aa02743; 16 Aug 96 2:07 EDT
Received: from nic.hq.cic.net by CNRI.Reston.VA.US id aa02353;
16 Aug 96 2:07 EDT
Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id CAA03847; Fri, 16 Aug 1996 02:07:30 -0400 (EDT)
Date: Fri, 16 Aug 1996 02:07:30 -0400 (EDT)
Sender:ietf-request at ietf.org
From: "Dorian R. Kim" <dorian at cic.net>
X-Orig-Sender: dorian at cic.net
To: JohnM <JohnM at competitive.com>
cc: 'CIDRD List' <cidrd at iepg.org>, 'IETF' <ietf at CNRI.Reston.VA.US>
Subject: Re: GPS info in IP addresses
In-Reply-To: <c=US%a=_%p=Competitive_Comp%l=CALLC2-960816030033Z-422 at callc2.competitive.com>
Message-ID: <Pine.SOL.3.95.960816020602.3715B-100000 at nic.hq.cic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
[cc' list trimmed]
On Thu, 15 Aug 1996, JohnM wrote:
> The benefit of placing geographic information in the IP address, despite
> the fact that we cannot (yet) use this info for routing, is that various
> network devices will be locatable within a physical space. This will be
> a real benefit for people trying to locate devices that need service,
> etc. in a large network. No protocol to date provides such information.
This has far less value then you think, IMO
-dorian
Received: from ietf.org by ietf.org id aa03449; 16 Aug 96 2:43 EDT
Received: from cnri by ietf.org id aa03392; 16 Aug 96 2:41 EDT
Received: from singapura.singnet.com.sg by CNRI.Reston.VA.US id aa02702;
16 Aug 96 2:41 EDT
Received: from localhost (mathias at localhost) by singapura.singnet.com.sg (8.7.3/8.7.2) with SMTP id OAA10606; Fri, 16 Aug 1996 14:40:51 +0800 (SST)
Date: Fri, 16 Aug 1996 14:40:50 +0800 (SST)
Sender:ietf-request at ietf.org
From: Mathias Koerber <mathias at staff.singnet.com.sg>
X-Sender: mathias at singapura.singnet.com.sg
Reply-To: mathias at staff.singnet.com.sg
To: "Dorian R. Kim" <dorian at cic.net>
cc: JohnM <JohnM at competitive.com>, 'CIDRD List' <cidrd at iepg.org>,
'IETF' <ietf at CNRI.Reston.VA.US>
Subject: Re: GPS info in IP addresses
In-Reply-To: <Pine.SOL.3.95.960816020602.3715B-100000 at nic.hq.cic.net>
Message-ID: <Pine.OSF.3.93.960816143843.730H-100000 at singapura.singnet.com.sg>
X-Disclaimer: I don't speak for anyone except for myself (and to myself
Organization: SingNet
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 16 Aug 1996, Dorian R. Kim wrote:
| Date: Fri, 16 Aug 1996 02:07:30 -0400 (EDT)
| From: "Dorian R. Kim" <dorian at cic.net>
| To: JohnM <JohnM at competitive.com>
| Cc: 'CIDRD List' <cidrd at iepg.org>, 'IETF' <ietf at CNRI.Reston.VA.US>
| Subject: Re: GPS info in IP addresses
|
| [cc' list trimmed]
|
| On Thu, 15 Aug 1996, JohnM wrote:
|
| > The benefit of placing geographic information in the IP address, despite
| > the fact that we cannot (yet) use this info for routing, is that various
| > network devices will be locatable within a physical space. This will be
| > a real benefit for people trying to locate devices that need service,
| > etc. in a large network. No protocol to date provides such information.
|
| This has far less value then you think, IMO
Oh, there is real value in being able to find the geo location of
a system, but that is already solved by the LOC RRs in DNS, only
not many people have been putting themin yet.
Having ICBM addresses encoded into the IP addresses strikes me as foolish.
Network architecture will never mimic geographic structure..
|
| -dorian
|
Mathias Koerber | Tel: +65 / 471 9820 | mathias at staff.singnet.com.sg
SingNet NOC | Fax: +65 / 475 3273 | Mathias_Koerber at pobox.org.sg
Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias at singnet.com.sg
2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
S'pore 148943 | Disclaimer: I speak only for myself
* Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
Received: from ietf.org by ietf.org id aa05782; 16 Aug 96 3:36 EDT
Received: from cnri by ietf.org id aa05728; 16 Aug 96 3:33 EDT
Received: from nova.unix.portal.com by CNRI.Reston.VA.US id aa03246;
16 Aug 96 3:33 EDT
Received: from jobe.shell.portal.com (jobe.shell.portal.com [156.151.3.4]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id AAA27839; Fri, 16 Aug 1996 00:32:02 -0700
Received: from localhost (dwm at localhost) by jobe.shell.portal.com (8.6.11/8.6.5) with SMTP id AAA26517; Fri, 16 Aug 1996 00:31:49 -0700
Date: Fri, 16 Aug 1996 00:31:48 -0700 (PDT)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at shell.portal.com>
To: Mathias Koerber <mathias at staff.singnet.com.sg>
cc: "Dorian R. Kim" <dorian at cic.net>, JohnM <JohnM at competitive.com>,
'CIDRD List' <cidrd at iepg.org>, 'IETF' <ietf at CNRI.Reston.VA.US>
Subject: Re: GPS info in IP addresses
In-Reply-To: <Pine.OSF.3.93.960816143843.730H-100000 at singapura.singnet.com.sg>
Message-ID: <Pine.SUN.3.93.960816002816.25882B-100000 at jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 16 Aug 1996, Mathias Koerber wrote:
> Having ICBM addresses encoded into the IP addresses strikes me as foolish.
> Network architecture will never mimic geographic structure..
*AND* for those applications which could use such information, I think
there would be a better mechanism for providing it than wasting a bunch
of bits in the ip address which must then be carried on every packet.
Use SMTP or perhaps a new PING format which also returned the GPS data
if known.
OTOH, I can think of more use for the GPS data than the hardware address
now included in the ipv6 address.
Dave Morris
Received: from ietf.org by ietf.org id aa06063; 16 Aug 96 3:44 EDT
Received: from cnri by ietf.org id aa06000; 16 Aug 96 3:43 EDT
Received: from iti.gov.sg by CNRI.Reston.VA.US id aa03350; 16 Aug 96 3:43 EDT
Received: (from mailer at localhost) by iti.gov.sg (8.6.11/8.6.11) id PAA13908; Fri, 16 Aug 1996 15:31:37 +0800
Received: from unknown(192.122.132.134) by iti.gov.sg via smap (V1.3)
id sma013902; Fri Aug 16 15:31:08 1996
Received: from p-peter.iti.gov.sg by jupiter.iti.gov.sg (SMI-8.6/SMI-SVR4)
id PAA17637; Fri, 16 Aug 1996 15:25:20 +0800
Message-ID: <32142459.4D28 at iti.gov.sg>
Date: Fri, 16 Aug 1996 15:33:45 +0800
Sender:ietf-request at ietf.org
From: Peter Teoh <peter at iti.gov.sg>
Reply-To: peter at iti.gov.sg
Organization: Information Technology Institute
X-Mailer: Mozilla 3.0b5Gold (Win95; I)
MIME-Version: 1.0
To: mathias at staff.singnet.com.sg
CC: "Dorian R. Kim" <dorian at cic.net>, JohnM <JohnM at competitive.com>,
'CIDRD List' <cidrd at iepg.org>, 'IETF' <ietf at CNRI.Reston.VA.US>
Subject: Re: GPS info in IP addresses
References: <Pine.OSF.3.93.960816143843.730H-100000 at singapura.singnet.com.sg>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
What if a notebook flying in a airplane? The IP address will be
dynamically changing all the time? The aim of IN (Intelligent Network)
is so that one IP address (or telephone numbers?) can travel everywhere
- whether it is home or workplace.
Mathias Koerber wrote:
>
> On Fri, 16 Aug 1996, Dorian R. Kim wrote:
>
> | Date: Fri, 16 Aug 1996 02:07:30 -0400 (EDT)
> | From: "Dorian R. Kim" <dorian at cic.net>
> | To: JohnM <JohnM at competitive.com>
> | Cc: 'CIDRD List' <cidrd at iepg.org>, 'IETF' <ietf at CNRI.Reston.VA.US>
> | Subject: Re: GPS info in IP addresses
> |
> | [cc' list trimmed]
> |
> | On Thu, 15 Aug 1996, JohnM wrote:
> |
> | > The benefit of placing geographic information in the IP address, despite
> | > the fact that we cannot (yet) use this info for routing, is that various
> | > network devices will be locatable within a physical space. This will be
> | > a real benefit for people trying to locate devices that need service,
> | > etc. in a large network. No protocol to date provides such information.
> |
> | This has far less value then you think, IMO
>
> Oh, there is real value in being able to find the geo location of
> a system, but that is already solved by the LOC RRs in DNS, only
> not many people have been putting themin yet.
>
> Having ICBM addresses encoded into the IP addresses strikes me as foolish.
> Network architecture will never mimic geographic structure..
>
> |
> | -dorian
> |
>
> Mathias Koerber | Tel: +65 / 471 9820 | mathias at staff.singnet.com.sg
> SingNet NOC | Fax: +65 / 475 3273 | Mathias_Koerber at pobox.org.sg
> Q'town Tel. Exch. | PGP: Keyid: 768/25E082BD, finger mathias at singnet.com.sg
> 2 Stirling Rd | 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 65
> S'pore 148943 | Disclaimer: I speak only for myself
> * Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft *
--
Bye! :)
Peter Teoh
+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Peter Teoh Information Technology Institute
Internet : peter at iti.gov.sgScience Park II
Tel : 65-7705585 11 Science Park Road
Fax : 65-7791827 Singapore 117685
http://www.iti.gov.sg/
Received: from ietf.org by ietf.org id aa10623; 16 Aug 96 9:19 EDT
Received: from cnri by ietf.org id aa10284; 16 Aug 96 9:14 EDT
Received: from seawind.bellcore.com by CNRI.Reston.VA.US id aa06732;
16 Aug 96 9:14 EDT
Received: (from huitema at localhost) by seawind.bellcore.com (8.6.9/8.6.10) id JAA17472; Fri, 16 Aug 1996 09:13:04 -0400
Date: Fri, 16 Aug 1996 09:13:04 -0400
Sender:ietf-request at ietf.org
From: Christian Huitema <huitema at bellcore.com>
Message-Id: <9608160913.ZM17470 at seawind.bellcore.com>
In-Reply-To: Peter Teoh <peter at iti.gov.sg>
"Re: GPS info in IP addresses" (Aug 16, 3:33pm)
References: <Pine.OSF.3.93.960816143843.730H-100000 at singapura.singnet.com.sg>
<32142459.4D28 at iti.gov.sg>
X-Mailer: Z-Mail (3.2.0 06sep94)
To: peter at iti.gov.sg
Subject: Re: GPS info in IP addresses
Cc: CIDRD List <cidrd at iepg.org>, IETF <ietf at CNRI.Reston.VA.US>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Source-Info: From (or Sender) name not authenticated.
> What if a notebook flying in a airplane? The IP address will be
> dynamically changing all the time? The aim of IN (Intelligent Network)
> is so that one IP address (or telephone numbers?) can travel everywhere
> - whether it is home or workplace.
IN uses databases for redirection. A connection to a certain address may
be trapped, the switch will ask a server about what to do next, and the
connection will be established to a different number. There are at least
two ways to do the same functions in the Internet.
In most cases, the functions if IN will be performed by simply updating
the DNS. Telephone users see telephone numbers, but internauts see domain
names, not IP addresses. The DNS introduces the "level of indirection"
that is implemented by IN servers.
The DNS, however, is not designed for very fast updates. DNS requests
already represents about 15% of the packets and 6% of the bytes exchanged
in the backbone. This is large. If we would make the DNS more dynamic,
caching would be even less efficient and the overhead would grow even
larger.
Rapid updates have to be implemented by rapid redirections, which can be
done either by using multicast, mobile IP or application level
redirections. The multicast solution,joining and leaving groups when
changing cell, can be implemented with regular IGMP. Mobile IP is on its
way towards a standard. Application level redirection may be required in
some cases, as examplified in the SIP proposal in Mmusic.
None of these solutions require geographic addressing.
--
Christian Huitema
Received: from ietf.org by ietf.org id aa11776; 16 Aug 96 9:42 EDT
Received: from cnri by ietf.org id aa11771; 16 Aug 96 9:42 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa07112;
16 Aug 96 9:42 EDT
Received: (from daemon at localhost) by atlas.xylogics.com (8.7.3/8.7.3) id JAA14207 for ietf-rip-include; Fri, 16 Aug 1996 09:39:09 -0400 (EDT)
Received: from ietf.org (ietf.org [132.151.1.19]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id JAA14204 for <ietf-rip at xylogics.com>; Fri, 16 Aug 1996 09:39:06 -0400 (EDT)
Received: from localhost by ietf.org id aa11366; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-archive-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rip-ripng-04.txt
Date: Fri, 16 Aug 1996 09:38:40 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11366 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Routing Information Protocol
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : RIPng for IPv6
Author(s) : G. Malkin, R. Minnear
Filename : draft-ietf-rip-ripng-04.txt
Pages : 20
Date : 08/15/1996
This document specifies a routing protocol for an IPv6 internet.
It is based on protocols and algorithms currently in wide use
in the IPv4 Internet.
This specification represents the minimum change to the
Routing Information Protocol (RIP), as specified in RFC 1058 [1]
and RFC 1723 [2], necessary for operation over IPv6 [3].
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-ietf-rip-ripng-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rip-ripng-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rip-ripng-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815153551.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rip-ripng-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rip-ripng-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815153551.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11897; 16 Aug 96 9:43 EDT
Received: from localhost by ietf.org id aa11274; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bradner-key-words-01.txt
Date: Fri, 16 Aug 1996 09:38:29 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11274 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Key words for use in RFCs to
Indicate Requirement Levels
Author(s) : S. Bradner
Filename : draft-bradner-key-words-01.txt
Pages : 2
Date : 08/15/1996
In many standards track documents several words are used to signify the
requirements of the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF
documents. Note that the force of these words is modified by the
requirement level of the document itself.
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-bradner-key-words-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bradner-key-words-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bradner-key-words-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815142433.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bradner-key-words-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bradner-key-words-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815142433.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11873; 16 Aug 96 9:43 EDT
Received: from localhost by ietf.org id aa11258; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-bernstein-mail-loops-war-01.txt
Date: Fri, 16 Aug 1996 09:38:27 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11258 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Tools in the War on Mail Loops
Author(s) : D. Bernstein
Filename : draft-bernstein-mail-loops-war-01.txt
Pages : 7
Date : 08/15/1996
An automailer means any program that receives a mail message and
automatically sends one or more mail messages. This term is meant to
include not only a mail-based server, such as a mailing list exploder or a
vacation program, but also an SMTP server, which receives a message from
the network and relays it to a local or remote user.
In a network full of automailers, any mistake can cause a mail loop. Since
some automailers generate several outputs in response to a single input, a
loop can produce an exponential explosion of mail.
All the automailers in the qmail package follow a general philosophy
designed to prevent mail loops and limit the damage from any loops
that do occur. These automailers have been repeatedly observed to
fail safe: they stop loops in the face of typical failures
by other hosts. This document explains the philosophy and
describes the automailers.
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-bernstein-mail-loops-war-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-bernstein-mail-loops-war-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-bernstein-mail-loops-war-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815114907.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-bernstein-mail-loops-war-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-bernstein-mail-loops-war-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815114907.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11874; 16 Aug 96 9:43 EDT
Received: from localhost by ietf.org id aa11283; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ids at umich.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ids-discovery-01.txt
Date: Fri, 16 Aug 1996 09:38:30 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11283 at 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 Directory
Services Working Group of the IETF.
Title : Finding Stuff
(Providing information to support service discovery)
Author(s) : R. Moats, M. Hamilton
Filename : draft-ietf-ids-discovery-01.txt
Pages : 12
Date : 08/15/1996
This document proposes a solution to the problem of finding information
about which services are being offered at a particular Internet domain,
based on deployment experience with the Netfind White Pages directory
software.
This approach makes it possible to supply clients with more information
than the DNS aliases which have been widely deployed in this role - notably
the port numbers being used by servers. However, it is not without
problems, and we have tried to take account of these.
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-ietf-ids-discovery-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ids-discovery-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ids-discovery-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815144555.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ids-discovery-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-discovery-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815144555.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11882; 16 Aug 96 9:43 EDT
Received: from localhost by ietf.org id aa11343; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-cat-gssv2-07.txt
Date: Fri, 16 Aug 1996 09:38:38 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11343 at ietf.org>
--NextPart
A Revised 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.
Note: This revision reflects comments received during the last call period.
Title : Generic Security Service Application Program Interface,
Version 2
Author(s) : J. Linn
Filename : draft-ietf-cat-gssv2-07.txt
Pages : 86
Date : 08/15/1996
The Generic Security Service Application Program Interface (GSS-API), as
defined in RFC-1508, provides security services to callers in a generic
fashion, supportable with a range of underlying mechanisms and technologies
and hence allowing source-level portability of applications to different
environments. This specification defines GSS-API services and primitives at
a level independent of underlying mechanism and programming language
environment, and is to be complemented by other, related specifications:
documents defining specific parameter bindings for
particular language environments
documents defining token formats, protocols, and procedures to be
implemented in order to realize GSS-API services atop
particular security mechanisms
This Internet-Draft revises RFC-1508, making specific, incremental changes
in response to implementation experience and liaison requests. It is
intended, therefore, that this draft or a successor version thereto will
become the basis for subsequent progression of the GSS-API specification on
the standards track.
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-ietf-cat-gssv2-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-gssv2-07.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-gssv2-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815153205.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-cat-gssv2-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-gssv2-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815153205.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11877; 16 Aug 96 9:43 EDT
Received: from localhost by ietf.org id aa11303; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-armitage-ion-mars-scsp-01.txt
Date: Fri, 16 Aug 1996 09:38:32 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11303 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Redundant MARS architectures and SCSP
Author(s) : G. Armitage
Filename : draft-armitage-ion-mars-scsp-01.txt
Pages : 36
Date : 08/15/1996
The Server Cache Synchronisation Protocol (SCSP) has been proposed as a
general mechanism for synchronising the databases of NHRP Next Hop Servers
(NHSs), MARSs, and MARS Multicast Servers (MCSs). All these entities are
different parts to the IETF's ION solution. This document attempts to
identify a range of distributed MARS scenarios, highlight associated
problems, and describe how SCSP may be applied. This document does not deal
with redundant MCS scenarios.
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-armitage-ion-mars-scsp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-armitage-ion-mars-scsp-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-armitage-ion-mars-scsp-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815145749.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-armitage-ion-mars-scsp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-armitage-ion-mars-scsp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815145749.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa11878; 16 Aug 96 9:43 EDT
Received: from localhost by ietf.org id aa11319; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: www-html at w3.org
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-html-i18n-05.txt
Date: Fri, 16 Aug 1996 09:38:34 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11319 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Markup Language
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Internationalization of the Hypertext Markup Language
Author(s) : F. Yergeau, G. Nicol, G. Adams, M. Duerst
Filename : draft-ietf-html-i18n-05.txt
Pages : 43
Date : 08/15/1996
The Hypertext Markup Language (HTML) is a markup language used to create
hypertext documents that are platform independent. Initially, the
application of HTML on the World Wide Web was seriouslyriously restricted
by its reliance on the ISO-8859-1 coded character set, restricted by its
reliance on the ISO-8859-1 coded character set, which is appropriate only
for Western European languages. Despite this restriction, HTML has been
widely used with other languages, using other coded character sets or
character encodings, at the expense of interoperability.
This document is meant to address the issue of the internationalization
(i18n, i followed by 18 letters followed by n) of HTML by extending the
specification of HTML and giving additional recommendations for proper
internationalization support. A foremost consideration is to make sure
that HTML remains a valid application of SGML, while enabling its use
with all languages of the world.
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-ietf-html-i18n-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-html-i18n-05.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-html-i18n-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815151516.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-html-i18n-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-html-i18n-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815151516.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab11897; 16 Aug 96 9:43 EDT
Received: from localhost by ietf.org id aa11368; 16 Aug 96 9:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-v11-spec-07.txt, .ps
Date: Fri, 16 Aug 1996 09:38:42 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608160938.aa11368 at ietf.org>
--NextPart
A Revised 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.
Note: This revision reflects comments received during the last call period.
Title : Hypertext Transfer Protocol -- HTTP/1.1
Author(s) : R. Fielding, J. Gettys, J. Mogul,
H. Frystyk, T. Berners-Lee
Filename : draft-ietf-http-v11-spec-07.txt, .ps
Pages : 153
Date : 08/15/1996
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, collaborative, hypermedia information systems. It is a
generic, stateless, object-oriented protocol which can be used for many
tasks, such as name servers and distributed object management systems,
through extension of its request methods. A feature of HTTP is the typing
and negotiation of data representation, allowing systems to be built
independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative
since 1990. This specification defines the protocol referred to as
"HTTP/1.1".
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-ietf-http-v11-spec-07.txt".
Or
"get draft-ietf-http-v11-spec-07.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-v11-spec-07.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-v11-spec-07.txt".
Or
"FILE /internet-drafts/draft-ietf-http-v11-spec-07.ps".
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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815154312.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-v11-spec-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-v11-spec-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815154312.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13428; 16 Aug 96 10:11 EDT
Received: from cnri by ietf.org id aa13424; 16 Aug 96 10:11 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa07521; 16 Aug 96 10:11 EDT
Received: from ietf.org by ietf.org id aa13417; 16 Aug 96 10:11 EDT
Received: from cnri by ietf.org id aa13403; 16 Aug 96 10:11 EDT
Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa07516; 16 Aug 96 10:11 EDT
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.249.124])
id QQbdae01233; Fri, 16 Aug 1996 10:09:56 -0400 (EDT)
Message-Id: <QQbdae01233.199608161409 at rodan.UU.NET>
To: JohnM <JohnM at competitive.com>
cc: 'Paul Ferguson' <pferguso at cisco.com>,
"'davidc at APNIC.NET'" <davidc at apnic.net>, "'dfk at RIPE.NET'" <dfk at ripe.net>,
"'kimh at internic.net'" <kimh at internic.net>,
"'markk at internic.net'" <markk at internic.net>,
"'Postel at ISI.EDU'" <Postel at isi.edu>, 'Jim Browning' <jfbb at atmnet.net>,
'CIDRD List' <cidrd at iepg.org>, 'IESG' <iesg at CNRI.Reston.VA.US>,
'IETF' <ietf at CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at ietf.org
Sender:ietf-archive-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: GPS info in IP addresses
References: <c=US%a=_%p=Competitive_Comp%l=CALLC2-960816030033Z-422 at callc2.competitive.com>
In-reply-to: Your message of "Thu, 15 Aug 1996 23:00:33 EDT."
<c=US%a=_%p=Competitive_Comp%l=CALLC2-960816030033Z-422 at callc2.competitive.com>
Date: Fri, 16 Aug 1996 10:09:55 -0400
X-Orig-Sender: louie at uu.net
> The benefit of placing geographic information in the IP address, despite
> the fact that we cannot (yet) use this info for routing, is that various
> network devices will be locatable within a physical space. This will be
> a real benefit for people trying to locate devices that need service,
> etc. in a large network. No protocol to date provides such information.
Er, there are resource records defined in the DNS for exactly this
purpose. Having the geographical coordinates imbedded within the
network-level address doesn't seem to be a particularlly good fit for
this particular application.
Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
UUNET Technologies, Inc. Voice: +1 703 206 5823
3060 Williams Drive Fax: +1 703 208 5390
Fairfax, VA 22031
Received: from ietf.org by ietf.org id aa17266; 16 Aug 96 11:00 EDT
Received: from localhost by ietf.org id aa17072; 16 Aug 96 10:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-borman-jumbograms-01.txt
Date: Fri, 16 Aug 1996 10:55:17 -0400
X-Orig-Sender: cclark at ietf.org
Message-ID: <9608161055.aa17072 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : TCP and UDP over IPv6 Jumbograms
Author(s) : D. Borman
Filename : draft-borman-jumbograms-01.txt
Pages : 3
Date : 08/15/1996
IPv6 supports datagrams larger than 65535 bytes long, often referred to as
jumbograms, through use of the Jumbo Payload hop-by-hop option [Deering95].
The UDP protocol has a 16-bit length field that keeps it from being able to
make use of jumbograms, and though TCP does not have a length field, both
the MSS option and the Urgent field are constrained by 16-bits. This
document describes some simple changes that can be made to allow TCP and
UDP to make use of IPv6 jumbograms.
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-borman-jumbograms-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-borman-jumbograms-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.8)
o Europe
Address: nic.nordu.net (192.36.148.17)
Address: ftp.nis.garr.it (193.205.245.10)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-borman-jumbograms-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.
For questions, please mail to Internet-Drafts at ietf.org
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <19960815150201.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-borman-jumbograms-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-borman-jumbograms-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19960815150201.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17765; 16 Aug 96 11:15 EDT
Received: from zephyr.isi.edu by ietf.org id aa17588; 16 Aug 96 11:11 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00152>; Fri, 16 Aug 1996 08:11:31 -0700
Message-Id: <199608161511.AA00152 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1988 on Search Address Patent Use
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 16 Aug 96 08:14:11 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1988:
Title: Conditional Grant of Rights to Specific
Hewlett-Packard Patents In Conjunction With the
Internet Engineering Task Force's
Internet-Standard Network Management Framework
Author: G. McAnally, D. Gilbert & J. Flick
Date: August 1996
Mailbox: johnf at hprnd.rose.hp.com
Pages: 2
Characters: 3,821
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1988.txt
This document is NOT a standard. It is an announcement to interested
parties of a conditional grant by the Hewlett-Packard Company (HP) of
certain rights to use autotopology network management technology
covered by specific HP patents in conjunction with the Internet
Engineering Task Force's (IETF's) Internet-standard network management
framework. This grant is made to help facilitate inclusion of certain
patented search address technology covering network device mapping in
IETF standards-track Management Information Base (MIB) modules. HP is
offering this search address technology to the IETF as a technique for
mapping network devices. It should be noted that the confirmatory
license mentioned is optional, since the grant of rights is automatic.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960816081109.RFC at ISI.EDU>
SEND /rfc/rfc1988.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1988.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960816081109.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17953; 16 Aug 96 11:17 EDT
Received: from zephyr.isi.edu by ietf.org id aa17787; 16 Aug 96 11:15 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00294>; Fri, 16 Aug 1996 08:15:14 -0700
Message-Id: <199608161515.AA00294 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1986 on ETFTP
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 16 Aug 96 08:17:55 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1986:
Title: Experiments with a Simple File Transfer Protocol
for Radio Links using Enhanced Trivial File
Transfer Protocol (ETFTP)
Author: W. Polites, W. Wollman, D. Woo & R. Langan
Date: August 1996
Mailbox: wpolites at mitre.org, wwollman at mitre.org,
dwoo at mitre.org, langanr at doim6.monmouth.army.mil
Pages: 21
Characters: 49,772
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1986.txt
This document is a description of the Enhanced Trivial File Transfer
Protocol (ETFTP). This protocol is an experimental implementation of
the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file
transfer application program. It uses the User Datagram Protocol
(UDP), as its transport layer. The two protocols are layered to create
the ETFTP client server application. The ETFTP program is named after
Trivial File Transfer Protocol (TFTP), because the source code from
TFTP is used as the building blocks for the ETFTP program. This
implementation also builds on but differs from the work done by the
National Imagery Transmission Format Standard. This document is
published for discussion and comment on improving the throughput
performance of data transfer utilities over Internet Protocol (IP)
compliant, half duplex, radio networks.
This memo defines an Experimental Protocol for the Internet community.
This memo does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960816081500.RFC at ISI.EDU>
SEND /rfc/rfc1986.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1986.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960816081500.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18179; 16 Aug 96 11:20 EDT
Received: from zephyr.isi.edu by ietf.org id aa17994; 16 Aug 96 11:18 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00372>; Fri, 16 Aug 1996 08:17:58 -0700
Message-Id: <199608161517.AA00372 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1987 on GSMP Protocol Specification
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 16 Aug 96 08:20:38 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1987:
Title: Ipsilon's General Switch Management Protocol
Specification Version 1.1
Author: P. Newman, W. Edwards, R. Hinden, E. Hoffman,
F. Ching Liaw, T. Lyon & G. Minshall
Date: August 1996
Mailbox: pn at ipsilon.com, texas at sprintcorp.com,
hinden at ipsilon.com, hoffman at ipsilon.com,
fong at ipsilon.com, pugs at ipsilon.com,
minshall at ipsilon.com
Pages: 44
Characters: 105,821
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1987.txt
The General Switch Management Protocol (GSMP), is a general purpose
protocol to control an ATM switch. GSMP allows a controller to
establish and release connections across the switch; add and delete
leaves on a point-to-multipoint connection; manage switch ports;
request configuration information; and request statistics.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960816081807.RFC at ISI.EDU>
SEND /rfc/rfc1987.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1987.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960816081807.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18361; 16 Aug 96 11:23 EDT
Received: from zephyr.isi.edu by ietf.org id aa18221; 16 Aug 96 11:21 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00446>; Fri, 16 Aug 1996 08:21:17 -0700
Message-Id: <199608161521.AA00446 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI18, RFC1983 on Internet Users' Glossary
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 16 Aug 96 08:23:57 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
FYI 18:
RFC 1983:
Title: Internet Users' Glossary
Author: G. Malkin, Editor
Date: August 1996
Mailbox: gmalkin at Xylogics.COM
Pages: 62
Characters: 123,008
Obsoletes: 1392
URL: ftp://ds.internic.net/rfc/rfc1983.txt
There are many networking glossaries in existence. This glossary
concentrates on terms which are specific to the Internet. Naturally,
there are entries for some basic terms and acronyms because other
entries refer to them. This RFC is the product of the Internet User
Glossary Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960816082143.RFC at ISI.EDU>
SEND /rfc/rfc1983.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1983.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960816082143.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18418; 16 Aug 96 11:23 EDT
Received: from localhost by ietf.org id aa18312; 16 Aug 96 11:22 EDT
To: ietf at ietf.org
Subject: Re: Internet Domain Survey, July 1996
Sender:ietf-request at ietf.org
From: Jason Lindquist <jlindqui at strange.qualcomm.com>
Date: Fri, 16 Aug 1996 11:22:30 -0400
X-Orig-Sender: scoya at ietf.org
Message-ID: <9608161122.aa18312 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In <Pine.LNX.3.91.960809100924.17273F at aragorn.alternic.net> Eugene Kashpureff
(ekashp at alternic.net) wrote:
> You seem to have missed the ALTERNIC.NET TLDs
I wouldn't count on it, considering most folks don't consider
alternic to be anything more than a rogue DNS "provider".
JL
--
Jason A. Lindquist KB9LCL <*> "Unfortunately, no one is listening
jlindqui at qualcomm.com (business) to keystrokes at the moment. You
linky at uiuc.edu (personal) might as well stop typing" -- S. Dorner
Received: from ietf.org by ietf.org id aa18696; 16 Aug 96 11:30 EDT
Received: from zephyr.isi.edu by ietf.org id aa18568; 16 Aug 96 11:27 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00612>; Fri, 16 Aug 1996 08:27:48 -0700
Message-Id: <199608161527.AA00612 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1989 on PPP Link Quality Monitoring
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 16 Aug 96 08:30:28 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1989:
Title: PPP Link Quality Monitoring
Author: W. Simpson
Date: August 1996
Mailbox: bsimpson at MorningStar.com
Pages: 16
Characters: 29,289
Obsoletes: 1333
URL: ftp://ds.internic.net/rfc/rfc1989.txt
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
also defines an extensible Link Control Protocol, which allows
negotiation of a Quality Protocol for continuous monitoring of the
viability of the link. This document defines a protocol for
generating Link-Quality-Reports. This RFC is the product of the
Point-to-Point Extensions Working Group of the IETF.
This is now a Draft 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960816082809.RFC at ISI.EDU>
SEND /rfc/rfc1989.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1989.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960816082809.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18830; 16 Aug 96 11:33 EDT
Received: from zephyr.isi.edu by ietf.org id aa18732; 16 Aug 96 11:31 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00693>; Fri, 16 Aug 1996 08:31:45 -0700
Message-Id: <199608161531.AA00693 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1990 on PPP Multilink
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 16 Aug 96 08:34:26 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1990:
Title: The PPP Multilink Protocol (MP)
Author: K. Sklower, B. Lloyd, G. McGregor, D. Carr
& T. Coradetti
Date: August 1996
Mailbox: sklower at CS.Berkeley.EDU, brian at lloyd.com,
glenn at lloyd.com, dcarr at Newbridge.COM,
70761.1664 at compuserve.com
Pages: 24
Characters: 53,271
Obsoletes: 1717
URL: ftp://ds.internic.net/rfc/rfc1990.txt
This document proposes a method for splitting, recombining and
sequencing datagrams across multiple logical data links. This work
was originally motivated by the desire to exploit multiple bearer
channels in ISDN, but is equally applicable to any situation in which
multiple PPP links connect two systems, including async links. This
is accomplished by means of new PPP options and protocols. The
differences between the current PPP Multilink specification (RFC 1717)
and this memo are explained in Section 11. Any system implementing
the additional restrictions required by this memo will be backwards
compatible with conforming RFC 1717 implementations. This RFC is the
product of the Point-to-Point Protocol Extensions Working Group of the
IETF.
This is now a Draft 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960816083136.RFC at ISI.EDU>
SEND /rfc/rfc1990.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1990.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960816083136.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18991; 16 Aug 96 11:37 EDT
Received: from zephyr.isi.edu by ietf.org id aa18876; 16 Aug 96 11:35 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00828>; Fri, 16 Aug 1996 08:35:13 -0700
Message-Id: <199608161535.AA00828 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1991 on PGP Message Exchange Formats
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 16 Aug 96 08:37:54 PDT
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1991:
Title: PGP Message Exchange Formats
Author: D. Atkins, W. Stallings & P. Zimmermann
Date: August 1996
Mailbox: warlord at MIT.EDU, stallings at ACM.org, prz at acm.org
Pages: 21
Characters: 46,255
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1991.txt
PGP (Pretty Good Privacy) uses a combination of public-key and
conventional encryption to provide security services for electronic
mail messages and data files. These services include confidentiality
and digital signature. PGP is widely used throughout the global
computer community. This document describes the format of "PGP
files", i.e., messages that have been encrypted and/or signed with
PGP.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. 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 at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at 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 at 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 at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
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 at ds.internic.net"
Content-Type: text/plain
Content-ID: <960816083453.RFC at ISI.EDU>
SEND /rfc/rfc1991.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1991.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <960816083453.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20176; 16 Aug 96 11:57 EDT
Received: from cnri by ietf.org id aa20039; 16 Aug 96 11:54 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa09267;
16 Aug 96 11:54 EDT
Received: from localhost (valdis at LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id LAA42988; Fri, 16 Aug 1996 11:54:23 -0400
Message-Id: <199608161554.LAA42988 at black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.7 5/3/96
To: JohnM <JohnM at competitive.com>
Cc: 'IETF' <ietf at CNRI.Reston.VA.US>
Subject: Re: GPS info in IP addresses
In-Reply-To: Your message of "Thu, 15 Aug 1996 23:00:33 EDT."
<c=US%a=_%p=Competitive_Comp%l=CALLC2-960816030033Z-422 at callc2.competitive.com>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <c=US%a=_%p=Competitive_Comp%l=CALLC2-960816030033Z-422 at callc2.competitive.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="===_-1_Fri_Aug_16_11:54:19_EDT_1996";
micalc=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Fri, 16 Aug 1996 11:54:21 -0400
Source-Info: From (or Sender) name not authenticated.
--===_-1_Fri_Aug_16_11:54:19_EDT_1996
Content-Type: text/plain; charset=us-ascii
On Thu, 15 Aug 1996 23:00:33 EDT, JohnM said:
> The benefit of placing geographic information in the IP address, despite
> the fact that we cannot (yet) use this info for routing, is that various
> network devices will be locatable within a physical space. This will be
> a real benefit for people trying to locate devices that need service,
> etc. in a large network. No protocol to date provides such information.
Umm.. GPS doesn't do it either. I just checked our machine room, and
in a 50 foot by 30 foot area, we have a Rolm CBX switch with about
2,000 lines on it, 14 19" racks full of modems and terminal servers
(at least 800 lines if not more) 48 server machines, and one end of a
3090 mainframe... All GPS will tell you is "I'm in the machine room
someplace".
I hate to think what GPS on mae-east or other interconnect would look
like ;)
GPS isn't suited for a densely packed network due to a limited
resolution. And it isn't suited for a WAN either. Consider a T-1
line. You can't use GPS for YOUR end, because it's in a rat's nets of
OTHER comm gear in the same 19" rack. You can't use it for the OTHER
end, because (a) you already *know* (see below) it goes to Building 5
at your Boston site and (b) at the Boston end, it's in a rat's nets of
(etc etc).
If you don't already have the rack labeled "boston link", "Chicago
link" and so on, GPS won't help you. What you need is a roll of
masking tape and a felt tip pen.... And even if you know where the two
ends are, GPS won't tell you how the circuit is routed (which is vital
when diagnosing backhoe problems) ...
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--===_-1_Fri_Aug_16_11:54:19_EDT_1996
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMhSZp9QBOOoptg9JAQHqPgP/QD2VXbtSG8t63PpGDU+oi8R1hg7qPPg9
es2yJ9x0NgW9J5A6TIgtoSa6Z3LDlKYO464K6Fq+2Z78IVHoug0/adMoJqn2Vg6l
gtF8bx9neJoKO0awnY007SGkBfZ2Su2cmxoG037HX04ij6EPYdMzsMBv0WdyTsnJ
0T+PzvzFEFs=
=dv6e
-----END PGP MESSAGE-----
--===_-1_Fri_Aug_16_11:54:19_EDT_1996--
Received: from ietf.org by ietf.org id aa27642; 16 Aug 96 15:19 EDT
Received: from cnri by ietf.org id aa27580; 16 Aug 96 15:17 EDT
Received: from gw.quake.net by CNRI.Reston.VA.US id aa12605; 16 Aug 96 15:17 EDT
Received: from quest.quake.net (avg at l24.ip.Quake.Net [198.68.224.24]) by gw.quake.net (8.7.4/8.7.4) with ESMTP id MAA11817; Fri, 16 Aug 1996 12:17:22 -0700 (PDT)
Received: (from avg at localhost) by quest.quake.net (8.6.9/8.6.9) id MAA01311; Fri, 16 Aug 1996 12:15:18 -0700
Date: Fri, 16 Aug 1996 12:15:18 -0700
Sender:ietf-request at ietf.org
From: Vadim Antonov <avg at quake.net>
Message-Id: <199608161915.MAA01311 at quest.quake.net>
To: huitema at bellcore.com, peter at iti.gov.sg
Subject: Re: GPS info in IP addresses
Cc: cidrd at iepg.org, ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
Christian Huitema wrote:
>The DNS, however, is not designed for very fast updates. DNS requests
>already represents about 15% of the packets and 6% of the bytes exchanged
>in the backbone. This is large. If we would make the DNS more dynamic,
>caching would be even less efficient and the overhead would grow even
>larger.
That says about general state of brokennes of DNS implemementations
more than of anything else.
--vadim
Received: from ietf.org by ietf.org id aa02354; 16 Aug 96 17:30 EDT
Received: from cs.columbia.edu by ietf.org id aa02296; 16 Aug 96 17:29 EDT
Received: from tune.cs.columbia.edu (tune.cs.columbia.edu [128.59.10.5]) by cs.columbia.edu (8.7.5/8.6.6) with ESMTP id RAA20868; Fri, 16 Aug 1996 17:28:55 -0400 (EDT)
Received: from tune.cs.columbia.edu (localhost [127.0.0.1]) by tune.cs.columbia.edu (8.7.5/8.6.6) with SMTP id RAA06395; Fri, 16 Aug 1996 17:28:51 -0400 (EDT)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <3214E813.506B at cs.columbia.edu>
Date: Fri, 16 Aug 1996 17:28:51 -0400
Sender:ietf-request at ietf.org
From: "Henning G. Schulzrinne" <schulzrinne at cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: ietf at ietf.org, rem-conf at es.net
Subject: CFP: IEEE Communications Magazine, Internet Technology
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Call For Papers
Venue: IEEE Communications Magazine
What: New Feature Series on Internet Technology
Deadline: Sept. 1, 1996 for January 1997 publication (feature series
to appear every six months)
Details: http://www.cs.columbia.edu/~hgs/ComMag/
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu (NEW!)
Dept. of Computer Science phone: +1 212 939-7042
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 aa08436; 16 Aug 96 22:44 EDT
Received: from zephyr.isi.edu by ietf.org id aa08182; 16 Aug 96 22:32 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA28523>; Fri, 16 Aug 1996 16:39:49 -0700
Message-Id: <199608162339.AA28523 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: Internet Monthly Report for April, 1996
Cc: imr at isi.edu, imr-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 16 Aug 96 16:39:49 PDT
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
--NextPart
The Internet Monthly Report for April, 1996 is now available
at the following location:
URL= ftp://ftp.isi.edu/in-notes/imr/imr9604.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 at 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 at 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 IMR9604.TXT. For example,
IMR9604.TXT is the report for April 1996.
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 at ISI.EDU with
the message body help: ways_to_get_imrs. For example:
To: rfc-info at 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 IMR9604.TXT is the report for April 1996).
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 at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9604
--OtherAccess
Content-Type: Message/External-body;
name="imr9604.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 aa08435; 16 Aug 96 22:44 EDT
Received: from zephyr.isi.edu by ietf.org id aa08173; 16 Aug 96 22:31 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA29179>; Fri, 16 Aug 1996 16:49:15 -0700
Message-Id: <199608162349.AA29179 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: Internet Monthly Report for April, 1996
Cc: imr at isi.edu, imr-ed at isi.edu
Date: Fri, 16 Aug 96 16:49:15 PDT
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
April 1996
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 at 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 at 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 at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at 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 April 1996
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 11
Registration Services . . . . . . . . . . . . . . . . . page 11
Directory and Database Services . . . . . . . . . . . . page 13
US Domain Registry. . . . . . . . . . . . . . . . . . . page 14
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 17
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 21
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 26
IMR Editor [Page 2]
Internet Monthly Report April 1996
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
----------------------------
IETF Monthly Report for April, 1996
1. At the plenary session of the Los Angeles IETF meeting, new IESG
and IAB members were announced. The current IESG memers are:
Harald T. Alvestrand Fred Baker (Chair)
Scott Bradner Jeff Burgan
Joel Halpern Frank Kastenholz
Deirdre Kostick Allison Mankin
Keith Moore Mike O'Dell
Joyce K. Reynolds Jeff Schiller
The current IAB members are:
J Allard Brian Carpenter (Chair)
Steve Bellovin Jon Crowcroft
Robert Elz Elise Gerich
Erik Huizer John Klensin
Bob Moskowitz Radia Perlman
Yakov Rekhter Chris Weider
2. The next IETF will be meeting in Montreal, Quebec, Canada from
June 24-28, 1996. If this date looks familiar, it is the same date
as INET '96! This is not a "joint" meeting per se, but both
meetings will be held in the Montreal Convention Center, and the
IETF and INET'96 will permit attendees to attend each others
sessions (assuming space is available). See the IETF or ISOC Web
Pages for more information.
Closing out the year, the IETF will be returning to San Jose,
California on December 9-13, 1996.Following that, the IETF travels
to Memphis, Tennessee where Federal Express will be the host. This
meeting will be held April 7-11, 1997.
IMR Editor [Page 3]
Internet Monthly Report April 1996
Once all the arrangements have been made, notifications will be
sent to the IETF Announcement list. Remember that information on
future IETF meetings can be always be found in the file 0mtg-
sites.txt which is located on the IETF shadow directories. This
information can also be viewed from the IETF Home Page on the Web.
The URL is:
http://www.ietf.cnri.reston.va.us
3. The minutes of the IESG teleconferences have been publicly
available on the IETF Shadow directories since 1991. These files
are placed in the /ftp/iesg directory.
The following IESG minutes have been added:
March 28, 1996 (iesg.96-03-28)
April 11, 1996 (iesg.96-04-11)
4. The IESG approved or recommended the following seven Protocol
Actions during the month of April, 1996:
o An LDAP URL Format be published as a Proposed Standard.
o A String Representation of LDAP Search Filters be published
as a Proposed Standard.
o Neighbor Discovery for IP Version 6 (IPv6) be published as
a Proposed Standard.
o IPv6 Stateless Address Autoconfiguration be published as a
Proposed Standard.
o GSS-API Authentication Method for SOCKS Version 5 be
published as a Proposed Standard.
o The Kerberos Version 5 GSS-API Mechanism be published as a
Proposed Standard.
o A DNS RR for specifying the location of services (DNS SRV)
be published as an Experimental Protocol.
5. The IESG issued 12 Last Calls to the IETF during the month of
April, 1996:
o An IPv6 Provider-Based Unicast Address Format
<draft-ietf-ipngwg-unicast-addr-fmt-04> for consideration as
a Proposed Standard.
IMR Editor [Page 4]
Internet Monthly Report April 1996
o Incremental Zone Transfer in DNS <draft-ietf-dnsind-ixfr-06>
for consideration as a Proposed Standard.
o Dynamic Updates in the Domain Name System (DNS UPDATE)
<draft-ietf-dnsind-dynDNS-09> for consideration as a Proposed
Standard.
o Serial Number Arithmetic <draft-ietf-dnsind-serial-03> for
consideration as a Proposed Standard.
o A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY) <draft-ietf-dnsind-notify-07> for consideration as
a Proposed Standard.
o SNMPv2 Management Information Base for the Internet Protocol
<draft-ietf-snmpv2-ip-ds-03> for consideration as a Proposed
Standard.
o SNMPv2 Management Information Base for the Transmission
Control Protocol <draft-ietf-snmpv2-tcp-ds-03> for
consideration as a Proposed Standard.
o SNMPv2 Management Information Base for the User Datagram
Protocol <draft-ietf-snmpv2-udp-ds-03> for consideration as
a Proposed Standard.
o MIME Security with Pretty Good Privacy (PGP)
<draft-elkins-pem-pgp-03> for consideration as a Proposed
Standard.
o PGP Message Exchange Formats <draft-atkins-pgpformat-01> for
consideration as an Informational RFC.
o INTERNET REGISTRY IP ALLOCATION GUIDELINES
<draft-hubbard-registry-guidelines-01> for consideration as
a Best Current Practices RFC.
o TCP Selective Acknowledgment Options
<draft-ietf-tcplw-sack-02> for consideration as a Proposed
Standard.
6. One working group was concluded during the month of April, 1996:
Address Autoconfiguration (addrconf)
7. A total of 95 Internet-Draft actions were taken during the month
of April, 1996:
IMR Editor [Page 5]
Internet Monthly Report April 1996
(Revised draft (o), New Draft (+) )
(iplpdn) o Management Information Base for Frame Relay DTEs
<draft-ietf-iplpdn-frmib-dte-06.txt>
(pppext) o The PPP NetBIOS Frames Control Protocol (NBFCP)
<draft-ietf-pppext-netbios-fcp-08.txt>
(cat) o The Kerberos Version 5 GSS-API Mechanism
<draft-ietf-cat-kerb5gss-07.txt>
(mobileip) o IP Mobility Support
<draft-ietf-mobileip-protocol-16.txt>
(rtfm) o Traffic Flow Measurement: Meter MIB
<draft-ietf-rtfm-acct-meter-mib-01.txt>
(snanau) o Definitions of Managed Objects for APPC
<draft-ietf-snanau-appcmib-06.txt>
(idmr) o Core Based Trees (CBT) Multicast -- Protocol
Specification <draft-ietf-idmr-cbt-spec-05.txt>
(ipngwg) o Basic Socket Interface Extensions for IPv6
<draft-ietf-ipngwg-bsd-api-05.txt>
(none) o Routing Aspects Of IPv6 Transition
<draft-ietf-ngtrans-routing-aspects-01.txt>
(ipngwg) o An IPv6 Provider-Based Unicast Address Format
<draft-ietf-ipngwg-unicast-addr-fmt-04.txt>
(none) o Mobility Support in IPv6
<draft-teraoka-ipv6-mobility-sup-03.txt>
(none) o The Photuris Session Key Management Protocol
<draft-simpson-photuris-10.txt>
(idr) + BGP communities attribute
<draft-ietf-idr-communities-00.txt>
(ipatm) o IP Broadcast over ATM Networks.
<draft-ietf-ipatm-bcast-03.txt>
(dhc) o DHCP Options and BOOTP Vendor Extensions
<draft-ietf-dhc-options-1533update-03.txt>
(entmib) o Entity MIB <draft-ietf-entmib-entmib-03.txt>
(none) o Common NNTP Extensions
<draft-barber-nntp-imp-03.txt>
(isdnmib) o ISDN Management Information Base
<draft-ietf-isdnmib-snmp-isdn-mib-06.txt>
(none) o Guidelines for IETF Meeting Sites
<draft-prior-future-host-guidelines-01.txt>
(atommib) o Definitions of Textual Conventions and
OBJECT-IDENTITIES for ATM Management
<draft-ietf-atommib-atm2TC-03.txt>
(ipatm) o IPv6 and Neighbour Discovery over ATM
<draft-ietf-ipatm-ipv6nd-02.txt>
(poised95) o The Internet Standards Process -- Revision 3 a
proposed revision of part of RFC 1602
<draft-ietf-poised95-std-proc-3-06.txt>
(grip) o Expectations for Security Incident Response
IMR Editor [Page 6]
Internet Monthly Report April 1996
<draft-ietf-grip-framework-irt-02.txt>
(isdnmib) o Dial Control Management Information Base
<draft-ietf-isdnmib-dial-control-04.txt>
(dlswmib) o Definitions of Managed Objects for Data Link
Switching using SNMPv2
<draft-ietf-dlswmib-mib-08.txt>
(rip) + Protocol Analysis for Triggered RIP
<draft-ietf-rip-trigger-analysis-00.txt>
(none) o Architectural Principles of the Internet
<draft-iab-principles-02.txt>
(none) o ISO Transport Service on top of TCP (ITOT)
<draft-pouffary-itot-02.txt>
(none) o The Private Communication Technology Protocol
<draft-benaloh-pct-01.txt>
(ipngwg) o Path MTU Discovery for IP version 6
<draft-ietf-ipngwg-pmtuv6-02.txt>
(cidrd) o INTERNET REGISTRY IP ALLOCATION GUIDELINES
<draft-hubbard-registry-guidelines-01.txt>
(poised95) o The Organizations Involved in the IETF Standards
Process <draft-ietf-poised95-ietf-orgs-01.txt>
(none) o ICMP Security Failures Messages
<draft-simpson-icmp-ipsec-fail-02.txt>
(ipngwg) o IP Version 6 over PPP
<draft-ietf-ipngwg-pppext-ipv6cp-02.txt>
(poised95) o IETF-ISOC relationship
<draft-ietf-poised95-isoc-02.txt>
(none) o RSVP Extensions for IPSEC Data Flows
<draft-berger-rsvp-ext-03.txt>
(tcplw) o TCP Selective Acknowledgment Options
<draft-ietf-tcplw-sack-02.txt>
(idr) o BGP Route Reflection An alternative to full mesh
IBGP <draft-ietf-idr-route-reflect-02.txt>
(pppext) o Layer Two Forwarding (Protocol) "L2F"
<draft-ietf-pppext-l2f-02.txt>
(none) o GZIP file format specification version 4.3
<draft-deutsch-gzip-spec-04.txt, .ps>
(none) o ZLIB Compressed Data Format Specification version
3.3 <draft-deutsch-zlib-spec-04.txt, .ps>
(none) o DEFLATE Compressed Data Format Specification version
1.3 <draft-deutsch-deflate-spec-04.txt, .ps>
(rolc) + Support for Sparse Mode PIM over ATM
<draft-ietf-rolc-pim-atm-00.txt>
(none) o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
<draft-crispin-imap-base-04.txt>
(dnsind) o Serial Number Arithmetic
<draft-ietf-dnsind-serial-03.txt>
(dhc) o Authentication for DHCP Messages
<draft-ietf-dhc-authentication-02.txt>
IMR Editor [Page 7]
Internet Monthly Report April 1996
(dhc) o An Extension to the DHCP Option Codes
<draft-ietf-dhc-options-opt127-02.txt>
(rtfm) o Traffic Flow Measurement: Architecture
<draft-ietf-rtfm-acct-arch-report-01.txt>
(dhc) o An option for FQDNs in DHCP options
<draft-ietf-dhc-fqdn-opt-01.txt>
(dnsind) o Selection of Secondary DNS Servers
<draft-ietf-dnsind-2ndry-01.txt>
(ipsec) o Combined DES-CBC, HMAC and Replay Prevention
Security Transform
<draft-ietf-ipsec-esp-des-md5-01.txt>
(none) o Server Cache Synchronization Protocol (SCSP) - NBMA
<draft-luciani-rolc-scsp-02.txt>
(http) o Proposed HTTP State Management Mechanism
<draft-ietf-http-state-mgmt-01.txt, .ps>
(atommib) o Managed Objects for Managing the Collection and
Storage of ATM Accounting Information
<draft-ietf-atommib-acct-01.txt>
(snanau) o Definitions of Managed Objects for APPN
<draft-ietf-snanau-appnmib-01.txt>
(none) o Clarification on the use of Hostnames, Mail Boxes
and Mail Domains in the DNS
<draft-andrews-dns-hostnames-02.txt>
(none) o Greek Character Encoding for Electronic Mail
Messages <draft-rfced-info-spinellis-01.txt>
(madman) + Mail and Directory Alarms
<draft-ietf-madman-alarmmib-00.txt>
(none) + The ESP Stream Transform
<draft-caronni-esp-stream-00.txt>
(none) + Authenticated Firewall Traversal with IPsec.
<draft-richardson-ipsec-aft-00.txt>
(none) + Netstrings <draft-bernstein-netstrings-00.txt>
(none) + Easily Parsed LIST Format (EPLF)
<draft-bernstein-eplf-00.txt>
(none) + Tools in the War on Mail Loops
<draft-bernstein-mail-loops-war-00.txt>
(none) + Public Information Retrieval Protocol (PIRP)
<draft-bernstein-pirp-00.txt>
(none) + Notice-Requested-Upon-Delivery-To (NRUDT)
<draft-bernstein-nrudt-00.txt>
(none) + The qmail-send Bounce Message Format (QSBMF)
<draft-bernstein-qsbmf-00.txt>
(none) + The Hash Convention For Mail System Status Codes
(HCMSSC) <draft-bernstein-hcmssc-00.txt>
(atommib) + Definitions of Managed Objects for ATM Management
<draft-ietf-atommib-atm1ng-00.txt>
(atommib) + Textual Conventions for MIB Modules Using
Performance History Based on 15 Minute Intervals
IMR Editor [Page 8]
Internet Monthly Report April 1996
<draft-ietf-atommib-perfhistTC-00.txt>
(trunkmib) o Definitions of Managed Objects for DDS Interface
Types <draft-ietf-trunkmib-dds-mib-01.txt>
(atommib) + Definitions of Managed Objects for the SONET/SDH
Interface Type <draft-ietf-atommib-sonetng-00.txt>
(none) + Distributed Dynamic Multicast Address(DDMA)
Assignment in Internet <draft-son-ddma-00.txt>
(idr) + BGP communities attribute
<draft-ietf-idr-communities-wrongcp-00.txt>
(pier) + Why consider Renumbering Now
<draft-ietf-pier-consider-00.txt>
(idmr) + Core Based Tree (CBT) Multicast Interoperability -
Stage 1 <draft-ietf-idmr-cbt-interop1-00.txt>
(none) + PPP Callback Control Protocol
<draft-gidwani-ppp-callback-cp-00.txt>
(none) + How new BGP Attribute Types are defined
<draft-manning-bgpattrib-type-00.txt>
(none) + New TLD Catagories <draft-higgs-tld-cat-00.txt>
(none) + Three-Way Handshake for IS-IS Point-to-Point
Adjacencies <draft-katz-isis-3way-00.txt>
(dhc) + Graceful renumbering of networks with DHCP
<draft-ietf-dhc-renumbering-00.txt>
(none) + Photuris Schemes and Privacy Protection
<draft-simpson-photuris-schemes-00.txt>
(mobileip) + The Definitions of Managed Objects for IP Mobility
Support <draft-ietf-mobileip-mib-00.txt>
(none) + Definitions of Managed Objects for HTTP
<draft-hazewinkel-httpmib-00.txt>
(pier) + Router Renumbering Guide <draft-ietf-pier-rr-00.txt>
(none) + Definitions of Managed Objects for an Information
Store <draft-hazewinkel-ismib-00.txt>
(none) + Definitions of Managed Objects for an Information
Retrieval Service <draft-hazewinkel-rsmib-00.txt>
(none) + Internet Security Transform Enhancements
<draft-simpson-ipsec-enhancement-00.txt>
(none) + Source directed access control on the Internet.
<draft-bradner-access-control-00.txt>
(mhtml) + MIME E-mail Encapsulation of Aggregate HTML
Documents (MHTML) <draft-ietf-mhtml-spec-00.txt>
(none) + IANA Character Set Registration Procedures
<draft-freed-charset-reg-00.txt>
(none) + Transient Neighbors for IPv6 over ATM
<draft-armitage-ipatm-tn-00.txt>
(avt) + RTP Payload Format for H.263 Video Stream
<draft-ietf-avt-rtp-payload-00.txt>
(none) + TFTP Blocksize Option
<draft-malkin-tftpexts-blksize-opt-00.txt>
(ipsec) + HMAC-MD5 IP Authentication with Replay Prevention
IMR Editor [Page 9]
Internet Monthly Report April 1996
<draft-ietf-ipsec-ah-hmac-md5-00.txt>
(ipsec) + HMAC-SHA IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-sha-00.txt>
8. There were 13 RFC's published during the month of April, 1996:
RFC St WG Title
------- -- -------- -------------------------------------
RFC1924 I (none) A Compact Representation of IPv6
Addresses
RFC1925 I (none) The Twelve Networking Truths
RFC1926 I (none) An Experimental Encapsulation of IP
Datagrams on Top of ATM
RFC1927 I (none) Suggested Additional MIME Types for
Associating Documents
RFC1928 PS (aft) SOCKS Protocol Version 5
RFC1929 PS (aft) Username/Password Authentication for
SOCKS V5
RFC1930 BCP (idr) Guidelines for creation, selection, and
registration of an Autonomous System (AS)
RFC1931 I (none) Dynamic RARP Extensions and
Administrative Support for Automatic
Network Address Allocation
RFC1932 I (ipatm) IP over ATM: A Framework Document
RFC1933 PS (ngtrans) Transition Mechanisms for IPv6 Hosts and
Routers
RFC1934 I (none) Ascend's Multilink Protocol Plus (MP+)
RFC1935 I (none) What is the Internet, Anyway?
RFC1936 I (none) Implementing the Internet Checksum in
Hardware
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( B) Best Current Practice
( E) Experimental
( I) Informational
Steve Coya <scoya at cnri.reston.va.us>
IMR Editor [Page 10]
Internet Monthly Report April 1996
INTERNET PROJECTS
-----------------
INTERNIC
--------
REGISTRATION SERVICES
InterNIC Registration Services
Monthly Letter Progress Report
Cooperative Agreement NCR-9218742
June 3, 1996
Progress Report for April 1, 1966 through April 31, 1996
I. Significant Events
During April 1996, InterNIC Registration Services assigned the
following network addresses, and registered domain names to include
top-level country domains:
Assigned Registered Country
Domain(s)
Network Addresses 16,781,886 *
Domain Names Registered 45,102
Top-level Country Domain(s) 4 CF - Central
African
Republic
NE - Niger
MF - Mauritanie
OM - Oman
* Note: Allocated for reassignment from the RIPE Registry.
The voice mail ports were installed and the new telephone script
was implemented allowing callers to select the section from which
support is needed. Received digital telephones to accommodate the
anticipated operations needs after 15-day final invoices are sent
out.
work on the transfer of responsibilities for IP allocation from
Canada to the InterNIC is continuing.
The draft IP Allocation document (RFC 1466) was released as a Best
Current Practice (BCP) and should become official within a few
weeks.
IMR Editor [Page 11]
Internet Monthly Report April 1996
Draft versions of contact and domain registration templates were
prepared and are under evaluation.
CSR Guardian training began in April in preparation for Guardian
implementation. Finalized Guardian schema. Guardian features are
being added to the hstreg (host registration) application.
Finished coding and successfully tested the domreg application for
Guardian.
Missed report processing was completed for February; backlog should
be eliminated in May.
Work continues on Domain editor tool. The InterNIC Template
Generator tool was changed to be compatible with version 3.0 of the
domain registration template; it will now generate a 3.0 template.
Hostmaster backlog was completely eliminated.
Generation of new domain name invoices continues. The backlog was
reduced to one week.
The invoice generator for renewal invoices is ready. The process of
sending out 60-day renewal notices was initiated.
Development of "payment uploader" is in progress (for transferring
payment information from the Access database into the main
database).
Installed Sparc center 2000, installed Ingres. Configuration of
Sun Ultra is in progress. Rolled out additional Sparc 20s for
information service machines.
All information and database files for the rs machine were ported
to the Auspex 150 NSF server. The tracking system files were
successfully transferred to the Auspex 650 NSF server.
Continued work with Patrick Crispin to allow InterNIC hosting of
the ROADMAP Internet training series.
Tom Newell attended the Coalition for Networked Information
conference on March 25-26.
Revised and implemented InterNIC Registration Services Home Page.
During April, new domain requests continued to range between 1,000
and 2,000+ per day. Updates ranged from 400 to 800+ a day.
Applications that do not need human review are processed within a
day. Approximately 50% are handled in this manner. The remaining
IMR Editor [Page 12]
Internet Monthly Report April 1996
applications and questions enter a queue for resolution by one of
the processing staff. This queue is currently a week and a half
long.
II. Current Status
E-mail 109,778 (hostmaster at internic.net)
Postal/Fax 772 (primarily Domreg requests)
Phone 22,878
Connections Retrievals
Gopher 34,166 67,180
WAIS 113,216 49,940
FTP 94,241 203,854
Mailserv 3,992
Telnet 166,097
Http 4,398,014
In addition, for WHOIS the number of queries were:
Client Server
_______ _________
693,016 10,101,977
Debbie Fuller <Debbief at internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
In February, we started porting our production servers to Solaris.
The port of one backup server (ds1.internic.net) was started in
February and completed in early March. The port of our primary
server (ds0.internic.net) was started in late March and completed
in early April. During April, we also completed the conversion of
our third server, so our production servers are all running
Solaris.
As noted previously, testing and rebuilds of databases mean that
each machine was down for an extended period when it is converted.
The other two servers support all of our user applications, so
service was always available during the conversion process.
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories. If you prefer, you can enter information
IMR Editor [Page 13]
Internet Monthly Report April 1996
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
Rick Huber <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
A new policy has been added to the criteria for delegating domain
names under the US Domain:
It is the intention that the delegation of third level (for
example, locality) domain names be wide spread to many
registries. It is undesirable for one person or organization to
manage a large part of the third level names in any particular
geographic or logical area.
No individual or organization shall have more than 500
delegations total in the US Domain as a whole, or more than 50
delegation in any particuilar second level (for example, a
state).
Some of the processing of requests to the US Domain administrator
is now automated. In particular, most requests to register names
in localities already delegated are automatically forwarded to the
administrator for that locality.
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).
To obtain a copy of the list of other delegated localities and
subdomains not administered by the US Domain Registrar, get the
file "us-domain-delegated.txt".
URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt
For further information about the US Domain, send a message to:
US-DOMAIN at ISI.EDU, or see our WEB page:
http://www.isi.edu/us-domain
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 1830
IMR Editor [Page 14]
Internet Monthly Report April 1996
PHONE 500
----------------------------
Total Contacts 2330
DELEGATIONS 54
FORWARDED DELEGATIONS: 420
OTHER US DOMAIN MSGS: 1856
---------------------------
Total 2330
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.
In addition, and not listed below, another 55 localities have been
delegated in New Jersey, New York, Indiana, Iowa and Pennsylvania
this month.
MAJOR SUBDOMAINS DELEGATED
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
51 35 33 47 38 23 23 9 3
===================================================================
----------------------------------
THIRD LEVEL DELEGATIONS THIS MONTH
----------------------------------
COG.MI.US Council of Governments, Michigan
LOCALITIES
==========
MADISON.TN.US JACKSON.TN.US
HUMBOLDT.TN.US GIBSON.TN.US
MAYFLOWER.AR.US VILONIA.AR.US
GREENBRIER.AR.US ROGERS.AR.US
EARLHAM.IA.US MUCKLESHOOT.NSN.US
BATAVIA.IL.US APPLETON.WI.US
GREEN-BAY.WI.US OSHKOSH.WI.US
SUCCASUNNA.NJ.US HOPATCONG.NJ.US
IMR Editor [Page 15]
Internet Monthly Report April 1996
LEBEC.CA.US HOLLY-SPRINGS.NC.US
HALIFAX.NC.US SAN-DIEGO.CA.US
CONWAY.AR.US LOUISVILLE.KY.US
LEXINGTON.KY.US EDGEWOOD.WA.US
CHESAPEAKE-BEACH.MD.US SPRINGFIELD.VA.US
ALBANY.OH.US MONTGOMERY.MD.US
GLENSIDE.PA.US ENFIELD.NH.US
GUTTENBERG.NJ.US ELLISVILLE.MO.US
GLENDALE.CA.US WESTCLIFFE.CO.US
EAST-PROVIDENCE.RI.US ALLEGEN.MI.US
MARTIN.FL.US ALEXANDRIA.VA.US
LONG-BEACH.MS.US GULFPORT.MS.US
PASS-CHRISTIAN.MS.US WARMINSTER.PA.US
SOUTHAMPTON.PA.US BRISTOL.PA.US
LEVITTOWN.PA.US HEBER-CITY.PA.US
CTSI.NSN.US ANNADALE.VA.US
LA.CA.US BEVERLY-HILLS.CA.US
HOLLYWOOD.CA.US VENICE.CA.US
OTHER US DOMAIN DELEGATIONS THIS MONTH
--------------------------------------
CI.INDEPENDENCE.MO.US CO.BROWN.NE.US
SPOKANE.CC.WA.US CI.SAN-MARINO.CA.US
CI.ORINDA.CA.US WWW.TORRANCE.CA.US
ROSEVILLE.PROB.FED.US TOWNHALL.CI.WEYMOUTH.MA.US
ADMIN.CO.FAYETTE.GA.US GR.CC.WA.US
LAKEFRONT.STERLING.VA.US CI.GENEVA.NE.US
CI.SMYRNA.GA.US VIL.OAK-BROOK.IL.US
METRO.DST.OR.US TOWN.PROVINCETOWN.MA.US
TOWN.SANDWICH.MA.US TOWN.WELLFLEET.MA.US
TOWN.YARMOUTH.MA.US TOWN.TRURO.MA.US
TOWN.ORLEANS.MA.US TOWN.MASHPEE.MA.US
TOWN.HARWICH.MA.US TOWN.EASTHAM.MA.US
TOWN.FALMOUTH.MA.US TOWN.DENNIS.MA.US
TOWN.CHATHAM.MA.US TOWN.BARNSTABLE.MA.US
TOWN.BREWSTER.MA.US TOWN.BOURNE.MA.US
CI.BUENA-PARK.CA.US CO.CLEVELAND.NC.US
JUNEAU.LIB.AK.US CI.DONIPHAN.NE.US
CASA.GEN.MI.US EPISCOPAL-HS.JAX.FL.US
CO.YORK.VA.US FPC.LEXINGTON.MA.US
CI.LA-MESA.CA.US CI.YORK.NE.US
CHANG.ARLINGTON.TX.US TIC.STEAMBOAT-SPRINGS.CO.US
CI.RICHMOND.IL.US CI.WILMINGTON.DE.US
NEWHORIZONS.MOBILE.AL.US MARC.PA.BATON-ROUGE.LA.US
CI.KENT.WA.US IGUANA.KANSAS-CITY.MO.US
CI.CLEBURNE.TX.US TAROT.SALEM.MA.US
IMR Editor [Page 16]
Internet Monthly Report April 1996
WICCA.SALEM.MA.US OCCCULT.SALEM.MA.US
PELLITIER.LEOMINSTER.MA.US KOSKI.LEOMINSTER.MA.US
KING.LEOMINSTER.MA.US CI.SIOUX-CITY.IA.US
WCICC.SIOUX-CITY.IA.US CO.WOODBURY.IA.US
SCHROTH.MARTINSBURG.WV.US GSDC.STATESVILLE.NC.US
CI.WEST-BEND.WI.US SJC.CC.OK.US
HEALTH.CO.ONIEDA.NY.US CI.VALENTINE.NE.US
CI.STAUNTON.VA.US CI.IMPERIAL-BEACH.CA.US
SACRAMENTO.COURT.FED.US YOSEMITE.COURT.FED.US
FRESNO.COURT.FED.US BOROUGH.MEDIA.PA.US
CHAMBER.GRAYS-HARBOR.WA.US CYBERCITY.GEN.CA.US
CI.EMERYVILLE.CA.US CHAMINADE.CHATSWORTH.CA.US
KOREA.EMB.WASHINGTON.DC.US SWEDEN.EMB.NW.DC.US
WILLIAMS.WASHINGTON.DC.US CI.EAST-POINT.GA.US
MIAMI-POLICE.CI.MIAMI.FL.US CITY.LONG-BEACH.WA.US
ARL.BOSTON.MA.US
-----------------------------------------------------------
URL: http://www.isi.edu/us-domain/
Ann Cooper & Shanthi Ranganathan (US-Domain at ISI.EDU)
MERIT INTERNET ENGINEERING - March
----------------------------------
This report summarizes March 1996 activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service and
other projects.
Several new organizations are now relying on the Routing Arbiter
project's Route Servers for peering at the NAPs. At the
Washington, D.C. NAP (MAE-East), Delphi uses the Route Servers as
its primary source of routing information for ESnet, PIPEX, DRA
Net, Capital Area Internet Service (CAIS), IConNet, Netcom, and
Hyperspace, and is actively migrating as many other peerings as
possible to use the RSs.
Tools developed by the Routing Arbiter are now being used along
with the Internet Routing Registry (IRR) to configure
RGnet/RAINet's production Cisco routers. Alan Barrett of
PIPEX/IAfrica and Randy Bush of RGnet provided valuable feedback on
RA services at the March meeting of the IETF Routing Policy System
(RPS) Working Group; their suggestions prompted the Routing Arbiter
to make immediate changes in the software to improve its usability.
The RPS Working Group, chaired by Cengiz Alaettinoglu of the RA and
IMR Editor [Page 17]
Internet Monthly Report April 1996
Daniel Karrenberg of the RIPE NCC, is defining the next-generation
language in which users of the Routing Arbiter Database (RADB) will
specify the information held in the database, the mechanism by
which information in the RADB will be distributed to other sites,
and standard tools which will analyze information in the RADB. The
Routing Arbiter would like to thank Barrett, Bush, and other
members of the Internet community who have provided extremely
useful feedback on RA services.
Using many of the suggestions and comments from recent IEPG and
NANOG meetings, Craig Labovitz has compiled several new Internet
routing statistics Web pages. See:
http://www.ra.net/statistics/
These pages include real-time graphs of network instability, bar
charts of the sources of routing instability, snapshots of the
Route Servers' routing tables, graphs of long-term trends, and
reports of invalid routing reports and IRR discrepancies.
In improving the quality and accuracy of these reports, Merit needs
the help of Internet Service Providers. The reports are only as
accurate as the raw data the Route Servers receive in peering
sessions. If you are not peering with the Route Servers, we
encourage you to do so. Your routes will ONLY be used for
statistics collection purposes (unless you have explicitly
registered policy in the IRR and indicated that the RA should
propagate the routes.) To peer with the Route Servers, send mail to
rs-peer at ra.net.
The Routing Arbiter wishes to thank the following organizations for
providing routes for statistics collection and analysis: ANS,
Advantis, Aimnet, alpha dot net, Alternet, Argonne, CAIS, CERFnet,
CWInet, DIGEX, DRA Net, the Defense Research Engineering Network,
DXnet, Delphi, ESnet, Insnet, IOSnet, IConNet, Interpath, MCI,
Nacamar Data Communications, NAP.NET, Net Access, Netcom, Netrail,
PIPEX, SURAnet, Supernet, The Planet, The Well, and US Cyber.
The Resource Allocation Committee has funded development of Merit's
Network Statistics Collection and Reporting software package. The
goal of the one-year project, managed by Bill Norton, is to develop
a Web interface that ISPs and other organizations can use to
collect and display network performance statistics for their
portion of the Internet.
Sue Hares, Gerald Winters, Craig Labovitz, Elise Gerich, Dun Liu,
and Bill Norton attended the 35th IETF in Los Angeles. Norton,
Gerich, and Liu met with Vern Paxson of Lawrence Berkeley National
IMR Editor [Page 18]
Internet Monthly Report April 1996
Laboratory and Jamshid Mahdavi of the Pittsburgh Supercomputing
Center to discuss Paxson's previous research on network
performance, and to plan for the comparable collection and analysis
of data for 1996. Gerich also participated in several meetings of
the Internet Architecture Board.
The final report for the NSFNET project, titled "NSFNET: A
Partnership for High-Speed Networking," is now available on the
Merit Web pages. See:
http://www.merit.edu/nsfnet/final.report
Susan R. Harris (srh at merit.edu)
MERIT INTERNET ENGINEERING - April
----------------------------------
This report summarizes April 1996 activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service and
other projects.
A new Merit graphical tool, called ASExplorer, makes it possible to
explore the real-time AS routing topology and instability of the
Internet. The tool generates hourly maps of current NAP stability
levels, based on the dynamic routing information collected by Route
Servers at the Network Access Points. Users select a NAP, click on
an AS peering with the Route Servers, and follow color-coded links
to display successive layers of neighbor ASs. The thicker the line
linking a Route Server and AS, the greater the number of BGP
updates, and the greater the instability of routing information at
the NAP. Clicking on an AS also displays InterNIC contact
information for that Autonomous System. ASExplorer, which was
developed by Craig Labovitz, requires a frames-capable browser such
as Netscape 2.0. See:
http://www.ra.net/tools/asexplorer/
Brian Renaud, Xin Liu, and Jerry Winters of the Routing Arbiter
Database support team have been working with RADB maintainers--end
users authorized to modify database records--to remove more than
4,000 duplicated Route objects from the database. The project is
part of a long-term Merit effort to identify, correct, and remove
inaccurate or obsolete records from the RADB. To initiate the
project, the team sent e-mail messages to more than 800 maintainers
listing Route objects duplicated in another Internet Routing
Registry (IRR) database or covered by a shorter (less specific)
aggregate Route object in the RADB. The staff offered to delete
the duplicated records on behalf of the maintainer, or send the
IMR Editor [Page 19]
Internet Monthly Report April 1996
maintainers the duplicated route objects fully prepared for
deletion, so they could review the deletions and send in the
transactions themselves. Depending on the response, the team then
worked on a case-by-case basis to update or delete the Route
objects. The process involved updating maintainer information,
working with multi-homed ISPs to find appropriate solutions,
providing tutorials on the RADB and IRR, and finding ways to ensure
consistency among IRR registries. The 4,000 deleted objects
represented roughly ten percent of those registered in the
database.
Users can display current information about RADB route duplication
and coverage for any AS on the Routing Arbiter Web pages:
http://www.ra.net/cgi-bin/ra/radb-duplicates.pl
Merit has received a continuation of funding for its IDRP project,
which is managed by the MITRE Corporation. Merit's development
effort for the GateD-IDRP implementation is led by Sue Hares. In
this phase of the project, Hares and other Merit staff will
implement IDRP QOS support for multiple FIBs and priority queuing
for multiple types of network reachability information.
Jerry Winters attended the 24th RIPE meeting in Berlin, where he
presented updates on ASExplorer, the RADB, and RAWhoisd.
Susan R. Harris (srh at merit.edu)
UCL
----
THe main UCL workitem in the last period of Merci sponsored work
has been the release of SDR 2.2a9 for platforms including SunOS
Solaris, HPUX, OSF/1, Linux and Win95. This incorporates the
Session Invitiation Protocol, which allows active setup of
conferences between participants as well as the "tune in" classic
session directory style of conference coordination.
The Robust-Audio Tool has also undergone further releases.
We have also started playing with RSVP (the ISI release and Cisco's
beta release). This is in an environment that includes an ATM
infrastructure between routers.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
IMR Editor [Page 20]
Internet Monthly Report April 1996
CALENDAR
--------
Last update 07/9/96
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:
<meeting-planning at ietf.org>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
FYI - The EMail World & Internet World originally scheduled for
Sept. 10-12, 1996 has been moved to Oct. 15-17, 1996. Boston, MA.
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.8)
cd ietf
ls *0mtg*
Gopher
------
Available on the Gopher Server running on IETF.CNRI.RESTON.VA.US
(132.151.1.35) under "Internet Engineering Task Force (IETF) / IETF
Meetings / Scheduling Calendar".
WWW
---
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link
for "meetings" and you should find an entry "listing of other Internet
related events".
************************************************************************
1996
IMR Editor [Page 21]
Internet Monthly Report April 1996
----
Aug. 12-16 12th Europ. Conf. on AI (ECAI) Budapest, Hungary
Aug. 14-15 Web Developer '96 Dallas, TX
Aug. 18-21 Object World West San Jose, CA
Aug. 19-23 ATM Forum Baltimore, MD
Aug. 20-22 Int. World Australia Pacific Sydney, Australia
Aug. 21 Commercenet Pittsburgh, PA
Aug. 25-28 8th IEEE Workshop on
Local & Metro. Area Networks Berlin, Germany
Aug. 26-30 SIGCOMM '96 Stanford, CA
Aug. 27-30 Object World Australia Sydney, Australia
FALL NSC'96 - Network Services Conf. Bled, Slovenia
Sep. 2-5 22nd Euromicro Conference Prague, Czech
Sep. 2-6 14th IFIP Conf. Canberra, AU
Sep. 3-5 iTV96 Interactive Television 1996
at the University of Edinburgh Scotland, UK
Sep. 3-5 TINA '96 Heidelberg, Germany
Sep. 6-7 ITS European Regional Wkshop Vienna, Austria
Sep. 9-13 ANSI X3T10 '96 Digital Natick, MA
Sep. 9-13 OIW (Firm)
Sep. 16-20 NetWorld+Interop Atlanta, GA
Sep. 16-20 OMG TC (Software 2000) Hyannis, MA
Sep. 16-20 Web Developer Canada '96 Vancouver, Canada
Sep. 17-19 IEEE 802.10 Interim meeting Washington, DC
Sep. 18 Commercenet Santa Clara, CA
Sep. 23-26 Internet World Philippines '96 Manila, Philippines
Sep. 24-27 IFIP WG6.1 w/FORTE/PSTV (Under Consideration)
Sep. 25-27 Internet World Philippines '96 Manila, Philippines
Sep. 25-27 3rd Int'l Workshop on Mobile
Multimedia Communication Princeton, NJ
Sep. 29-Oct 4 10th USENIX Syst. Admin
Conference (LISA '96) Chicago, IL
Oct. 1-3 Email World & Internet Expo Toronto, Ontario, CA
Oct. 2-4 Object World Tokyo Tokyo, Japan
Oct. 6-9 Asia Pacific Distributed
Solutions Event Queensland, Australia
Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL
Oct. 7-11 ATM Forum Montreux, Switzerland
Oct. 7-11 NetWorld+Interop Paris, France
Oct. 7-11 Performance 96 Conference Lausanne, Switzerland
Oct. 9-11 Object World Frankfurt Frankfurt, Germany
Oct. 13-16 IEEE Local Computer Ntwrks (LCN) Minneapolis, MN
Oct. 14-17 MEDNET '96 European Congress
of the Internet in Medicine Brighton, UK
Oct. 15 Commercenet New Orleans, LA
Oct. 15-17 EMail World & Internet Expo Boston, MA
Oct. 15-18 3rd Int'l on Protocols for
IMR Editor [Page 22]
Internet Monthly Report April 1996
Multimedia Systems Madrid, Spain
Oct. 16-18 Internet World Monterrey '96 Monterrey, Mexico
Oct. 16-19 5th Int'l Conference on
Computer Communications & Ntwrks Rockville, MD
Oct. 17-20 IEEE Symposium on Planning & Design
of Broadband Networks Quebec, Canada
Oct. 21-25 ICECCS'96 (held jointly with
6th CSESAW, 4th IEEE RTAW) Montreal, Canada
Oct. 28-31 2nd USENIX Seattle, WA
Oct. 28-Nov. 1 NetWorld+Interop London, England
Oct. 29-31 Internet Professional '96 Paris, France
Oct. 29-Nov. 1 ICNP-96 Int'l Conf. on
Network Protocols Columbus, Ohio
Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys.
Design & Implement. (OSIDI II) Seattle, WA
Nov. 1996 OMG TC (Groupe Bull) Nice, France
Nov. 4-7 APPN Implementers Workshop Raleigh, NC
Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA
Nov. 6-8 Web Developer Mexico '96 Mexico Ciy, Mexico
Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York
Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada
Nov. 12-15 3rd Int'l Conf.
on Multimedia Modeling Toulouse, France
Nov. 13 Commercenet Santa Clara, CA
Nov. 18-20 2nd USENIX Workshop on
Electronic Commerce Oakland, CA
Nov. 18-22 ACM Multimedia '96 Boston, MA
Nov. 18-22 IEEE Globecom 96 London, England
Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA
Nov. 20-21 IEEE Global Internet '96 London, UK
Nov. 25-29 NetWorld+Interop Sydney, Australia
Dec. 2-4 Web World San Diego, CA
Dec. 2-6 ANSI X3T11 Rochester, MN
Dec. 2-6 ATM Forum Vancover, BC
Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA
Dec. 9-12 Internet World '96 Baltimore, MD
Dec. 9-13 37th IETF San Jose, CA
Dec. 9-13 OIW (Firm)
Dec. 10-13 Fall Internet World '96 New York, NY
Dec. 12 Internet Security for System
& Network Administrators Pittsburgh, PA
Dec. 13 Commercenet Albuquerque, NM
1997
-----------
Jan. 6-10 ANSI X3T10 '97
Jan. 6-10 USENIX '97
Annual Technical Conf. Anaheim, CA
IMR Editor [Page 23]
Internet Monthly Report April 1996
Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA
Jan. 7-10 13th Annual Hawaii Int'l Conf
on Systems Sciences Maui, Hawaii
Jan. 7-10 Internet World Canada '97 Toronto, Canada
Jan. 21-23 Internet World Shanghai-China Shanghai, China
Jan. 21-25 Internet World Singapore Intl Singapore
Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL
Feb. 3-7 ANSI X3T11 TBA
Feb. 10-11 ISOC Symposium on Network and
Distributed System Security San Diego, CA
Feb. 17-19 Internet Expo & EMail World San Jose, CA
Mar. 1-5 ACM '97: The Next 50 yrs. of Computing
San Jose, CA
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque
Mar. 11-14 Spring Internet World '97 Los Angeles, CA
Mar. 11-15 ANSI X3T10 '97
Mar. 17-19 1st Euromicro Working Conf. on
Software Maintenance & Reengineering
Berlin, Germany
Mar. 19-21 Internet World Asia '97 Kuala Lumpur, Malaysia
Apr. 7-11 38th IETF Memphis, TN
Apr. 7-11 ANSI X3T11 TBA
Apr. 7-11 IEEE Infocom '97 Kobe, Japan
Apr. 9-11 ISADS 97 - 3rd Intl Symposium on
Autonmous Decentralized Sys. Berlin, Germany
Apr. 22-24 Internet Expo & EMail World Chicago, IL
May 5-9 ANSI X3T10 '97
May 12-16 IFIP/IEEE San Diego, CA
May 28-30 Web Developer '97 Chicago, IL
Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico
Jun. 8-12 ICC '97 Montreal
Jun. 9-13 OIW (Firm)
Jun. 9-13 ANSI X3T11 TBA
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 14-18 ANSI X3T10 '97
Aug. 11-15 ANSI X3T11 TBA
Aug. 11-15 (tenative) 39th IETF Munich, Germany
Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland
Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France
Oct. 6-10 ANSI X3T11 TBA
Nov. 3-7 ANSI X3T10 '97
Dec. 8-12 OIW (Firm)
TELECOM '97 Asia (Venue and Dates to be Determined)
IMR Editor [Page 24]
Internet Monthly Report April 1996
1998
-----------
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
1999
-----
Oct. 8-14 TELECOM '99 Geneva, Switzerland
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IMR Editor [Page 25]
Internet Monthly Report April 1996
TERENA List of Meetings
=======================
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact the
chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail <secretariat at terena.nl>.
MEETING/DATE LOCATION
============ ========
TERENA General Assembly
-----------------------
GA6
24-25 October Bled
GA7
15-16 May 1997 Edinburgh
TERENA Executive Committee
--------------------------
10 September Amsterdam
TERENA Technical Committee
--------------------------
23 September Brussels
TERENA Working Groups
---------------------
TF-TEN
29-30 August Stuttgart
PHARE Research Networking
25 October Bled
CEEnet
26 October Bled
INSIGHT Workshop
28-29 October Bled
TERENA Office Meeting
---------------------
IMR Editor [Page 26]
Internet Monthly Report April 1996
22 August Amsterdam
-----------------------------------------------------------------
EBONE
-----
ECCO (Ebone Consortium of Contributing Organisations)
23 September Copenhagen
EEMA
----
Moscow Conference
26-27 September Moscow
Regional Conference
29 November - 1 December Malta
EWOS
----
TA34, 17-18 September Brussels
TA35, 3-4 December "
TA36, 25-26 February 1997 "
TA37, 13-14 May 1997 "
TA38, 16-17 September 1997 "
TA39, 2-3 December 1997 "
SC - 24 September "
SC - 17 December "
Workshops
35: 21-25 October Brussels
36: 20-24 January 1997 "
37: 7-11 April 1997 "
38: 16-20 June 1997 "
39: 27-31 October 1997 "
ETSI
----
Seminar/Workshop
1-3 October Nice, France
GA24 10-11 December Nice, France
TA25 23-25 October "
IETF
IMR Editor [Page 27]
Internet Monthly Report April 1996
----
9-13 December San Jose, CA
7-11 April 1997 Memphis, Tenn.
11-15 August 1997 Munich, Germany
RIPE-NCC Contributor's Committee
--------------------------------
Annual Meeting
11 September Amsterdam
RIPE
----
RIPE23
23-25 September Amsterdam
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
------------------
Call for Papers
JENC8 - 8th Joint European Networking Conference
------------------------------------------------
"Diversity and Integration: The New European Networking Landscape"
12-15 May 1997
Edinburgh, Scotland
This conference will be the European Forum to get up-to-date
information, to debate and assess the new deregulated tele-
communication environment in Europe, new leading-edge applications,
and the network/internetwork support infrastructure which is
currently being developed
Subject Areas:
* Emerging Network Technologies and Network Engineering
* User Support, Training and Education
* Security and Management Issues
* Information Systems and Distributed Applications
* Economic and Political Issues
--Deadline for paper submission 10 November 1996--
IMR Editor [Page 28]
Internet Monthly Report April 1996
For all information please contact the JENC8 Secretariat at:
TERENA Secretariat
Singel 466-468
1017 AW Amsterdam, The Netherlands
tel: +31 20 6391131 fax: +31 20 6393289
email: <jenc8-sec at terena.nl>
http://www.terena.nl/jenc8
or
JENC8 Local Organization
c/o Concorde Services Ltd
Unit 5, SECC
Glasgow, G3 8YW, Scotland
email: <jenc8 at ed.ac.uk>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The NSC'96 (Network Services Conference 1996)
scheduled for 22 - 24 October has been CANCELLED
until further notice
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OTHER CONFERENCES
-----------------
TINA'96:
-------
The Convergence of Telecommunications and Distributed
Computing Technologies
3-5 September
The Stadthall, Heidelberg, Germany
The emphasis of the conference will be on experimental results
and experience with real systems, although theoretical contributions
of clear practical importance will also be considered.
Deadline paper submission 1 March 1996 to <TINA96 at eurescom.de>
BAR-IT'96 (Barents Region)
2nd International Conference on Information Technology
------------------------------------------------------
16-18 September
IMR Editor [Page 29]
Internet Monthly Report April 1996
Apatity (Murmansk Region) Russia
The conference will focus on the development and efficient application
of information and communication technology in the Barents Region.
See WWW page: http://www.sn.no/~gunnark/barit96
International Congress and Technical Exhibition
"Water: Ecology and Technology"
-----------------------------------------------
17-21 September
Moscow, Russia
Organized by: Russian Federal Committee for Water Management,
Russian Federal Ministry of Construction, Ministry of Environment
and Natural Resources Protection, Municipal Enterprise "Mosvodokanal",
State Enterprise "Vodokanal St. Petersburg",Stock Company "SIBICO
International".
For all further information, contact:
<postmaster at sibico.MSK.RU>
telephone/telefax: +7 095 207 63 60
2nd International Conference on Satellite Communications (ISCS'96)
------------------------------------------------------------------
23-27 September
Moscow, Russia
The conference will explore the theme "Satellites for Global
Communications" with representives from government, international
organizations, industry, research institutes and universities - for
discussions on recent advances and future trends of development and
applications of satellite communications.
For further information please email: <enir at icsti.su> or
tel: +7 095 198 7691
fax: +7 095 943 0089
MoMuC-3
3rd International Workshop on Mobile Multimedia Communications
--------------------------------------------------------------
25-27 September
Hyatt Regency Hotel, Princetown, New Jersey, USA
Aimed at stimulating technical exchange in the emerging and
strategically important field of mobile multimedia communications.
For information contact email <MoMuC3 at ccrl.nj.nec.com
The Future of Biotechnologies in Europe
---------------------------------------
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
