Citing I-Ds (was Re: Draft RFCs)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Citing I-Ds (was Re: Draft RFCs)
- To: jhawk at panix.com (John Hawkinson)
- Subject: Citing I-Ds (was Re: Draft RFCs)
- Date: Thu, 22 Dec 1994 11:42:55 +0000 (GMT)
- In-reply-to: <199412211946.AA11188@panix.com> from "John Hawkinson" at Dec 21, 94 02:46:45 pm
- Reply-to: P.Furniss at uk.ac.ulcc
Since the subject has come up
> Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other
> documents at any time. It is inappropriate to use Internet-
> Drafts as reference material or to cite them other than as
> ``work in progress.''
I have seen this interpreted as meaning the name of the I-D should not
be given in (paper) published articles that refer to current IETF
work. This seems distinctly unhelpful, especially where cooperation
with other groups is desired.
Can it be agreed that a reference to an I-D by a document (of any
kind) can give the (current) file name, but should make clear the
ephemeral status ? (For example "These concepts are described in the
Internet-Draft "draft-ietf-nosuchgroup-ihope-01.txt", which is a
working document of the IETF nosuchgroup working group and will be
revised or replaced in the future") I would not think it was necessary
to give the summary of the IETF practices in every such reference.
Peter Furniss
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01409;
22 Dec 94 6:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01403;
22 Dec 94 6:57 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03256;
22 Dec 94 6:57 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01394;
22 Dec 94 6:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01357;
22 Dec 94 6:56 EST
Received: from panix.com by CNRI.Reston.VA.US id aa03232; 22 Dec 94 6:56 EST
Received: by panix.com id AA27474
(5.67b/IDA-1.5 for ietf at CNRI.Reston.VA.US); Thu, 22 Dec 1994 06:56:22 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Hawkinson <jhawk at panix.com>
Message-Id: <199412221156.AA27474 at panix.com>
Subject: Re: Draft RFCs
To: beatrice dominguez-meiers <polbdm at unm.edu>
Date: Thu, 22 Dec 1994 06:56:22 -0500 (EST)
Cc: sunil at prospero.dev.cdx.mot.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <Pine.3.89.9412211652.D59052-0100000 at pegasus.unm.edu> from "beatrice dominguez-meiers" at Dec 21, 94 04:23:27 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4419
> From: beatrice dominguez-meiers <polbdm at unm.edu>
> To: John Hawkinson <jhawk at panix.com>
> Cc: Sunil Menon <sunil at prospero.dev.cdx.mot.com>, ietf at CNRI.Reston.VA.US
> use Archie to search for the file named rfx xxxx.txt. Once you have
> found an Anonymous FTP host that has this file, FTP to the host and
> download the file.
> If you would like to download an index of all the RFCs, use Archie to
> search for a file named rfc-index.txt
This is, in general, a poor idea. Archie is a useful tool for locating
files when you don't know the location, but it is not always helpful
when trying to locate documents and files which tend to change. This
is particularly annoying when one is trying to find the current
version of a package. The correct solution is to look in a known
canonical location.
Since rfc-index.txt tends to change, archie is a less-than-desirable
tool for finding it. Additionally, the query was about finding
DRAFT Request For Comments, *not* regular RFCs.
Regardless, current RFCs (and current copies of rfc-index.txt)
are available from the ``Primary Repositories'':
RFCs can be obtained via FTP from DS.INTERNIC.NET, NIS.NSF.NET,
NISC.JVNC.NET, FTP.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or FTP.SESQUI.NET.
and also the attached ``Secondary Repositories''. Please use
the one closest to you, topologically speaking.
--
John Hawkinson
jhawk at panix.com
Sweden
------
Host: sunic.sunet.se
Directory: rfc
Host: chalmers.se
Directory: rfc
Germany
-------
Site: EUnet Germany
Host: ftp.Germany.EU.net
Directory: pub/documents/rfc
France
------
Site: Institut National de la Recherche en Informatique
et Automatique (INRIA)
Address: info-server at inria.fr
Notes: RFCs are available via email to the above
address. Info Server manager is Mireille
Yamajako (yamajako at inria.fr).
Netherlands
-----------
Site: EUnet
Host: mcsun.eu.net
Directory: rfc
Notes: RFCs in compressed format.
France
------
Site: Centre d'Informatique Scientifique et Medicale
(CISM)
Contact: ftpmaint at univ-lyon1.fr
Host: ftp.univ-lyon1.fr
Directories: pub/rfc/* Classified by hundreds
pub/mirrors/rfc Mirror of Internic
Notes: Files compressed with gzip. Online
decompression done by the FTP server.
Finland
-------
Site: FUNET
Host: funet.fi
Directory: rfc
Notes: RFCs in compressed format. Also provides
email access by sending mail to
archive-server at funet.fi.
Norway
------
Host: ugle.unit.no
Directory: pub/rfc
Denmark
-------
Site: University of Copenhagen
Host: ftp.denet.dk
Directory: rfc
Australia and Pacific Rim
-------------------------
Site: munnari
Contact: Robert Elz <kre at cs.mu.OZ.AU>
Host: munnari.oz.au
Directory: rfc
rfc's in compressed format rfcNNNN.Z
postscript rfc's rfcNNNN.ps.Z
United States
-------------
Site: cerfnet
Contact: help at cerf.net
Host: nic.cerf.net
Directory: netinfo/rfc
Site: NASA NAIC
Contact: rfc-updates at naic.nasa.gov
Host: naic.nasa.gov
Directory: files/rfc
Site: NIC.DDN.MIL (DOD users only)
Contact: NIC at nic.ddn.mil
Host: NIC.DDN.MIL
Directory: rfc/rfcnnnn.txt
Note: DOD users only may obtain RFC's via FTP
from NIC.DDN.MIL. Internet users should NOT
use this source due to inadequate connectivity.
Site: uunet
Contact: James Revell <revell at uunet.uu.net>
Host: ftp.uu.net
Directory: inet/rfc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01681;
22 Dec 94 7:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01675;
22 Dec 94 7:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03688;
22 Dec 94 7:26 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01666;
22 Dec 94 7:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01636;
22 Dec 94 7:24 EST
Received: from relay.tis.com by CNRI.Reston.VA.US id aa03643; 22 Dec 94 7:24 EST
Received: from cybercash.com(192.94.214.95) by relay via smap (V1.3)
id sma022374; Thu Dec 22 07:24:47 1994
Received: from [192.94.214.93] (ogata.tis.com) by cybercash.com. (4.1/SMI-4.1)
id AA00959; Thu, 22 Dec 94 07:26:17 EST
Message-Id: <ab1f1e100a02100442ad at [192.94.214.93]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Dec 1994 07:24:48 -0500
To: P.Furniss at ulcc.ac.uk, ietf <ietf at CNRI.Reston.VA.US>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Crocker <crocker at cybercash.com>
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
Peter, et al.,
The caveat attached to Internet Drafts is they're ephemeral and will not
exist indefinitely. Anyone is free to do whatever he wants in preparing
other documents. Editors who have standards about the quality of citations
are properly advised that I-Ds are not archival documents. They are thus
usually inappropriate to cite in other archival documents, e.g. journals
and RFCs. On the other hand, if you're preparing a report which is
intended to be relevant for only a short period of time, e.g. "Status of
the current work on the ihope protocol" and want to cite the work of the
nonesuch working group, there shouldn't be any reason for complaint if you
include the filename of the relevant I-D.
Steve
At 6:44 AM 12/22/94, Peter Furniss wrote:
>> Internet-Drafts are draft documents valid for a maximum of six
>> months and may be updated, replaced, or obsoleted by other
>> documents at any time. It is inappropriate to use Internet-
>> Drafts as reference material or to cite them other than as
>> ``work in progress.''
>
>I have seen this interpreted as meaning the name of the I-D should not
>be given in (paper) published articles that refer to current IETF
>work. This seems distinctly unhelpful, especially where cooperation
>with other groups is desired.
>
>Can it be agreed that a reference to an I-D by a document (of any
>kind) can give the (current) file name, but should make clear the
>ephemeral status ? (For example "These concepts are described in the
>Internet-Draft "draft-ietf-nosuchgroup-ihope-01.txt", which is a
>working document of the IETF nosuchgroup working group and will be
>revised or replaced in the future") I would not think it was necessary
>to give the summary of the IETF practices in every such reference.
>
>Peter Furniss
--------------------
Steve Crocker
CyberCash, Inc. Work: +1 703 620 1222
2086 Hunters Crest Way Fax: +1 703 391 2651
Vienna, VA 22181 crocker at cybercash.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02047;
22 Dec 94 8:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02041;
22 Dec 94 8:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04614;
22 Dec 94 8:28 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02032;
22 Dec 94 8:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02009;
22 Dec 94 8:27 EST
Received: from boa.te.rl.ac.uk by CNRI.Reston.VA.US id aa04566;
22 Dec 94 8:26 EST
Received: from adder.te.rl.ac.uk by boa.te.rl.ac.uk with SMTP
(1.38.193.4/HP16.2-ACU2.00) id AA04149;
Thu, 22 Dec 1994 13:22:43 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "D.J.Horgan" <David.Horgan at acu.rl.ac.uk>
Received: by adder.te.rl.ac.uk
(1.37.109.4/ACU-1.2) id AA10562; Thu, 22 Dec 94 13:31:36 GMT
Message-Id: <9412221331.AA10562 at adder.te.rl.ac.uk>
Subject: Re: J'Accuse, ATM
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Date: Thu, 22 Dec 94 13:31:36 GMT
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <607.788091076 at cs.ucl.ac.uk>; from "Jon Crowcroft" at Dec 22, 94 10:11 am
Mailer: Elm [revision: 70.85]
>
>
> There are two schools of thought on ATM
> 1/ its a muxing technique for the phone companies
> 2/ its a replacement for IP
>
> To address the latter (despite some people's protestations)
> a large number of available, affordable ATM switches are being landed
> in research labs so people develop technology to use this end to end
> native mode as the nervous system tendons and muscles of the
> information superhighway
>
> However, this technology has not been slected on the basis of
> good, fair and proper evaluation. In fact, when talking to anyone
> who has tried using it for computer-computer communciations, I have
> yet to find someone who has positive things to say. It is alarming
> that all the books and papers and money that are being fired at this
> approach are so uncritical - in the research commuity, I have only
> seen one notable paper in the last two years (last edition of ToN)
> that questions the approachj/architecture.
>
> And yet at demonstrations in the RACE and other European research
> programs, and in the gigabit programs in the US, behind the scenes,
> under their breath, and so on, people are saying how painful this
> technology is.
>
> Now one excuse made by proponents is that this is new technology.
> I'm sorry, but it isn't. Its virtual circuit, packet seitching, mainly
> around 100-100 Mbps. That is something that given IP and X.25
> experience is simply what one would expect from silico and fiber and a
> few changes in constraining packet header fields (e.g. in IP, TCP window
> scaling, or in X.25, increasing the HDLC and level 3 packet size and
> window size and sequence numebr space).
>
> All (and I mean all) the excitement of the Internet is with the mbone,
> WWW and at a lower layer, IP6. Yet can _anyone_ run equivalents to
> any of these applciations over a significant size piece of ATM (sorry,
> B-ISDN) infrastructure?
>
> So another excuse I might here is "logistics and deployment
> time/problems". I'm sorry, we've been trying very hard to deploy WAN
> ATM to interconnect LAN ATM for some time. it doesn't support mixed
> CBR and ABR traffic as well as IP does right now (or as well as
> reasonable priced frame relay or even lower layer multiplexors) - its
> entire raison d'etre does not cover the case that all the labs are
> tying to address [ pace, telcos, i still agree it may have its place
> in the trunk network... maybe, altrhough the third largest telco
> in the world expressed their dobuts privately several tiems to us about
> whether they could use ATM for voice or data....why add kit to a SDH
> trunk voice network that works fine, and will only be 5% of their
> busniess 10 years hence?]/
>
> Techical reasons cited for 'selecting ATM' include
> 1/ fixed small size makes for cheap fast switches
> 2/ VCs rather than datagram mean you can do resource reservation and
> security properly
> 3/ the small cell size means you can do fine grain interleaving of
> different traffic classes and therefore guarantee low latency to some
> classes (e.g. 64kbps voice) while still supporting others...
>
> 1 is demonstrably true, yet peopel can build equally fast switches for
> fixed header size, variable data size packets - they're called IP
> routers - they can even run cut through, so the latency you require
> from 3 is achievable.
> 2 - VCs are an anathema to efficient many-to-many communication (steve
> deering says this often, but has yet to be pursuadad to write this
> down - sorry if i don't get the argument right, steve).
> You want to send lots of streams, and you want to receive lots of
> streams. With VCs, you get to have to keep O(n**2) PCBs. With
> datagrams you get O(n). nbow you might think that a PCB is simple. but
> with ATM, because of the fixed small size cell, you get to have to
> keep O(n**2) reassembly buffer descriptors - since its trying to go
> fast, you have to supprort this in the ATM adator hardware other wise
> the host takes a per cell interrupt - since these descriptors are
> quite complex (slightly more for isntance than a lance dma buffer ring
> descriptor) your hardware gets to cost a lot - we abandonesd this with the
> cambridge ring in 1982...bad news!
> 3 the cell size debate: designed to suite the RTT of a national phone
> net with some modest number of switches and a line speed of 64kbps, so
> that a voice call could be a2d coverrted at source and sink traverse
> the path twice and the cell store and forward/switching times, and
> stil be inside the time tolerable for hearing ones own voice while
> speaking: sorry, this doesn't work unless your switches have
> synchonous cut thru (ie.e are really cell based SDH cross connects) -
> otherwise, line speed mismatches mean that traffic from all sources is
> subject to queueing delays (its _a_synchronous transfer mode) and at
> best, you get to be 1 bit out of phase with all n-1 other flows of the
> same traffic class - this means that the queing time is based on the
> dimension of the flows in the net, not the geography and topology of
> switches. So the 32/64/48 byte payload fiasco is bogus au fond.
>
> Finally, on the technical front: signaling, addressing and routing
> (what in IP is achieved by
> sending a packet, and if you need special treatment, will be done by
> the reciever thru RSVP):-) - well, shame there isn't much right now
> isn't it? but when there is, what will have been the cost to develop a
> new VC (cell non-reordering) distriuted adaptive routing famework,
> when we already have one for IP?
>
> There is a lot more I could say, and some of it in defense of ATM
> (:-), but time doesn't permit.
>
> However, why am i writing this? well, the effort and pressure being
> put on us to develop solutions to problems bought about by this
> selection are enourmous. yet why am i unpleasantly reminded of what we
> used to have to do with X.25 for WANs in the late 70s/early 80s?
>
> Why should we have to put up with this? the "industry" is always
> reported as working on ATM, being excited by it, developing solutions
> etc....well, we are the industry now, and i don;t spot may of us doing
> our busniess that way....
>
> If the ATM forum put out their plenary sessions on the "Abone", then
> perhaps I would be less negative about this (i know thats unfair, they
> havn't got the infrastructure yet.....yet....yet.....still
> waiting?)?
>
> There are a lot of smart people working on ATM, and i hate writing
> this. but there were a lot of smart people working at Los Alamos on
> the bomb..... and, less dramatically, a lot of smart people worked on
> X.235 ,and in its day, that at least was operational and still is in
> not un0-significant size networks....and underwent the sme kind of
> trial by use that we in the Internet Community used to feel was mandatory
> before "selecting" some piece of technology
>
> Anyhow, seasons greetings and a happy new year to all and sundry
>
> jon
>
> ATM: Just Say No.
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02204;
22 Dec 94 8:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02200;
22 Dec 94 8:46 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05149;
22 Dec 94 8:46 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <HAA06919 at pad-thai.cam.ov.com>; Thu, 22 Dec 1994 07:57:25 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA27755; Thu, 22 Dec 94 07:54:58 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <HAA06915 at pad-thai.cam.ov.com>; Thu, 22 Dec 1994 07:57:22 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA05402; Thu, 22 Dec 94 07:57:20 EST
Message-Id: <9412221257.AA05402 at winkl.cam.ov.com>
To: minutes at CNRI.Reston.VA.US, cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Minutes for San Jose CAT meetings
Date: Thu, 22 Dec 1994 07:57:19 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
SUMMARY
The Common Authentication Technology (CAT) WG met for two sessions at
the San Jose IETF. We progressed through a busy agenda, including the
following areas: Kerberos One-Time Passwords Internet-Draft and
issues; updated Simple Public-Key Mechanisms Internet-Draft and
issues; Internet-Draft update to RFC-1508 and issues; status of
Windows GSS-API bindings; Independent Object Protection (IOP)
Internet-Draft for extensions to GSS-API and issues; issues affecting
the update to the FTP security Internet-Draft for its advancement to
Proposed Standard; discussion re multiple overlay proposals for
interfaces to layer atop GSS-API. Revised Internet-Drafts are
expected for many of these documents in advance of the Danvers IETF;
in particular, a revised FTP security Internet-Draft will be targeted
for submission to become a Proposed Standard; depending on
implementation results, a version of the SPKM Internet-Draft may also
be submitted for advancement.
KERBEROS V5 ONE-TIME PASSWORDS
Following agenda discussion, Glen Zorn (CyberSAFE) presented
discussion about the Kerberos V5 one-time passwords Internet-Draft
(draft-ietf-cat-kerberos-passwords-00.txt) which he had co-authored
with Cliff Neuman (ISI). The proposal's goal is to support a range of
one-time password schemes through use of the Kerberos V5
preauthentication data (padata) field. The draft considers two cases
of one-time password integration, one of which is more secure and
easier to support, but is unable to accomodate as broad a range of
one-time password technologies. In the less secure, more complex, but
more general case, the server is assumed to know passcode values in
advance; for the higher security case, the server is not assumed to
know passcode values in advance.
Ted Ts'o (MIT) observed that the weaker form presumes that peers know
the salting value a priori and can perform computations with it; as an
alternative, he suggested that the salt value be provided dynamically
in a krb_error message. Charlie Kaufman (Iris) noted that Security
Dynamics had indicated potential willingness to opening up the
structure of their interfaces in order to support operation in the
stronger mode. The group agreed that both classes should be supported.
It was also believed that more than the 5 passcode type values
currently defined in the draft are needed. In detailed discussion,
Bill Sommerfeld (HP) commented that a redirect facility should be
available to designate a server address. It was also recognized that
the proposal contains no explicit internationalization facilities
(e.g., to tag a desired language for user prompt messages).
Cliff Neuman expressed a desire to move forward quickly on revision of
this specification to another Internet-Draft, and then to advance the
result to Proposed Standard status. Cliff asserted that client
support for the defined passcode types should be mandatory, though
server support would be optional (and often dependent on availability
of proprietary vendor code). In response to a query about
availability of one-time password code in the MIT Kerberos
distribution, Glen Zorn indicated that CyberSAFE would be willing to
contribute requisite client-side code, and possibly a server-side
S/Key implementation. Piers McMahon (ICL) noted that it would be
useful to define a common API for use on the server side; Ted Ts'o
observed that maintaining modular structure within the KDC was
important. Cliff also commented that additional work was underway on
public-key preauthentication, but that it wasn't yet sufficiently
complete or stable to be considered for standardization. Further
review of the Internet-Draft and comment on the WG mailing list was
solicited.
SPKM
Paul Van Oorschot (BNR) presented an update on the Simple Public-Key
Mechanism (SPKM) proposal, documented in draft-ietf-cat-spkmgss-01.txt
and for which Paul gave primary technical credit to Carlisle Adams of
BNR. SPKM incorporates digital signature facilities (see also IOP
extension proposal, discussed elsewhere in these minutes) as well as
base GSS-API services, and can operate in a mode which imposes no
requirement for shared secure time. Algorithm IDs provide
extensibility, and negotiation facilities are provided for selection
of alternate algorithms for confidentiality, integrity, and key
establishment within SPKM. QOP values are used to select among different
integrity levels, including a level which provides non-repudiation.
Changes between the original and current SPKM Internet-Drafts
were summarized. Token formats include syntax changes for alignment
with Project SESAME. The distinctions between SPKM-1 (random-number
based, with 2-step one-way authentication of target to initiator,
or 3-step mutual authentication) and SPKM-2 (timestamp-based, with
one-step one-way authentication of initiator to target or 2-step
mutual authentication) operational modes were clarified. OIDs were
changed to Algorithm IDs in order to carry parameters; all tokens
are now encoded in ASN.1 BER. Context negotiation
within the mechanism now negotiates the key establishment mechanism.
SPKM now specifies certificate_data as optional, and allows a source
name in a request token as an alternative. The SPKM-REQ now has
an optional authorization data field (as in Kerberos V5), and an optional
validity period specifier for the context's key. Two new integrity
algorithms were added: one which provides single-pass integrity and
encryption for data and another based on an encrypted MD5 hash.
Some additional minor status values were defined for SPKM.
Error handling is enhanced by including a sequence number to identify
the token within which a processing error occurred. Some discussion
ensued about whether error-reporting tokens were themselves signed
objects; signatures are applied but (given the fact that the
signatures won't necessarily be verifiable under all failure
conditions), their reports are assumed to be accepted whether or not
the signature check succeeds. It was observed that this can make
implementations vulnerable to disruption through receipt of gratuitous
and/or spurious error tokens. Further clarification on error token
generation and processing is expected before the next IETF meeting.
Several SPKM implementation activities are proceeding. BNR is
approaching completion (before the end of 1994) of an implementation
including some proprietary facilities and performance optimizations.
SESAME is building an implementation of SPKM-2, which is to be
publicly available. The University of New Brunswick is developing a
public reference SPKM implementation, and additional activity may be
underway in Australia. Ted Ts'o suggested that SPKM developers
attempt to use the GSS-API sample application as available in the MIT
Kerberos V5 distribution as a test vehicle to exercise SPKM and to
validate portability. Interoperability testing is planned between now
and February 1995, with results to be reported to the CAT list;
depending on progress, SPKM may be recommended for advancement to
Proposed Standard at, or before, the Danvers IETF meeting.
GSS-API BINDINGS FOR MICROSOFT WINDOWS
Piers McMahon reported on the status of Windows bindings for GSS-API,
which had been the topic of prior mailing list discussion and proposal
by Piers. Like RFC-1509, Piers' draft presumes that GSS-API functions
operate in a synchronous and potentially blocking mode; the prospect
of an alternative asynchronous interface was also agreed to be useful,
but would be a separate effort; Shawn Mamros (FTP) indicated possible
interest in such an activity. Ted Ts'o noted that MIT will be engaging
a developer to build a Kerberos V5 DLL based on Piers' draft. A
version of the draft document as discussed in E-mail, reflecting
revisions based on comments received, will be sent to Internet-Drafts
shortly.
GSS-API OVERLAY PROPOSALS
Multiple proposals have been made on alternate interfaces to layer
atop GSS-API, providing protected communications sessions, including
(at least) Ted Ts'o's CATS, work (by Lam) at the University of Texas
at Austin, and an E-mail proposal made by P. Rajaram. Don Stephenson
(Sun) was familiar with the UT/Austin work, and may be able to make
its code and/or a descriptive USENIX paper available on-line. We
collected an informal subgroup (Don Stephenson, John Myers (CMU), Glen
Zorn, Ed Reed (Novell), and Ted Ts'o) to work on a consolidated
proposal to become an Internet-Draft, drawing on these inputs.
GSS-V2: CHANGES MADE IN I-D
A number of changes, included in draft-ietf-cat-gssv2-00.txt, were
summarized. These changes are specific and incremental, derived
from implementation experience and liaison requests and making only
minor modifications to the functional model established in V1, and
their inclusion is not perceived as necessitating reset of GSS-API's
standards status to Proposed Standard rather than progressing to
Draft Standard.
Changed GSS_ prefix for major_status values to GSS_S_.
Added GSS_S_GAP_TOKEN major status to be returned by GSS_VerifyMIC()
and GSS_Unwrap() to indicate receipt of a message following skipped
predecessor sequenced messages. Rewording in Section 1.2.3 on
sequencing indicators.
Added new GSS_S_BAD_QOP major status.
Added description of GSS_S_BAD_MECH return status for
GSS_Init_sec_context() and GSS_Accept_sec_context().
Added non-textual name import and export routines, as proposed in the
Kerberos V5 Internet-Draft. Renamed GSS_Import_internal_name() to
GSS_Import_name_object() and GSS_Export_internal_name() to
GSS_Export_name_object() to avoid terminology confusion; the phrase
"internal name" is already used to represent the opaque form as
supported within a GSS-API implementation, and the input to
GSS_Import_name_object is an object tagged externally to GSS-API.
Added GSS_Inquire_context().
Deprecated GSS_Sign, GSS_Seal, GSS_Verify, GSS_Unseal routine names in
favor of successors GSS_GetMIC, GSS_Wrap, GSS_VerifyMIC, GSS_Unwrap.
(After some discussion, we resisted the temptation to revisit the
function naming question again.)
Added new GSS_Wrap_size_limit() routine to determine how large an
input token can be provided to GSS_Wrap() without generating an output
token larger than a caller-specified size.
Rewrote description of channel bindings (Sec. 1.1.6) for purposes of
clarification.
In routine descriptions, changed types of credential and context handle
arguments to CREDENTIAL HANDLE and CONTEXT HANDLE, respectively.
GSS-V2: ISSUES PENDING AND DISCUSSED
This section summarizes topics pending against GSS-V2 and their
intended disposition. Further discussion is required to ascertain
working group consensus about whether the scope of intended actions on
these topics warrants resetting GSS-V2's standards status to Proposed
Standard rather than proceeding to Draft status.
Level, if any, to include extension routines for OID and OID set
management: John Linn to send message to list, comparing Wray and
Glatting proposals; subsequent resolution to be sought on list.
GSS_Add_cred() proposal. Accepted for addition.
ASN.1 syntax for Appendix B, conformantly permitting non-ASN.1 enclosed
objects. No information available.
Definition of reserved QOP values to distinguish NO, WEAK, MEDIUM,
STRONG levels in a mechanism-independent matter (with mapping to
algorithm choices to be mechanism-specified), and to distinguish
integrity QOP from confidentiality QOP. Accepted for addition.
Additional values designating FAST, SLOW, and (for integrity)
NON_REPUDIABLE were suggested and also accepted.
GSS_Delete_sec_context() to be documented as returning a token only if
caller requests same by passing a non-NULL buffer to accept it; usage
with NULL token and, therefore, without transfer of deletion token to
be recommended.
GSS_Process_context_token() changes to distinguish whether or not
context remains valid; action: not adopted.
Facilities to enable binary compatibility: believed to require only
changes to RFC-1509 (concrete typing of 4 objects), as documented in
E-mail from John Wray. Action: Review Wray proposal and assume that
it holds, unless list discussion revisits the issue.
Ability for GSS_VerifyMIC() and GSS_Unwrap() to return, in addition to
current fatal errors on receipt of unsequenced messages, new advisory
codes to report the same conditions. Action: Intend to support. John
Linn and Marc Horowitz (OpenVision) to codify proposal to the list.
GSS_Open(), GSS_Close() proposal (added calls to obviate need for
constructing self-initializing implementations of other GSS-API
routines). Ted Ts'o observed that the strongest portability rules, as
he has seen applied in other developments, require that neither static
nor global variables be used; conformance to this standard would imply
that each GSS-API routine would need to incorporate an added parameter
for a caller-provided state block, a pervasive change which the group
was not prepared to adopt at this time. The semantics of GSS_Open()
and GSS_Close() in terms of objects which could be allocated and freed
(with and without maintenance of reference counts) received some
debate; resources (e.g., replay caches) potentially sharable across
multiple callers were a particular discussion point. Action:
discussion remanded to list.
Dual-use (INITIATE and ACCEPT) credentials, within which expiration
times and other parameters may differ for directions of use, and
extensions (e.g., by new parameter to GSS_Inquire_cred() or new
GSS_Inquire_cred_specific() routine in order to preserve
GSS_Inquire_cred()'s call signature intact: there was disagreement (as
yet unresolved) about what, if any, changes are needed in this area.
Action: more discussion needed.
FTP SECURITY
Sam Sjogren (TGV) led discussion of FTP security, beginning at the end
of the first CAT session and finishing at the beginning of the second
session. Relatively few of the session's attendees indicated detailed
familiarity with the FTP security draft. During the second session,
Steve Lunt (J.P. Morgan), author of the current Internet-Draft
(draft-ietf-cat-ftpsec-05.txt) joined the discussion via speakerphone.
Sam Sjogren and Marc Horowitz intend to handle the next set of
revisions to the Internet-Draft, between January 1995 and the next
IETF meeting, with the result targeted for recommendation by the
working group to Jeff Schiller as Security Area Director for
advancement to Proposed Standard. Marc Horowitz noted that the current
draft emphasizes client-side behavior and should be enhanced to
include more detailed discussion of server-side cases and behavior as
well; he has implemented client-side and server-side FTP security code
layered atop GSS-API and can contribute to clarifying this discussion.
Proposal: Add a new reply code to support OT passwords; the apparent
sense of the group was that this was a useful and valid facility,
without adverse impact on existing clients and enabling new
security-aware clients to accomplish more intelligent behavior.
An issue was discussed about the relation between AUTH and USER
commands: is it acceptable to perform AUTH more than once
(renegotiating) to create a new security context within an FTP
session? A window of vulnerability can be constrained by refusing to
act on commands which are received outside secure mode. Proposal: a
new AUTH will tear down any existing security context and try to
initiate a new one; Ted Ts'o notes that this doesn't work in all cases
(e.g., chroot, where you wouldn't be able to go back to prior
identity) or on all system types. Marc Horowitz notes that current
FTP implementations refuse to accept a new USER command on an existing
session; analogously, it would be possible for implementations to
reject a new AUTH command once a context is in place. An
implementation note on behavior seems important here.
Question: Should MIC be required on all commands once security
initiated? Diffie-Hellman and one-time password mechanisms can't
accomodate this, for example. Marc believes that it shouldn't be
required (if so negotiated, in a tamperproof fashion). Proposal
accepted; a server need not require use of MIC'd commands.
Use of more verbose error codes was proposed and accepted.
Multiline reply format (Jeff Schiller issue): Jeff suggested dropping
1:1 correspondence between number of input vs. protected lines,
encoding multiline object as an object. Noted that multiline replies,
unlike file data, aren't generally massive. It was proposed that each
line should be represented as a separate GSS-API token, but discussion
here was not conclusive.
INDEPENDENT OBJECT PROTECTION (IOP)
Paul Van Oorschot proposed GSS-API extensions for use in a
store-and-forward environment, per a recent Internet-Draft
(draft-ietf-cat-iopgss-00.txt) authored by Carlisle Adams of BNR. Its
motivations include the need to protect important applications (e.g.,
E-mail) which aren't session-based, to protect independent message
objects, and to operate independently of on-line communication with
target. The IOP proposal permits a context, and an object protected
in conjunction with that context, to be addressed to and processable
by multiple recipients. By intent, IOP contexts impose no expiration
times. For the case of mechanisms capable of supporting both base
GSS-API and IOP functions, the ability to use common credentials for
both classes of operations is a valuable facility.
The IOP proposal's security context construct contrasts with that in
the base GSS-API: rather than being shared on-line with a peer,
independent contexts at initiator and target allow creation and remote
recovery of a key. It was suggested that, in order to reduce
confusion, another term rather than "context" be used to describe the
IOP construct. Ted Ts'o and Marc Horowitz expressed elements of an
alternate view: that at least some of IOP's goals might be satisfiable
within the conventional GSS-API, given a mechanism within which
context establishment could be accomplished with exactly one context
establishment token from initiator to target, and suitable technology
supporting the existing GSS-API per-message calls. An updated draft is
expected to include renaming of the IOP context construct and to
clarify IOP context expiration semantics.
The IOP proposal leaves GSS-API's credential functions unchanged, and
adds new IOP_Init_context(), IOP_Accept_context(), and
IOP_Delete_context() for management of IOP contexts. New per-object
calls IOP_Protect(), IOP_Unprotect() are provided; each operation is
subdivided into "start", "operate", and "end operate" calls, emitting
a prot_token at the start of processing and an optional receipt_token;
common routines provide functions analogous to both GSS_Wrap() and
GSS_GetMIC(). Continuation facilities seem more important for
protection of potentially-large documents than for the
session-oriented paradigm in which the base GSS-API operates. Each
operation yields a buffer (e.g., of encrypted text), not a token; this
aspect of the proposal was controversial. Issues around segmentation
of buffer data at peers, and requirements on crypto-algorithm
quantization, arise here: tokenizing would help here and will be
explored. One new support call, IOP_Extract_Prot_Token(), is added in
the proposal. Clarification on buffers and their management is
expected in an updated draft.
BNR is implementing the IOP proposal, but this implementation is not
planned to become public domain; the availability of the specification
is intended to encourage independent evaluation and implementation
activities.
ACTION ITEMS PENDING
Check on availability of documents on Stephenson and Rajaram's
mechanism negotiation work; also on electronic availability of paper
and, possibly, code from UT/Austin re session-oriented overlay
for GSS-API. (Don Stephenson)
Send summary message re "Service:"; name prefix issue (Ted Ts'o,
to be supported by others with memory of the issue).
STATUS OF ACTIVE CAT DOCUMENTS AND ADVANCEMENT PLANS
GSS-V2: To be revised I-D before Danvers meeting (John Linn). To plan
for advancement from Proposed to Draft standard level, we need a statement
proposing how the IETF's independent implementation requirements for
advancement to Draft, defined and commonly used for protocols, should
be applied for this case of an interface specification; John Linn will
draft such a statement. Piers McMahon commented that X/Open has relevant
experience in interface validation and is now planning test procedures
and suites to validate conformance with GSS-V1.
FTP Security: To be revised I-D early 1995, before Danvers meeting,
with result targeted for advancement to Proposed Standard (Sam
Sjogren, Marc Horowitz, Steve Lunt).
SPKM: Implementation experience pending at BNR and University of
New Brunswick (the latter to be freely available reference implementation),
possibly also at SESAME; experience to be summarized to list in advance
of advancing current or revised Internet-Draft to Proposed Standard, possibly
before Danvers meeting. (Paul Van Oorschot, for Carlisle Adams)
IOP: I-D to be revised (Paul Van Oorschot, for Carlisle Adams).
Kerberos One-Time Passwords: I-D probably to be revised (Glen Zorn,
Cliff Neuman).
Kerberos V5 GSS-API mechanism: slight I-D revision pending (John Linn).
Windows GSS-API bindings: to be released as I-D (Piers McMahon).
RFC-1509: I-D update needed to track 1508 changes, binary portability,
and other pending issues (John Wray: John Linn to contact re scope and
status of planned RFC-1509 revisions.).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02274;
22 Dec 94 8:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02264;
22 Dec 94 8:51 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05233;
22 Dec 94 8:51 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02253;
22 Dec 94 8:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02225;
22 Dec 94 8:50 EST
Received: from boa.te.rl.ac.uk by CNRI.Reston.VA.US id aa05179;
22 Dec 94 8:49 EST
Received: from adder.te.rl.ac.uk by boa.te.rl.ac.uk with SMTP
(1.38.193.4/HP16.2-ACU2.00) id AA04164;
Thu, 22 Dec 1994 13:46:17 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "D.J.Horgan" <David.Horgan at acu.rl.ac.uk>
Received: by adder.te.rl.ac.uk
(1.37.109.4/ACU-1.2) id AA10592; Thu, 22 Dec 94 13:55:09 GMT
Message-Id: <9412221355.AA10592 at adder.te.rl.ac.uk>
Subject: re: J'Accuse, ATM -proper response
To: ietf at CNRI.Reston.VA.US
Date: Thu, 22 Dec 94 13:55:08 GMT
Cc: David.Horgan at boa.te.rl.ac.uk
Mailer: Elm [revision: 70.85]
Jon,
I feel that you have been a little selective and biased in your assessment
of ATM, and its applicabilty in present and future networks. Ignoring
multimedia and real time, time sensitive communications such as video and
voice is probably a bit of an oversight!
>Jon Crowcroft writes:
>
> There are two schools of thought on ATM
> 1/ its a muxing technique for the phone companies
> 2/ its a replacement for IP
>
......
I am under the impression that it is both a multiplexing technique for the
PTTs ie in the Wide Area, and can be a replacement for IP for certain
applications, particularly multimedia communications which are predicted
to be the preferred comms type of the near future, according to a huge range
of people from right across the spectra of both communities.
>
> However, this technology has not been slected on the basis of
> good, fair and proper evaluation. In fact, when talking to anyone
> who has tried using it for computer-computer communciations, I have
> yet to find someone who has positive things to say. It is alarming
> that all the books and papers and money that are being fired at this
> approach are so uncritical - in the research commuity, I have only
> seen one notable paper in the last two years (last edition of ToN)
> that questions the approachj/architecture.
>
re Selection: surely you must develop technology first before you can make
rational "selection" decisions about it and its alternatives. So aren't
all the RACE research and gigabit programs in the US a first part in this
selection procedure? - a sort of a speculative gamble that this is the
technology of the future and a means of becoming experienced with it early.
> And yet at demonstrations in the RACE and other European research
> programs, and in the gigabit programs in the US, behind the scenes,
> under their breath, and so on, people are saying how painful this
> technology is.
>
No gain without pain (in the short term at least).
> Now one excuse made by proponents is that this is new technology.
> I'm sorry, but it isn't. Its virtual circuit, packet seitching, mainly
> around 100-100 Mbps. That is something that given IP and X.25
> experience is simply what one would expect from silico and fiber and a
> few changes in constraining packet header fields (e.g. in IP, TCP window
> scaling, or in X.25, increasing the HDLC and level 3 packet size and
> window size and sequence numebr space).
>
> All (and I mean all) the excitement of the Internet is with the mbone,
> WWW and at a lower layer, IP6. Yet can _anyone_ run equivalents to
> any of these applciations over a significant size piece of ATM (sorry,
> B-ISDN) infrastructure?
>
Very exciting: this kind of argument could have been used to limit computers
to adding and subtracting in the 50's, knowing that typewriters produce
documents and TVs take care of image! What about real time multimedia
applications over the wide area? - these developments you talk of are only
the tip of the iceberg, give me video on demand, real time surveilance,
fast MM comms for home working, remote consultation, entertainment, education
etc etc! How can I do this in a scalable integrated network without ATM???
> So another excuse I might here is "logistics and deployment
> time/problems". I'm sorry, we've been trying very hard to deploy WAN
> ATM to interconnect LAN ATM for some time. it doesn't support mixed
> CBR and ABR traffic as well as IP does right now (or as well as
> reasonable priced frame relay or even lower layer multiplexors) - its
> entire raison d'etre does not cover the case that all the labs are
> tying to address [ pace, telcos, i still agree it may have its place
> in the trunk network... maybe, altrhough the third largest telco
> in the world expressed their dobuts privately several tiems to us about
> whether they could use ATM for voice or data....why add kit to a SDH
> trunk voice network that works fine, and will only be 5% of their
> busniess 10 years hence?]/
>
I don't think its been tried and developed enough yet- I think you are being
premature here.
> Techical reasons cited for 'selecting ATM' include
> 1/ fixed small size makes for cheap fast switches
> 2/ VCs rather than datagram mean you can do resource reservation and
> security properly
> 3/ the small cell size means you can do fine grain interleaving of
> different traffic classes and therefore guarantee low latency to some
> classes (e.g. 64kbps voice) while still supporting others...
>
> 1 is demonstrably true, yet peopel can build equally fast switches for
> fixed header size, variable data size packets - they're called IP
> routers - they can even run cut through, so the latency you require
> from 3 is achievable.
> 2 - VCs are an anathema to efficient many-to-many communication (steve
> deering says this often, but has yet to be pursuadad to write this
> down - sorry if i don't get the argument right, steve).
> You want to send lots of streams, and you want to receive lots of
> streams. With VCs, you get to have to keep O(n**2) PCBs. With
> datagrams you get O(n). nbow you might think that a PCB is simple. but
> with ATM, because of the fixed small size cell, you get to have to
> keep O(n**2) reassembly buffer descriptors - since its trying to go
> fast, you have to supprort this in the ATM adator hardware other wise
> the host takes a per cell interrupt - since these descriptors are
> quite complex (slightly more for isntance than a lance dma buffer ring
> descriptor) your hardware gets to cost a lot - we abandonesd this with the
> cambridge ring in 1982...bad news!
> 3 the cell size debate: designed to suite the RTT of a national phone
> net with some modest number of switches and a line speed of 64kbps, so
> that a voice call could be a2d coverrted at source and sink traverse
> the path twice and the cell store and forward/switching times, and
> stil be inside the time tolerable for hearing ones own voice while
> speaking: sorry, this doesn't work unless your switches have
> synchonous cut thru (ie.e are really cell based SDH cross connects) -
> otherwise, line speed mismatches mean that traffic from all sources is
> subject to queueing delays (its _a_synchronous transfer mode) and at
> best, you get to be 1 bit out of phase with all n-1 other flows of the
> same traffic class - this means that the queing time is based on the
> dimension of the flows in the net, not the geography and topology of
> switches. So the 32/64/48 byte payload fiasco is bogus au fond.
>
> Finally, on the technical front: signaling, addressing and routing
> (what in IP is achieved by
> sending a packet, and if you need special treatment, will be done by
> the reciever thru RSVP):-) - well, shame there isn't much right now
> isn't it? but when there is, what will have been the cost to develop a
> new VC (cell non-reordering) distriuted adaptive routing famework,
> when we already have one for IP?
IP is GREAT: no doubt about it, but ATM is far better suited to real time
applications (whats the ratio of traffic today between real time (time
sensitive) traffic such as voice, (cable TV) and non time sensitive traffic
such as internet, fax, etc - around ten to one you'll find, so no guessing
which technologies have greater clout. I
......>
> There is a lot more I could say, and some of it in defense of ATM
> (:-), but time doesn't permit.
>
I hope I have mentioned some of what you did not have time for ;).
> Anyhow, seasons greetings and a happy new year to all and sundry
>
> jon
Many happy returns,
David Horgan.
>
> ATM: Just Say No.
>
ATM: Just Say Maybe.
p.s perhaps even Probably.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03448;
22 Dec 94 10:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03442;
22 Dec 94 10:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06960;
22 Dec 94 10:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab03431;
22 Dec 94 10:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03384;
22 Dec 94 10:05 EST
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa06910;
22 Dec 94 10:05 EST
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7661;
Thu, 22 Dec 94 10:05:05 EST
Date: Thu, 22 Dec 94 10:03:22 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: yakov at watson.ibm.com
To: David.Horgan at acu.rl.ac.uk
cc: ietf at CNRI.Reston.VA.US
Subject: J'Accuse, ATM -proper response
Message-ID: <9412221005.aa06910 at CNRI.Reston.VA.US>
Ref: Your note of Thu, 22 Dec 94 13:55:08 GMT
David,
>What about real time multimedia applications over the wide area ? - these
>developments you talk of are only the tip of the iceberg, give me video
>on demand, real time surveilance, fast MM comms for home working, remote
>consuting, entertainment, education etc etc! How can I do this in a
>scalable intergrated network without ATM ???
Would you consider TCP/IP augmented with multicast and resource
reservation capabilities as a possible alternative ?
>IP is GREAT: no doubt about it, but ATM is far better suited to real
>time application.
Why ATM is far better suited for such application than TCP/IP augmented
with multicast and resource reservation capabilities ?
Yakov Rekhter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04124;
22 Dec 94 10:36 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04118;
22 Dec 94 10:36 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07736;
22 Dec 94 10:36 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04106;
22 Dec 94 10:36 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04029;
22 Dec 94 10:33 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa07673;
22 Dec 94 10:33 EST
Received: from [128.102.17.23] (edi_test.arc.nasa.gov [128.102.17.23]) by Mordor.Stanford.EDU (8.6.9/8.6.6) with SMTP id HAA08438; Thu, 22 Dec 1994 07:33:34 -0800
Message-Id: <v03000e0bab1f49cd8770 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Dec 1994 07:33:36 -0800
To: P.Furniss at ulcc.ac.uk
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
Cc: ietf <ietf at CNRI.Reston.VA.US>
At 3:44 AM 12/22/94, Peter Furniss wrote:
>I have seen this interpreted as meaning the name of the I-D should not
>be given in (paper) published articles that refer to current IETF
>work. This seems distinctly unhelpful, especially where cooperation
>with other groups is desired.
>
>Can it be agreed that a reference to an I-D by a document (of any
>kind) can give the (current) file name, but should make clear the
>ephemeral status ? (For example "These concepts are described in the
Peter, I believe a citation is about information needed to locate a
document, rather than information about the "name" of the document. The
title on page one of a document is the name of the document. The filename
is part of its location information.
In any event, it is essential that I-D's not be declared according to any
of the information that is specific to their maintenance as an I-D.
Hence, my own practise when the Foobar working group is producing the the
Foo Protocol, is to have a citation along the lines of
Foo Protocol, draft
and very much NOT to have filename, which would be something like:
ietf-foobar-foo-00.txt
d/
ps. After my/our experience a couple of days ago on this list, I just
can't WAIT to find out if people get only one copy of this note. But
PLEASE don't tell me. I'll find out directly...
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05204;
22 Dec 94 11:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05198;
22 Dec 94 11:22 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08890;
22 Dec 94 11:22 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05183;
22 Dec 94 11:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05098;
22 Dec 94 11:20 EST
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa08825;
22 Dec 94 11:20 EST
Received: (from ole at localhost) by Csli.Stanford.EDU (8.6.9/8.6.9) id IAA24704; Thu, 22 Dec 1994 08:19:16 -0800
Date: Thu, 22 Dec 94 8:19:14 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: P.Furniss at ulcc.ac.uk
Cc: ietf <ietf at CNRI.Reston.VA.US>
Phone: +1 415 578-6900 (SOFTBANK Expos)
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 578-6988 (Office) +1 415 998-4427 (Pager)
FAX: +1 415 525-0194 (SOFTBANK Expos) +1 415 826-2008 (Home)
Address: 303 Vintage Park Drive, Foster City, CA 94404-1138
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
In-Reply-To: Your message of Thu, 22 Dec 1994 11:44:10 +0000 (GMT)
Message-ID: <CMM.0.90.4.788113154.ole at Csli.Stanford.EDU>
>(For example "These concepts are described in the
>Internet-Draft "draft-ietf-nosuchgroup-ihope-01.txt", which is a
>working document of the IETF nosuchgroup working group and will be
>revised or replaced in the future") I would not think it was necessary
>to give the summary of the IETF practices in every such reference."
Exactly. I have been arguing this for years, but have not had much
success. If we further accept that Internet-Drafts are electronic
documents and that 99% of all people who look at them are going to
understand that the document came from a computer (from where new
versions can be retrieved), then it is a simple matter to *retain* the
document in the archive *forever* but change it to contain pointers
instead of any other text. So, for example, when you go fetch the
document "draft-ietf-nosuchgroup-ihope-01.txt", it will contain ONE
(or two) sentences that say something like:
"The nosuch group decided that we didn't need a new version of RIP and
went to the bar. There is no spec with this name."
or
"draft-ietf-nosuchgroup-ihope-01.txt", is now RFC 6700, "RIP Version 9,"
by Dewey, Cheatem and Howe, November 2048."
(Lawyers willl of course be writing all our specs in the year 2048).
Anyone who decides to use a work-in-progress document for conformance
or marketing purposes ("Our new MaxiNetBox conforms to "draft-ietf...")
deserve what they get.
Happy Holidays!
Ole
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report,
Interop Company, a division of SOFTBANK Expos, 303 Vintage Park Drive,
Foster City, CA 94404-1138, USA. Ph: +1 (415) 578-6988 Fax: +1 (415) 525-0194.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05644;
22 Dec 94 11:36 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09202;
22 Dec 94 11:36 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05550;
22 Dec 94 11:36 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05281;
22 Dec 94 11:25 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-vines-02.txt
Date: Thu, 22 Dec 94 11:25:24 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9412221125.aa05281 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The PPP Banyan Vines Control Protocol (BVCP)
Author(s) : S. Senum
Filename : draft-ietf-pppext-vines-02.txt
Pages : 10
Date : 12/21/1994
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol, and proposes a family of
Network Control Protocols for establishing and configuring different
network-layer protocols.
This document defines the Network Control Protocol for establishing
and configuring the Banyan VINES protocol over PPP.
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-pppext-vines-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-vines-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-pppext-vines-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19941221140256.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-vines-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-vines-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941221140256.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06629;
22 Dec 94 12:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06617;
22 Dec 94 12:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10334;
22 Dec 94 12:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06586;
22 Dec 94 12:24 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06516;
22 Dec 94 12:21 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa10242;
22 Dec 94 12:21 EST
Received: by ginger.lcs.mit.edu
id AA12727; Thu, 22 Dec 94 12:21:34 -0500
Date: Thu, 22 Dec 94 12:21:34 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9412221721.AA12727 at ginger.lcs.mit.edu>
To: J.Crowcroft at cs.ucl.ac.uk, ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
Cc: jnc at ginger.lcs.mit.edu
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
There are two schools of thought on ATM
1/ its a muxing technique for the phone companies
2/ its a replacement for IP
I've been fond of saying that ATM should either shoot for 2/, or accept the
fact that it's a constituent network technology and leave all the problems
that are best handled at the internetwork level (like routing) at that level.
I have no idea if it has any validity as a pure constituent technology, but
it's not doing 2/ properly, in my opinion, for reasons I won't get into.
VCs rather than datagram mean you can do resource reservation and
security properly ... VCs are an anathema to efficient many-to-many
communication ... You want to send lots of streams, and you want to
receive lots of streams. With VCs, you get to have to keep O(n**2) PCBs.
With datagrams you get O(n).
It's pretty clear that you can't reasonably support multi-cast by building it
on top of unicast without *any* support out there in the fabric (i.e. by
simulating it with O(N^2) direct unicast connections between all the
participants). However, there are intermediates (such as using unicast streams
between "distribution modules" which split a traffic stream, allowing you to
produce a distribution tree). I don't know it the ATM people are exploring
any of these.
Finally, on the technical front: signaling, addressing and routing
... well, shame there isn't much right now isn't it?
Well, there is a draft routing spec going around now.
when there is, what will have been the cost to develop a new ...
distriuted adaptive routing famework, when we already have one for IP?
Well, it depends on what happens with IP. If IP correctly takes the next step
into an architecture that has the capabilities needed to support a global
communication infrastructre, it will probably be a waste. If IP doesn't do
that (and it's an open question if it will), and ATM gets 2/ right, maybe it
won't be a waste.
why am i unpleasantly reminded of what we used to have to do with X.25 for
WANs in the late 70s/early 80s?
Because they are making many of the same mistakes, obviously! Most
prominently, offering a partial solution under the illusion that that are
offering a complete solution. No architecture which tries to do 2/, and
doesn't support a heterogeneous mix of networking technologies, is going to
fly, I reckon.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06854;
22 Dec 94 12:42 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06848;
22 Dec 94 12:42 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10702;
22 Dec 94 12:42 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06838;
22 Dec 94 12:42 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06786;
22 Dec 94 12:40 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa10667;
22 Dec 94 12:40 EST
Received: from [128.102.17.23] (edi_test.arc.nasa.gov [128.102.17.23]) by Mordor.Stanford.EDU (8.6.9/8.6.6) with SMTP id JAA08975; Thu, 22 Dec 1994 09:40:15 -0800
Message-Id: <v03000e00ab1f5f2b640f at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Dec 1994 09:40:19 -0800
To: "Ole J. Jacobsen" <ole at csli.stanford.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
Cc: ietf <ietf at CNRI.Reston.VA.US>
Ole, et al,
At 8:19 AM 12/22/94, Ole J. Jacobsen wrote:
>success. If we further accept that Internet-Drafts are electronic
>documents and that 99% of all people who look at them are going to
>understand that the document came from a computer (from where new
Since we do not currently have a working version of such a service -- for
example documents are NOT retained forever in the archive and we need to
remember that it costs money to retain them -- we need to treat your view
as a goal.
Goals are fine and it would be great to work toward this one, but meanwhile
we need to have citation practises that are compatible with current
reality.
The current reality is that these things are HIGHLY transit and DO disappear.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07759;
22 Dec 94 13:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab07753;
22 Dec 94 13:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12155;
22 Dec 94 13:48 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07737;
22 Dec 94 13:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07708;
22 Dec 94 13:46 EST
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa12080;
22 Dec 94 13:46 EST
Received: (from ole at localhost) by Csli.Stanford.EDU (8.6.9/8.6.9) id KAA27203; Thu, 22 Dec 1994 10:45:26 -0800
Date: Thu, 22 Dec 94 10:45:24 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: "Ole J. Jacobsen" <ole at csli.stanford.edu>
Cc: P.Furniss at ulcc.ac.uk, ietf <ietf at CNRI.Reston.VA.US>
Phone: +1 415 578-6900 (SOFTBANK Expos)
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 578-6988 (Office) +1 415 998-4427 (Pager)
FAX: +1 415 525-0194 (SOFTBANK Expos) +1 415 826-2008 (Home)
Address: 303 Vintage Park Drive, Foster City, CA 94404-1138
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
In-Reply-To: Your message of Thu, 22 Dec 94 8:19:14 PST
Message-ID: <CMM.0.90.4.788121924.ole at Csli.Stanford.EDU>
Just in case I wasn't 100% clear: The idea would be to turn each
obsolete I-D into a file which contains ONLY a pointer with the rest
of text DELETED. Think of it as turning the contents of a file into
an index mechanism. Lots of really small files. We would of course
have to announce this change in the usual way, and probably add a
suffix or prefix to the I-D name in order to mark it as "empty,
contains pointer only," but this seems trivial to me.
Ole
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08306;
22 Dec 94 14:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08300;
22 Dec 94 14:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12776;
22 Dec 94 14:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08288;
22 Dec 94 14:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08239;
22 Dec 94 14:05 EST
Received: from pax.cavebear.com by CNRI.Reston.VA.US id aa12719;
22 Dec 94 14:05 EST
Received: from karl.pax by cavebear.com (4.1/SMI-4.1)
id AA02029; Thu, 22 Dec 94 11:05:48 PST
Date: Thu, 22 Dec 94 11:05:48 PST
Message-Id: <9412221905.AA02029 at cavebear.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Dave Crocker's message of Thu, 22 Dec 1994 09:40:19 -0800 <v03000e00ab1f5f2b640f at [128.102.17.23]>
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
Reply-To: karl at cavebear.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Karl Auerbach <karl at cavebear.com>
X-Orig-Sender: karl at cavebear.com
Repository: cavebear
Originating-Client: pax
>>success. If we further accept that Internet-Drafts are electronic
>>documents and that 99% of all people who look at them are going to
>>understand that the document came from a computer (from where new
>
>Since we do not currently have a working version of such a service -- for
>example documents are NOT retained forever in the archive and we need to
>remember that it costs money to retain them -- we need to treat your view
>as a goal.
>
>Goals are fine and it would be great to work toward this one, but meanwhile
>we need to have citation practises that are compatible with current
>reality.
>
>The current reality is that these things are HIGHLY transit and DO disappear.
I certainly agree with you that it is a burden to retain IDs.
However, they do contain important information, if only the fact that
they represent someone's thoughts.
We should be careful not to lose something simply because today we
can not achieve a concensus that it is valuable. Tomorrow that
concensus may change and the documents are gone.
Do we have an archival site or mechanism so that we can visit, perhaps
with some pain or cost, the old and expired IDs?
I know the following will sound like a bit of anathema, but
perhaps some commercial entity would like to run the archive and
do a lightweight experiment in digital commerce to cover the
costs.
In that case would it be OK to cite them?
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08838;
22 Dec 94 14:45 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08832;
22 Dec 94 14:45 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13531;
22 Dec 94 14:45 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08823;
22 Dec 94 14:45 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08753;
22 Dec 94 14:42 EST
Received: from pluto.ulcc.ac.uk by CNRI.Reston.VA.US id aa13461;
22 Dec 94 14:42 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Peter Furniss <cziwprf at pluto.ulcc.ac.uk>
Message-Id: <13283.9412221943 at pluto.ulcc.ac.uk>
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
To: ietf <ietf at CNRI.Reston.VA.US>
Date: Thu, 22 Dec 1994 19:43:04 +0000 (GMT)
In-Reply-To: <v03000e0bab1f49cd8770 at [128.102.17.23]> from "Dave Crocker" at Dec 22, 94 07:33:36 am
Reply-To: P.Furniss at ulcc.ac.uk
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1009
In reply to my message, Dave Crocker sent (precisely once :-)
> Peter, I believe a citation is about information needed to locate a
> document, rather than information about the "name" of the document. The
> title on page one of a document is the name of the document. The filename
> is part of its location information.
It is both unambiguous identification and location information that we
should allow other documents to include, where appropriate. I-D's are
liable not have clear identifications internally, so the filename
(which is now on the front page too, usually) is the only unambiguous
label.
Not including the location information in a citation that the readers
may need to follow up seems to be contrary to the openness of the
IETF. These aren't the pre-print papers of a closed community. If the
nosuchgroup's drafts look like affecting a wider community, must all
the people who read the article mentioning this send emails to the
author asking for details ?
Happy Christmas all.
Peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08947;
22 Dec 94 14:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08941;
22 Dec 94 14:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13588;
22 Dec 94 14:49 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08932;
22 Dec 94 14:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08845;
22 Dec 94 14:47 EST
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa13557;
22 Dec 94 14:47 EST
Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA06217; Thu, 22 Dec 94 11:41:27 -0800
Received: by skidrow.tay.dec.com (5.65/MS-081993);
id AA04863; Thu, 22 Dec 1994 14:46:18 -0500
Message-Id: <9412221946.AA04863 at skidrow.tay.dec.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
In-Reply-To: Your message of "Thu, 22 Dec 94 10:45:24 PST."
<CMM.0.90.4.788121924.ole at Csli.Stanford.EDU>
Date: Thu, 22 Dec 94 14:46:17 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.tay.dec.com>
X-Mts: smtp
I believe this sort of thing is done to some extent now when drafts
time out, etc.
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
>
>Just in case I wasn't 100% clear: The idea would be to turn each
>obsolete I-D into a file which contains ONLY a pointer with the rest
>of text DELETED. Think of it as turning the contents of a file into
>an index mechanism. Lots of really small files. We would of course
>have to announce this change in the usual way, and probably add a
>suffix or prefix to the I-D name in order to mark it as "empty,
>contains pointer only," but this seems trivial to me.
You could just smash the version number to 99 to indicate this:
draft-xxx-badidea-99.txt, etc.
but I'm not sure any mechanism is necessary. People usually
just look for the most recent version and if its less than
100 bytes long, it's a big clue that the draft has really gone
away.
>Ole
Donald
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09241;
22 Dec 94 15:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09235;
22 Dec 94 15:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14114;
22 Dec 94 15:10 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09208;
22 Dec 94 15:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09168;
22 Dec 94 15:07 EST
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa14065;
22 Dec 94 15:07 EST
Received: from skidrow.tay.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94)
id AA26744; Thu, 22 Dec 94 12:02:16 -0800
Received: by skidrow.tay.dec.com (5.65/MS-081993);
id AA05462; Thu, 22 Dec 1994 15:06:57 -0500
Message-Id: <9412222006.AA05462 at skidrow.tay.dec.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
In-Reply-To: Your message of "Thu, 22 Dec 94 11:05:48 PST."
<9412221905.AA02029 at cavebear.com>
Date: Thu, 22 Dec 94 15:06:57 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.tay.dec.com>
X-Mts: smtp
From: Karl Auerbach <karl at cavebear.com>
To: ietf at CNRI.Reston.VA.US
>I certainly agree with you that it is a burden to retain IDs.
>
>However, they do contain important information, if only the fact that
>they represent someone's thoughts.
>
>We should be careful not to lose something simply because today we
>can not achieve a concensus that it is valuable. Tomorrow that
>concensus may change and the documents are gone.
The vast majority of internet-drafts are mailed to some working group
mailing list as well as making their way to the internet drafts
directory and are archived along with mail discussing them.
Even when that isn't true, almost anything that has been put out as an
internet draft could be successfully submitted by its author(s) as an
information RFC if they want to do so. If the authors to not care to
exercise this or other means of preserving their work, why should the
ietf worry about it?
>Do we have an archival site or mechanism so that we can visit, perhaps
>with some pain or cost, the old and expired IDs?
>
>I know the following will sound like a bit of anathema, but
>perhaps some commercial entity would like to run the archive and
>do a lightweight experiment in digital commerce to cover the
>costs.
Why anathema? Commercial outfits retrieve and sell RFCs (usually in
hard copy form) all the time. As far as I'm concerned, anyone who
wanted to do this would be welcome to.
>In that case would it be OK to cite them?
internet-drafts are intended to be emphemeral. There is a limit to
how much clutter people can comprehend. I only cite I-Ds in other
I-Ds.
> --karl--
Donald
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09532;
22 Dec 94 15:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09526;
22 Dec 94 15:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14429;
22 Dec 94 15:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09502;
22 Dec 94 15:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09450;
22 Dec 94 15:22 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14331;
22 Dec 94 15:22 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09441;
22 Dec 94 15:22 EST
To: "Ole J. Jacobsen" <ole at csli.stanford.edu>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
In-reply-to: Your message of "Thu, 22 Dec 94 10:45:24 PST."
<CMM.0.90.4.788121924.ole at Csli.Stanford.EDU>
Date: Thu, 22 Dec 94 15:22:20 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Coya <scoya at CNRI.Reston.VA.US>
Message-ID: <9412221522.aa09441 at IETF.CNRI.Reston.VA.US>
>> Just in case I wasn't 100% clear: The idea would be to turn each
>> obsolete I-D into a file which contains ONLY a pointer with the rest
>> of text DELETED.
Something like this?
/ftp/internet-drafts>more draft-wollman-nap-based-00.txt
This Internet Draft was deleted. For more information, send a message to
Internet-drafts at nri.reston.va.us.
/ftp/internet-drafts>
or this?
/ftp/internet-drafts>more draft-zimmerman-finger-03.txt
A new Request for Comments is now available in online RFC libraries.
RFC 1288:
Title: The Finger User Information Protocol
Author: D. Zimmerman
Mailbox: dpz at dimacs.rutgers.edu
Pages: 12
Characters: 25,161
Obsoletes: RFC 1196
pathname: rfc/rfc1288.txt
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10959;
22 Dec 94 16:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10953;
22 Dec 94 16:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15878;
22 Dec 94 16:35 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10936;
22 Dec 94 16:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10904;
22 Dec 94 16:33 EST
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa15822;
22 Dec 94 16:33 EST
Received: (from ole at localhost) by Csli.Stanford.EDU (8.6.9/8.6.9) id NAA29949; Thu, 22 Dec 1994 13:32:48 -0800
Date: Thu, 22 Dec 94 13:32:46 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: Steve Coya <scoya at CNRI.Reston.VA.US>
Cc: "Ole J. Jacobsen" <ole at csli.stanford.edu>, ietf at CNRI.Reston.VA.US
Phone: +1 415 578-6900 (SOFTBANK Expos)
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 578-6988 (Office) +1 415 998-4427 (Pager)
FAX: +1 415 525-0194 (SOFTBANK Expos) +1 415 826-2008 (Home)
Address: 303 Vintage Park Drive, Foster City, CA 94404-1138
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
In-Reply-To: Your message of Thu, 22 Dec 94 15:22:20 -0500
Message-ID: <CMM.0.90.4.788131966.ole at Csli.Stanford.EDU>
Great, so it is being done already. Then I don't see a problem citing drafts.
ole
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report,
Interop Company, a division of SOFTBANK Expos, 303 Vintage Park Drive,
Foster City, CA 94404-1138, USA. Ph: +1 (415) 578-6988 Fax: +1 (415) 525-0194.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11224;
22 Dec 94 16:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11218;
22 Dec 94 16:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16101;
22 Dec 94 16:48 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11201;
22 Dec 94 16:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11096;
22 Dec 94 16:45 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16054;
22 Dec 94 16:45 EST
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-20)
id <AA17850>; Thu, 22 Dec 1994 13:45:38 -0800
Date: Thu, 22 Dec 1994 13:45:37 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: braden at isi.edu
Posted-Date: Thu, 22 Dec 1994 13:45:37 -0800
Message-Id: <199412222145.AA28291 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA28291>; Thu, 22 Dec 1994 13:45:37 -0800
To: ietf at CNRI.Reston.VA.US, karl at cavebear.com
Subject: Re: Citing I-Ds (was Re: Draft RFCs)
*> However, they do contain important information, if only the fact that
*> they represent someone's thoughts.
*>
*> We should be careful not to lose something simply because today we
*> can not achieve a concensus that it is valuable. Tomorrow that
*> concensus may change and the documents are gone.
*>
Karl,
Thoughts that are are worth retaining can always be, indeed SHOULD be,
published as Informational RFCs. RFCs form the archival document
series of the Internet community. Having two archival series has
always seemed to me to be a Bad Idea.
Bob Braden
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11690;
22 Dec 94 17:20 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11684;
22 Dec 94 17:20 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16695;
22 Dec 94 17:20 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11672;
22 Dec 94 17:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11624;
22 Dec 94 17:17 EST
Received: from tipper.oit.unc.edu by CNRI.Reston.VA.US id aa16655;
22 Dec 94 17:17 EST
Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02)
id AA01063; Thu, 22 Dec 94 17:17:34 EST
Message-Id: <9412222217.AA01063 at tipper.oit.unc.edu>
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
In-Reply-To: Your message of "Thu, 22 Dec 94 10:11:16 GMT."
<607.788091076 at cs.ucl.ac.uk>
Date: Thu, 22 Dec 94 17:17:33 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
"ATM- it's not just a link layer, it's er...um...
actually, it is just a link layer - sorry about that"
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12250;
22 Dec 94 17:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12244;
22 Dec 94 17:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17063;
22 Dec 94 17:37 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12206;
22 Dec 94 17:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12163;
22 Dec 94 17:35 EST
Received: from acton.timeplex.com by CNRI.Reston.VA.US id aa17014;
22 Dec 94 17:35 EST
Received: from enigma.acton.timeplex.com (enigma.acton.timeplex.com [134.196.22.57]) by maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with ESMTP id RAA02535; Thu, 22 Dec 1994 17:36:36 -0500
Received: from maelstrom.timeplex.com (malis at localhost) by enigma.acton.timeplex.com (8.6.9/ACTON-SUB-1.0) with ESMTP id RAA02949; Thu, 22 Dec 1994 17:36:34 -0500
Message-Id: <199412222236.RAA02949 at enigma.acton.timeplex.com>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
cc: J.Crowcroft at cs.ucl.ac.uk, ietf at CNRI.Reston.VA.US,
malis at maelstrom.timeplex.com
Subject: Re: J'Accuse, ATM
In-reply-to: Your message of "Thu, 22 Dec 1994 12:21:34 EST."
<9412221721.AA12727 at ginger.lcs.mit.edu>
Date: Thu, 22 Dec 1994 17:36:34 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Andy Malis <malis at maelstrom.timeplex.com>
Jon, Noel, et al,
As an old-time ARPANET, X.25, and IP guy that's gotten into ATM as
well lately, let me try to lower the flame content a bit.
IP and ATM both have their places, it's just a question of defining the
proper role for each.
IP, as it is CURRENTLY switched by routers, cannot carry
constant-bit-rate traffic at all, and doesn't do that great a job on
VBR traffic that requires particular loss or delay characteristics.
Some would also argue that there are limits as to how many IPv4 (or,
looking forward, IPv6) datagrams can be handled by layer 3 switching
as currently defined in router requirements (including decrementing
TTL, recomputing the checksum, options processing, etc.).
The RSVP and int-serv groups are addressing the VBR traffic. CBR
traffic is a lot harder in a variable-sized-datagram world, unless you
are broadcasting and don't mind huge playback buffers. Real-time CBR
is probably a very bad application for IP, anyway.
Very smart people are also working on speeding up router forwarding
rates.
The CURRENT generation of ATM switches, as implemented by most (but
not all) vendors, is really only good for CBR traffic. However,
again, very smart people are working on fixing that, and its other
current design and implementation shortcomings.
However, to me, the promise (or purpose) of ATM isn't to replace IP at
all, but to be an efficient means to carry all kinds of traffic,
including voice, video, CBR streams, IP, and all the rest using one
single data transmission infrastructure, along with the speed
efficiencies that come with hardware switching and replacing network
layer switching with cell switching (where it makes sense - the ROLC
WG is working on defining where it makes sense and where it doesn't).
In its SAA, LAN Emulation, and Multiprotocol over ATM working groups,
the ATM Forum has repeatedly endorsed the idea that you just don't run
ATM by itself. Instead, you use ATM as the basis for supporting a lot
of different applications over one underlying infrastructure. IP
happens to be one of those applications.
I will be the first to agree that ATM isn't the universal answer to
life, the universe, and everything, and that it has been a long time
coming. However, I also think that it is too early to call it a
failure.
It's the marketeers and the trade rags that try to push the idea of
ATM uber alles, and if anyone should take the hit for pushing a
technology before it is ready, it is them. However, once ATM has a
couple of generations of switches under its belt, and the carriers
start to deploy it enough that it is practical and cost-effective to
use in the wide area, then it'll be time to judge how well ATM is
doing.
Happy and peaceful holidays to all,
Andy
__________________________________________________________________________
Andrew G. Malis malis at maelstrom.timeplex.com +1 508 266-4522
Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13189;
22 Dec 94 18:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13183;
22 Dec 94 18:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17839;
22 Dec 94 18:15 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13174;
22 Dec 94 18:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13149;
22 Dec 94 18:13 EST
Received: from stilton.cisco.com by CNRI.Reston.VA.US id aa17790;
22 Dec 94 18:13 EST
Received: from [171.69.60.202] (fbaker-mac.cisco.com [171.69.60.202]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id PAA17390; Thu, 22 Dec 1994 15:08:10 -0800
X-Sender: fred at stilton.cisco.com
Message-Id: <v02110100ab1fb67f22c3 at [171.69.60.202]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Dec 1994 15:08:11 -0800
To: Simon E Spero <ses at tipper.oit.unc.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fred at cisco.com>
Subject: Re: J'Accuse, ATM
Cc: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>, ietf at CNRI.Reston.VA.US
At 2:17 PM 12/22/94, Simon E Spero wrote:
>"ATM- it's not just a link layer, it's er...um...
> actually, it is just a link layer - sorry about that"
no, it's a data link layer with an attitude. You have to remember the attitude.
We could make it a network layer if you like, just like X.25's PLP. We
could run it over LAPB.
Any other improvements you'd like to make?
=============================================================================
If you're not living on the edge, you're taking up too much room!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17664;
22 Dec 94 22:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17653;
22 Dec 94 22:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22360;
22 Dec 94 22:56 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17635;
22 Dec 94 22:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17394;
22 Dec 94 22:54 EST
Received: from POSTOFFICE3.MAIL.CORNELL.EDU by CNRI.Reston.VA.US id aa22308;
22 Dec 94 22:54 EST
Received: from [132.236.236.170] (CU-DIALUP-0531.CIT.CORNELL.EDU [132.236.236.170]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id WAA09633; Thu, 22 Dec 1994 22:54:06 -0500
X-Sender: swb1 at postoffice3.mail.cornell.edu
Message-Id: <v02110300ab1ff2d5e434 at [132.236.199.117]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Dec 1994 22:54:23 -0500
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Scott Brim <swb1 at cornell.edu>
Subject: Re: J'Accuse, ATM
Cc: J.Crowcroft at cs.ucl.ac.uk, ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
At 12:21 12/22/94, Noel Chiappa wrote:
>I've been fond of saying that ATM should either shoot for 2/, or accept the
>fact that it's a constituent network technology and leave all the problems
>that are best handled at the internetwork level (like routing) at that level.
>I have no idea if it has any validity as a pure constituent technology, but
>it's not doing 2/ properly, in my opinion, for reasons I won't get into.
Noel, a network layer does routing within a network. An internetwork
layer does internet routing between networks. When two adjacent
constituent networks have the same technology, it seems reasonable to
see if it's possible to couple them more tightly for efficiency.
>participants). However, there are intermediates (such as using
unicast streams
>between "distribution modules" which split a traffic stream, allowing you to
>produce a distribution tree).
Eeeeeek! CU-SeeMe! (but it will be primarily based on multicast RSN)
>Well, it depends on what happens with IP. If IP correctly takes the next step
>into an architecture that has the capabilities needed to support a global
>communication infrastructre, it will probably be a waste. If IP doesn't do
>that (and it's an open question if it will), and ATM gets 2/ right, maybe it
>won't be a waste.
I've been thinking about what the timelines seem to be for deployment
of IPv6, the cost of ATM over diverse media like CATV distribution
trees, and the possible spread of ATM to end systems. It looks like a
close race.
>Because they are making many of the same mistakes, obviously! Most
>prominently, offering a partial solution under the illusion that that are
>offering a complete solution. No architecture which tries to do 2/, and
>doesn't support a heterogeneous mix of networking technologies, is going to
>fly, I reckon.
The conclusion, obviously, is that they are not trying to do 2/.
I wish we were having a meeting soon so we could argue over a fine dinner.
...Scott
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17665;
22 Dec 94 22:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17652;
22 Dec 94 22:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22361;
22 Dec 94 22:56 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17633;
22 Dec 94 22:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17399;
22 Dec 94 22:54 EST
Received: from POSTOFFICE3.MAIL.CORNELL.EDU by CNRI.Reston.VA.US id aa22312;
22 Dec 94 22:54 EST
Received: from [132.236.236.170] (CU-DIALUP-0531.CIT.CORNELL.EDU [132.236.236.170]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id WAA09622; Thu, 22 Dec 1994 22:53:58 -0500
X-Sender: swb1 at postoffice3.mail.cornell.edu
Message-Id: <v02110300ab1fe6efae63 at [132.236.199.117]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 22 Dec 1994 22:54:14 -0500
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Scott Brim <swb1 at cornell.edu>
Subject: Re: J'Accuse, ATM
Cc: ietf at CNRI.Reston.VA.US
At 05:11 12/22/94, Jon Crowcroft wrote:
>There are two schools of thought on ATM
>1/ its a muxing technique for the phone companies
>2/ its a replacement for IP
I use it as a network layer, and OC3 etc. as a link layer. Within a
private area many things besides IP can be run over it without IP (e.g.
cellified video) -- perhaps that is why you think it is being used to
replace IP. Many people, including Vint Cerf, have mourned the
disappearance of network layers in the major pieces of the Internet in
recent years. We're now finding out if this particular one is useful
or not.
>To address the latter (despite some people's protestations)
>a large number of available, affordable ATM switches are being landed
>in research labs so people develop technology to use this end to end
>native mode as the nervous system tendons and muscles of the
>information superhighway
You claim a large number of switches are being put in research labs as
part of an effort to replace IP. You then attack that straw man. A
very old tactic, Jon. What evidence do you have for your conspiracy
theory, and have you stopped beating your wife?
>However, this technology has not been slected on the basis of
>good, fair and proper evaluation. In fact, when talking to anyone
>who has tried using it for computer-computer communciations, I have
>yet to find someone who has positive things to say.
As I've said before, I (tentatively, contingent on testing) plan to
deploy it despite its shortcomings, because in my environment it
appears to be "good enough", and I can save more than either of us will
make in our lifetime by using it. We are benefiting a lot from testing
which other engineers have done -- so far it seems that under some
conditions, some switches are okay. I think it can only get better,
due to market forces, and if it doesn't get better then those same
market forces will lead to its being pushed into its proper place.
>It is alarming
>that all the books and papers and money that are being fired at this
>approach are so uncritical - in the research commuity, I have only
>seen one notable paper in the last two years (last edition of ToN)
>that questions the approachj/architecture.
Really? Forget books, but papers? Let's start with Allyn Romanow ...
hey, you know the literature better than I do. I don't understand what
you're saying.
>And yet at demonstrations in the RACE and other European research
>programs, and in the gigabit programs in the US, behind the scenes,
>under their breath, and so on, people are saying how painful this
>technology is.
Yes, in the past the switches were uniformly awful. They are certainly
better than they used to be. I would say at least one is now
acceptable.
>Now one excuse made by proponents is that this is new technology.
>I'm sorry, but it isn't.
What's new is the speed, so the bandwidth*delay exceeds thresholds we
never even dreamed of on X.25. What is new is understanding queue
management in order to support TCP/IP in an environment where its
behavior conflicts with its supporting service. X.25's "I'm here to
help you" problems were not brought forward to ATM, but new ones have
emerged and are being worked on. That sounds like progress as usual to
me.
>All (and I mean all) the excitement of the Internet is with the mbone,
>WWW and at a lower layer, IP6. Yet can _anyone_ run equivalents to
>any of these applciations over a significant size piece of ATM
For sure. That's the important question. Since there is so much
motivation for the new internet applications, and so much motivation
for a cost-saving technology like ATM, how can we make the two work
together. Technically it's ugly, but that is not the overwhelming
issue.
>Finally, on the technical front: signaling, addressing and routing
>... well, shame there isn't much right now isn't it?
Check out the P-NNI draft. It's being put together by many of the
people who brought you the modern Internet.
>Techical reasons cited for 'selecting ATM' include
Again, I agree, these are poor reasons. I don't know *anyone* who is
planning on deploying ATM because of its technical superiority.
>However, why am i writing this? well, the effort and pressure being
>put on us to develop solutions to problems bought about by this
>selection are enourmous. yet why am i unpleasantly reminded of what we
>used to have to do with X.25 for WANs in the late 70s/early 80s?
>
>Why should we have to put up with this?
Money. (1) people want to use it because it saves them money;
providers want to install it because it saves them money. (2) perhaps
you're having trouble getting grants for other things? Otherwise I
can't imagine why you would feel obligated to make IP work over ATM.
You could just ignore it and let the providers who deploy it sink into
oblivion.
Again, I think the problems are different from the X.25 days.
>There are a lot of smart people working on ATM
Frankly, from what I can see there are now as many smart people in the
ATM Forum as there are in the IETF, even in absolute numbers.
> ATM: Just Say No
See Figure 1.
...Scott, who will be out of touch Saturday-Saturday
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01531;
23 Dec 94 7:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01525;
23 Dec 94 7:07 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03416;
23 Dec 94 7:07 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01506;
23 Dec 94 7:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01433;
23 Dec 94 6:53 EST
Received: from sonne.darmstadt.gmd.de by CNRI.Reston.VA.US id aa03221;
23 Dec 94 6:53 EST
Received: from wadi.darmstadt.gmd.de (wadi [141.12.43.19]) by sonne.darmstadt.gmd.de (8.6.9/8.6.9) with SMTP id MAA01270; Fri, 23 Dec 1994 12:43:35 +0100
Date: Fri, 23 Dec 1994 12:43:35 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ruediger Grimm <grimm at darmstadt.gmd.de>
Message-Id: <199412231143.MAA01270 at sonne.darmstadt.gmd.de>
To: ifip-wg65 at ics.uci.edu, ifip65-prog at ics.uci.edu, wg65-exec at ics.uci.edu,
ifip-gtwy at ics.uci.edu, mhsnews at ics.uci.edu,
mhsnews%DEARN.BITNET at vm.gmd.de, newsletters at rare.nl, ripe at ripe.net,
wg-all at rare.nl, ietf at CNRI.Reston.VA.US
Subject: Call for Papers IFIP-ULPAA'95
Cc: i2 at sonne.darmstadt.gmd.de, i4 at sonne.darmstadt.gmd.de,
vis at sonne.darmstadt.gmd.de, M.Fry at cs.ucl.ac.uk, mike at socs.uts.edu.au,
bob at cs.wisc.edu
--- Sorry if you get this more than once ---
We are happy to inform you about our next IFIP working conference
"Upper Layers Protocols, Architectures, and Applications",
"ULPAA'95"
in Sydney, Australia, December 1995.
An ASCII version of our Call-for-Papers is attached below.
There is also a Postscript Version which you can retrieve
from our WWW pages which are referenced at the bottom of
the Call-for-Papers. Look, for example, into
http://www.ee.uts.edu.au/ifip/ULPAA95.html
Best regards --- Nathaniel, Ruediger, and Bob (ULPAA'95 Co-Chairs)
=========================== CALL FOR PAPERS: =========================
1995 IFIP International Working Conference
on
UPPER LAYER PROTOCOLS, ARCHITECTURES AND APPLICATIONS (ULPAA)
Sydney, Australia
Hipparch Workshop: 11th and 12th of December 1995
Tutorials: 11th and 12th of December 1995
Conference: 13th to 15th of December 1995
Under the auspices of:
IFIP Technical Committee 6 IFIP Working Group 6.5
Hosted by:
University of Technology, Sydney
and the Australian Computer Society
OVERVIEW
The Internet is now progressing into a "marketplace" of worldwide
interworking services. The TCP/IP protocol suite is simple
and can be used by an unlimited variety of applications.
It is accessible worldwide by more than 30 million users and
continues to grow.
Message Handling is still the most popular service and, although
widely used, still contains considerable technical and social
problems. However, the Internet already offers much richer
applications such as the World Wide Web, privacy and integrity
services, and information shopping.
The Internet puts us in the fascinating situation of engineering this huge
and complex communication system while we use it at the same time.
The conference is a place where active researchers can exchange
their understanding, experience,
and design plans about open network cooperation technology.
Increasingly, the effective use of computers depends upon smooth
interworking between disparate and diverse systems, communicating
with each other using a wide variety of networking technologies.
Such smooth interworking, in turn, depends critically on standardized
communication protocols, which are themselves dependent on
clearly-understood and well-specified architectures for distributed
applications. As new applications are developed, new protocols are
vital to the success of the applications in the world. The ULPAA
conference provides a pre-standards forum where leading researchers
can discuss promising and problematic developments in the world of
distributed applications. Past conferences in this series already have had
significant impact on the earliest stages of standard development
in both the ISO and Internet protocol suites. We are soliciting papers
that will help to focus the efforts of the networking community and to
point out new directions for continued progress.
CONFERENCE TOPICS
Application architectures:
- Implementation, and experience with distributed applications.
- Models and designs.
- Programming environments.
- Group communication models and services.
- The impact of human factors on upper layer protocol
design and implementation.
- Multimedia applications and communications.
- Management and operation of distributed services.
- The perspective of new applications like:
- World Wide Web (WWW),
- Directory services,
- Privacy and integrity services (PEM and PGP),
- Information shopping,
- Electronic publication,
- Business on open networks.
Impact on applications of underlying services:
- Interconnection of upper layer and application entities.
- Mobile communications.
- Upper layer network management and naming.
- Universal resource naming schemes.
- Presentation and session layer issues.
- Security and privacy provision.
- Very high-speed networking.
Standards:
- Upper layer conformance and interoperability testing activities.
- The role of the standardization process for upper layer protocols.
CONFERENCE OUTLINE
The purpose of the conference is to provide an international forum for the
exchange of information on the technical, economic, and social impacts and
experiences with upper layer protocols, architectures and distributed
applications. The conference format will be two and a half days of
conference paper presentations combined with one half a day of workshops.
INSTRUCTIONS TO AUTHORS
Prospective authors are invited to submit unpublished original
contributions (not exceeding 5000 words) which describe recent research
results or developments directly relevant to upper layer protocols,
architectures or distributed applications.
IFIP WG 6.5 intends to use modern communication technology
for its cooperation within the WG. The subject of our research
shall be the basis of our daily work.
Therefore, we are already using electronic mail for all WG business
including discussions, event preparations, joint reviewing, etc.
The next step will be to work on electronic publication for the
conference proceedings.
For this purpose, electronic submission of papers is highly recommended.
PUBLICATION
Papers that are accepted will be published by Chapman and Hall, London,
the general publisher for IFIP.
A preprint of the proceedings will be provided to attendees.
We will thoroughly examine the possibility of electronic publication
in accordance with IFIP and the Publisher.
DEADLINES
Today: Send a message, letter, phone, or fax to either
of the contacts below stating your intention to submit
a paper, or stating your general interest in the conference.
May 15, 95: Full version of papers due for review.
July 15, 95: Notification of acceptance/rejection.
Nov 1, 95: Camera-ready papers required for publication.
Please submit either five paper copies of your paper or one
file in electronic form (plain text and/or in Postscript format)
to one of the
PROGRAM COMMITTEE CO-CHAIRS:
Dr. Nathaniel S. Borenstein
First Virtual Holdings, Inc.
25 Washington Avenue
Morristown, NJ 07960
U S A
Email: nsb at nsb.fv.com
Tel: +1 201 993 8586
Fax: +1 201 993 3032
or to:
Dr. Ruediger Grimm
Gesellschaft fuer Mathematik und Datenverarbeitung GmbH
P.O. Box 100138
D-64201 Darmstadt
Germany
Email: grimm at darmstadt.gmd.de
Tel: +49 6151 869 716
Fax: +49 6151 869 785
or to:
Prof. Dr. Bob Kummerfeld
University of Sydney
Computer Science Departement
NSW 2006
Australia
Email: bob at cs.su.oz.au
Tel: +61 2 692 3423
Fax: +61 2 692 3838
PROGRAM COMMITTEE
Harald T. Alvestrand <harald.t.alvestrand at uninett.no>
Gregor v. Bochmann <bochmann at iro.umontreal.ca>
Nathaniel Borenstein <nsb at nsb.fv.com>
Jaime Delgado <delgado at ac.upc.es>
Rik Drummond <76550.1044 at compuserve.com>
Magdalena Feldhoffer <magdalena.feldhoffer at zentrale.deutsche-bank.dbp.de>
Frank E. Ferrante <ferrante at mitre.org>
Ned Freed <ned at innosoft.com>
Michael Fry <mike at socs.uts.edu.au>
James M. Galvin <galvin at tis.com>
Ruediger Grimm <grimm at darmstadt.gmd.de>
Alf Hansen <Alf.Hansen at uninett.no>
Christian Huitema <Christian.Huitema at sophia.inria.fr>
Ole J. Jacobsen <ole at interop.com, ole at csli.stanford.edu>
Steve Kille <s.kille at isode.com>
Bob Kummerfeld <bob at cs.su.oz.au>
R. Greg Lavender <G.Lavender at isode.com>
Ed Levinson <elevinson at accurate.com>
Hannes P. Lubich <lubich at switch.ch>
James McHugh <jmchugh at orion.uci.edu>
Manel Medina <medina at ac.upc.es>
Leandro Navarro <leandro at ac.upc.es>
Gerald Neufeld <neufeld at cs.ubc.ca>
Encarna Pastor <encarna at dit.upm.es>
Bernhard Plattner <plattner at tik.ethz.ch>
Marshall T. Rose <mrose at dbc.mtview.ca.us>
Pietro Schicker <schicker at clients.switch.ch>
Aruna Seneviratne <aps at ee.uts.edu.au>
Allan W. Shepherd <shepherd at hpl.hp.com>
Alnoor M. Shivji <shivji at vancouver.osiware.bc.ca>
Einar Stefferud <stef at nma.com>
IFIP WORKING GROUP 6.5 GENERAL CO-CHAIRS:
Einar Stefferud (Chair), Ruediger Grimm (Vice Chair)
PAST-PROGRAM CO-CHAIRS:
Bernhard Plattner, Gerald Neufeld (1992)
Manuel Medina, Nathaniel Borenstein (1994)
ORGANIZING COMMITTEE:
Michael Fry
School of Computing Sciences
University of Technology, Sydney
P.O.Box 123, Broadway
Sydney, NSW 2007
AUSTRALIA
Email: mike at socs.uts.edu.au
Tel: +61 2 330 1821
Fax: +61 2 330 1807
Aruna Seneviratne
School of Electrical Engineering
University of Technology, Sydney
P.O.Box 123, Broadway
Sydney, NSW 2007
AUSTRALIA
Email: aps at ee.uts.edu.au
Tel: +61 2 330 2441
Fax: +61 2 330 2435
TUTORIALS:
On Monday and Tuesday, December 11-12, time and space
is reserved for a number of tutorials.
We invite interested persons to submit proposals for tutorials.
If you have ideas about a tutorial and wish to discuss these ideas
informally, please just send email to one of the program chairs.
The following topics are being considered:
- Upper Layer/Application Layer Architecture
- Security Models, Mechanisms and Systems
- Message Handling Harmonization
- Directory Services Harmonization
- PGP and PEM
- Network Management
- ASN.1
- Coexistence and Transition to OSI Applications
- Distributed Application Programming Environments
- Multimedia Internet Mail (MIME)
- World Wide Web Applications
- Payment and Purchase Systems on the Internet
HIPPARCH WORKSHOP:
The HIPPARCH Workshop will be meeting at the same location, parallel
to the tutorials in the two days 11th and 12th of December 1995,
prior to the conference proper. ULPAA participants are welcome
to attend the workshop.
The workshop is organized by UTS within the context of the HIPPARCH
Basic Research Action project (European-Australian collaboration),
sponsored by CEC DG XIII.
The objective of the HIPPARCH project is to study and design high performance
communication architectures and implementations, based particularly on the
"Application Level Framing" and "Integrated Layer Processing" concepts,
and with an emphasis on automatic protocol compilation techniques. Several
research groups engaged in this area will be represented.
The first HIPPARCH workshop was held at INRIA in December 1994.
This is the second workshop, which will present the outcomes of
the project in workshop format.
MORE INFORMATION ON THE WWW
There is more information in the WWW available
about the conference ULPAA 95:
http://www.ee.uts.edu.au/ifip/ULPAA95.html
about our IFIP Working Group 6.5 and the ULPAA 95 conference:
http://www.darmstadt.gmd.de/TKT/IFIP6.5/IFIP-WG6.5.html
and about the IFIP Technical Committee 6 and related WGs and conferences:
http://www.iaik.tu-graz.ac.at/IFIP/tc6_home.html
----- End Included Message -----
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02836;
23 Dec 94 9:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02832;
23 Dec 94 9:49 EST
Received: from inet1.tek.com by CNRI.Reston.VA.US id aa05824; 23 Dec 94 9:49 EST
Received: from tektronix.tek.com by inet1.tek.com id <AA29808 at inet1.tek.com>; Fri, 23 Dec 1994 06:49:55 -0800
Received: from dtl.labs.tek.com (crl.labs.tek.com) by tektronix.TEK.COM (4.1/8.2)
id AA16779; Fri, 23 Dec 94 06:48:11 PST
Received: by dtl.labs.tek.com (4.1/8.0)
id AA09104; Fri, 23 Dec 94 06:47:16 PST
Received: from tektronix.TEK.COM (tektronix.TEK) by dtl.labs.tek.com (4.1/8.0)
id AA09095; Fri, 23 Dec 94 06:47:13 PST
Received: from inet1.tek.com by tektronix.TEK.COM (4.1/8.2)
id AA16773; Fri, 23 Dec 94 06:48:03 PST
Received: from thumper.bellcore.com by inet1.tek.com id <AA38922 at inet1.tek.com>; Fri, 23 Dec 1994 06:48:40 -0800
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by thumper.bellcore.com (8.6.9/8.6.6) with SMTP id JAA00768 for <if-mib at thumper.bellcore.com>; Fri, 23 Dec 1994 09:48:32 -0500
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02747;
23 Dec 94 9:46 EST
To: IETF-Announce. at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: if-mib at thumper.bellcore.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: IEEE 802.5 Station Source Routing MIB to Proposed
Standard
Date: Fri, 23 Dec 94 09:46:58 -0500
Message-Id: <9412230946.aa02747 at IETF.CNRI.Reston.VA.US>
X-Orig-Sender: if-mib-owner at dtl.labs.tek.com
Precedence: bulk
The IESG has approved the Internet-Draft "IEEE 802.5 Station Source
Routing MIB" <draft-ietf-ifmib-ssr-mib-02.txt> as a Proposed Standard.
This document is the product of the Interfaces MIB Working Group. The
IESG contact person is Marshall T. Rose.
Technical Summary
This memo defines managed objects used by 802.5 end stations for
managing source routes on a Token Ring Network where IEEE source
routing is in use.
Working Group Summary
There were no contentious issues.
Protocol Quality
The NM-D has reviewed the draft.
Notes to the RFC editor (upon publication)
1. Please change the dot5SrMIBObjects OID accordingly
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02948;
23 Dec 94 9:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02942;
23 Dec 94 9:51 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05888;
23 Dec 94 9:51 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02886;
23 Dec 94 9:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02786;
23 Dec 94 9:48 EST
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa05814;
23 Dec 94 9:48 EST
Received: by interlock.ans.net id AA25668
(InterLock SMTP Gateway 1.1 for ietf at CNRI.Reston.VA.US);
Fri, 23 Dec 1994 09:49:02 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Fri, 23 Dec 1994 09:49:02 -0500
Date: Fri, 23 Dec 94 9:49:00 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Guy Almes <almes at ans.net>
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
In-Reply-To: Your message of Thu, 22 Dec 94 10:11:16 +0000
Message-Id: <CMM.0.90.2.788194140.almes at home.ans.net>
Jon,
In February 1994, I had the pleasure of attending a RARE Workshop on High
Speed Networking for Research in Europe, held in Brussels. I presented a
paper that, among other things, noted that sustaining high-speed flows (say,
40 Mb/s) over wide areas (say, 4,000 miles) was achievable within the IP
Internet. It is very challenging, however, for reasons that include the need
for large and intelligently managed buffers. And (and here is why I flew
from San Diego to Brussels in the dead of winter to attend the meeting)
making such high-speed wide-area flows opeartionally normative on whatever
network our scientists depend on for worldwide computer networking during the
late 1990s will require sustained engineering effort. I hate to state that
these problem cannot be solved within an ATM context, but I pointed out that
there were several reasons why ATM would make this more, rather than less,
difficult.
Most of the other papers at that Workshop related to ATM testbeds set up
within small geographic areas with first-generation equipment. It was not
surprising that those papers did not generally address how sustained
high-speed wide-area flows with bursty traffic sources could be supported
using ATM testbeds. What did concern me was that those planning the ATM
testbeds did not generally appreciate the importance of the issue.
Since that workshop, we in the states have seen two attempts to make ATM
technology prominent within the new NSFnet architecture.
<> two of the four NSF NAPs plan to use ATM metropolitan area clouds as
Internet exchange points.
<> it is expected that the vBNS will use an ATM wide-area cloud to support
high-end applications.
Time will tell whether (or the extent to which) these efforts succeed.
Americans are just as capable of being seduced or confused about ATM as the
Europeans. My hope is that these two efforts will be conducted pragmatically
so that we openmindedly accept ATM as a possible tool in solving the problems
of improving the Internet's engineering, but so that we also avoid accepting
ATM as an end in itself -- an engineering/political constraint within which
Internet engineers must work.
1995 will be an interesting year.
-- Guy
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03808;
23 Dec 94 10:32 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06707;
23 Dec 94 10:32 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03760;
23 Dec 94 10:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03707;
23 Dec 94 10:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06641;
23 Dec 94 10:28 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03701;
23 Dec 94 10:28 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: snadlcmib at cisco.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Definitions of Managed Objects for SNA Data Link
Control: SDLC to Proposed Standard
Date: Fri, 23 Dec 94 10:28:14 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9412231028.aa03701 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Definitions of Managed
Objects for SNA Data Link Control: SDLC" <draft-ietf-snadlc-sdlc-mib-06.txt>
as a Proposed Standard. This document is the product of the SNA DLC
Services MIB Working Group. The IESG contact person is Marshall T. Rose.
Technical Summary
This memo defines managed objects for SNA Synchronous Data Link
Control links.
Working Group Summary
There were no unresolved issues of convention.
Protocol Quality
The NM-D has reviwed the memo.
Notes to the RFC Editor (upon publication)
1. Please consult the NM-D for OID assignment for this mib module.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04265;
23 Dec 94 10:53 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07128;
23 Dec 94 10:53 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04226;
23 Dec 94 10:53 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04187;
23 Dec 94 10:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07012;
23 Dec 94 10:49 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04180;
23 Dec 94 10:49 EST
To: IETF Announce: ;
Subject: WG Action: New Generation Transition (ngtrans)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: The IESG <iesg-secretary at IETF.CNRI.Reston.VA.US>
Date: Fri, 23 Dec 94 10:49:42 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9412231049.aa04180 at IETF.CNRI.Reston.VA.US>
A new working group has been created in the IPng Area
of the IETF. Please contact the working group chairs
or the area directors for more information.
==========================================================
New Generation Transition (ngtrans)
-----------------------------------
Chair(s):
Robert Gilligan <Bob.Gilligan at Eng.Sun.Com>
Tony Hain <alh at es.net>
IP: Next Generation Area Director(s):
Scott Bradner <sob at harvard.edu>
Allison Mankin <mankin at isi.edu>
Area Advisor
Scott Bradner <sob at harvard.edu>
Mailing lists:
General Discussion:ngtrans at sunroof.eng.sun.com
To Subscribe: majordomo at sunroof.eng.sun.com
In Body: include "subscribe ngtrans" in body
Archive: ftp:/playground.sun.com/pub/ngtrans
Description of Working Group:
The purpose of this group is to design the mechanisms and procedures to
support the transition of the Internet from IPv4 to IPv6.
The work of the group will fall into three areas:
1. Define the processes by which the Internet will be transitioned
from IPv4 to IPv6. As part of this effort, the group will produce
a document explaining to the general Internet community what
mechanisms will be employed in the transition, how the transition
will work, the assumptions about infrastructure deployment inherent
in the operation of these mechanisms, and the types of
functionality that applications developers will be able to assume
as the protocol mix changes over time.
2. Define and specify the mandatory and optional mechanisms that
vendors are to implement in hosts, routers, and other components of
the Internet in order for the transition to be carried out. Dual
protocol stack, encapsulation and header translation mechanisms
must all be defined, as well as the interaction between hosts using
different combinations of these mechanisms. The specifications
produced will be used by people implementing these IPv6 systems.
3. Articulate a concrete operational plan for transitioning the
Internet from IPv4 to IPv6. The result of this work will be a
transition plan for the Internet that network operators and
Internet subscribers can execute.
The group will use the Simple SIPP Transition (SST) overview document
<draft-ietf-sipp-sst-overview-00.txt> as the starting point for its
work on the IPv6 transition.
The group will work closely with the main IPng working group and the
IPng Address Configuration (addrconf) working group. The group will
co-ordinate with the tacit working group.
Goals and Milestones:
Sep 94 Submit Internet-Draft on General Overview of Transition
Sep 94 Submit Internet Draft on Specifications of Transition Mechanisms for
IPv6 Hosts and Routers
Sep 94 Submit Internet-Draft of Transition Plan for the Internet
Jan 95 Submit Internet-Draft on Specification of mechanisms for header
translating routers
Feb 95 Submit Specification of Transition Mechanisms for IPv6 Hosts and
Routers to IESG for consideration as a Proposed Standard.
Apr 95 Submit Specifications for Header Translating Routers document to IESG
for consideration as a Proposed Standard.
Jul 95 Submit Specifications of Transition Mechanisms for IPv6 Hosts and
Routers to IESG for consideration as a Draft Standard.
Jul 95 Submit Specification of mechanisms for header translating routers to
IESG for consideration as a Draft Standard.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08575;
23 Dec 94 14:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11509;
23 Dec 94 14:12 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08556;
23 Dec 94 14:11 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08397;
23 Dec 94 14:04 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tftpexts at hpindsh.cup.hp.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-tftpexts-analysis-00.txt
Date: Fri, 23 Dec 94 14:03:53 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9412231404.aa08397 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the TFTP Extensions Working Group
of the IETF.
Title : TFTP Option Negotiation Analysis
Author(s) : G. Malkin, A. Harkin
Filename : draft-ietf-tftpexts-analysis-00.txt
Pages : 3
Date : 12/22/1994
The TFTP option negotiation mechanism, proposed in [1], is a
backward-compatible extension to the TFTP protocol, defined in [2]. It
allows file transfer options to be negotiated prior to the transfer using a
mechanism which is consistent with TFTP's Request Packet format. The
mechanism is kept simple by enforcing a request-respond-acknowledge
sequence, similar to the lock-step approach taken by TFTP itself.
This document was written to allay concerns that the presence of options in
a TFTP Request packet might cause pathological behavior on servers which do
not support TFTP option negotiation.
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-tftpexts-analysis-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-tftpexts-analysis-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-tftpexts-analysis-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19941222113450.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-tftpexts-analysis-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tftpexts-analysis-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941222113450.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08735;
23 Dec 94 14:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11687;
23 Dec 94 14:19 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08701;
23 Dec 94 14:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08632;
23 Dec 94 14:16 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11614;
23 Dec 94 14:16 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08626;
23 Dec 94 14:16 EST
To: IETF-Announce: ;
cc: minutes at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: minutes at CNRI.Reston.VA.US
Subject: December IETF: On-line Minutes
Date: Fri, 23 Dec 94 14:16:05 -0500
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9412231416.aa08626 at IETF.CNRI.Reston.VA.US>
Below is a list of minutes and area reports from the December
IETF which will be available from the IETF remote directories
tomorrow.
Happy Holidays!
Debra
========
December IETF Area Reports
--------------------------
94dec/area.userservices.94dec.txt
December IETF Minutes
---------------------
94dec/acct2-minutes-94dec.txt
94dec/arts-minutes-94dec.txt
94dec/dlswmib-minutes-94dec.txt
94dec/http-minutes-94dec.txt
94dec/iab-minutes-94dec.txt
94dec/intprop-minutes-94dec.txt
94dec/ios-minutes-94dec.txt
94dec/ipv6mib-minutes-94dec.txt
94dec/mptrans-minutes-94dec.txt
94dec/nosi-minutes-94dec.txt
94dec/peering-minutes-94dec.txt
addrconf/addrconf-minutes-94dec.txt
aft/aft-minutes-94dec.txt
ale/ale-minutes-94dec.txt
asid/asid-minutes-94dec.txt
bmwg/bmwg-minutes-94dec.txt
cat/cat-minutes-94dec.txt
dnsind/dnsind-minutes-94dec.txt
dnssec/dnssec-minutes-94dec.txt
edi/edi-minutes-94dec.txt
html/html-minutes-94dec.txt
ids/ids-minutes-94dec.txt
imap/imap-minutes-94dec.txt
ipatm/ipatm-minutes-94dec.txt
isn/isn-minutes-94dec.txt
mhsds/mhsds-minutes-94dec.txt
mmusic/mmusic-minutes-94dec.txt
mobileip/mobileip-minutes-94dec.txt
nimrod/nimrod-minutes-94dec.txt
nisi/nisi-minutes-94dec.txt
opstat/opstat-minutes-94dec.txt
ospf/ospf-minutes-94dec.txt
pem/pem-minutes-94dec.txt
pppext/pppext-minutes-94dec.txt
quis/quis-minutes-94dec.txt
ripv2/ripv2-minutes-94dec.txt
rmonmib/rmonmib-minutes-94dec.txt
rolc/rolc-minutes-94dec.txt
rreq/rreq-minutes-94dec.txt
run/run-minutes-94dec.txt
snmpv2/snmpv2-minutes-94dec.txt
ssh/ssh-minutes-94dec.txt
tftpexts/tftpexts-minutes-94dec.txt
trainmat/trainmat-minutes-94dec.txt
Interim Minutes
---------------
rsvp/rsvp-minutes-94oct.txt
rmonmib/rmonmib-minutes-94nov.txt
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10178;
23 Dec 94 15:17 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12747;
23 Dec 94 15:17 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10161;
23 Dec 94 15:17 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10095;
23 Dec 94 15:13 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12676;
23 Dec 94 15:13 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA08895>; Fri, 23 Dec 1994 12:13:31 -0800
Message-Id: <199412232013.AA08895 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI26, RFC1709 in PostScript
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 Dec 94 12:14:31 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
Note: This is a PostScript version of FYI 26, RFC 1709. The ASCII
version of this RFC is the primary reference version. The PostScript
version is secondary. For descriptive purposes, the PostScript
version may contain typographic variations (italics, boldface, etc.),
figures, and other features that promote readability and
understanding.
FYI 26:
RFC 1709:
Title: K-12 Internetworking Guidelines
Author: J. Gargano & D. Wasley
Date: November 1994
Mailbox: jcgargano at ucdavis.edu, dlw at berkeley.edu
PS-Pages: 23
PS-Characters: 662,030
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1709.ps
Many organizations concerned with K-12 educational issues and the
planning for the use of technology recognize the value of data
communications throughout the educational system. State sponsored
documents such as the California Department of Education's
"Strategic Plan for Information Technology" recommend the planning
of voice, video and data networks to support learning and
educational administration, but they do not provide specific
technical direction.
The institutions that built the Internet and connected early in its
development are early adopters of technology, with technical staff
dedicated to the planning for and implementation of leading edge
technology. The K-12 community traditionally has not had this level
of staffing available for telecommunications planning. This
document is intended to bridge that gap and provides a recommended
technical direction, an introduction to the role the Internet now
plays in K-12 education and technical guidelines for building a
campus data communications infrastructure that provides
internetworking services and connections to the Internet.
This RFC is the product of the Internet School Networking 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-REQUEST at NIC.DDN.MIL.
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: application/postscript
Content-ID: <941223120845.RFC at ISI.EDU>
SEND /rfc/rfc1709.ps
--OtherAccess
Content-Type: Message/External-body;
name="rfc1709.ps";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: application/postscript
Content-ID: <941223120845.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10307;
23 Dec 94 15:20 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12828;
23 Dec 94 15:20 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10262;
23 Dec 94 15:20 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10198;
23 Dec 94 15:17 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12756;
23 Dec 94 15:17 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA08963>; Fri, 23 Dec 1994 12:18:06 -0800
Message-Id: <199412232018.AA08963 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1743 on IEEE 802.5 MIB using SMIv2
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 Dec 94 12:19:05 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1743:
Title: IEEE 802.5 MIB using SMIv2
Author: K. McCloghrie & E. Decker
Date: December 1994
Mailbox: kzm at cisco.com, cire at cisco.com
Pages: 25
Characters: 43,224
Obsoletes: 1231
URL: ftp://ds.internic.net/rfc/rfc1743.txt
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
subnetworks which use the IEEE 802.5 Token Ring technology described
in 802.5 Token Ring Access Method and Physical Layer Specifications,
IEEE Standard 802.5-1989. This memo is a replacement for RFC 1231.
This RFC is a product of the Interfaces MIB 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-REQUEST at NIC.DDN.MIL.
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: <941223121502.RFC at ISI.EDU>
SEND /rfc/rfc1743.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1743.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941223121502.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10414;
23 Dec 94 15:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12880;
23 Dec 94 15:23 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10391;
23 Dec 94 15:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10268;
23 Dec 94 15:20 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12815;
23 Dec 94 15:20 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA08998>; Fri, 23 Dec 1994 12:20:24 -0800
Message-Id: <199412232020.AA08998 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1744 on Management of Internet Address Space
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 Dec 94 12:21:24 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1744:
Title: Observations on the Management of
the Internet Address Space
Author: G. Huston
Date: December 1994
Mailbox: Geoff.Huston at aarnet.edu.au
Pages: 12
Characters: 32,411
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1744.txt
This memo examines some of the issues associated with the current
management practices of the Internet IPv4 address space, and examines
the potential outcomes of these practices as the unallocated address
pool shrinks in size. Possible modifications to the management
practices are examined, and potential outcomes considered. Some
general conclusions are drawn, and the relevance of these conclusions
to the matter of formulation of address management policies for IPv6
are noted.
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-REQUEST at NIC.DDN.MIL.
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: <941223121956.RFC at ISI.EDU>
SEND /rfc/rfc1744.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1744.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941223121956.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10526;
23 Dec 94 15:27 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12959;
23 Dec 94 15:27 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10502;
23 Dec 94 15:27 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10447;
23 Dec 94 15:24 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12901;
23 Dec 94 15:24 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA09158>; Fri, 23 Dec 1994 12:24:53 -0800
Message-Id: <199412232024.AA09158 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1745 on BGP4/IDRP for IP - OSPF Interaction
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 23 Dec 94 12:25:53 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1745:
Title: BGP4/IDRP for IP---OSPF Interaction
Author: K. Varadhan, S. Hares & Y. Rekhter
Date: December 1994
Mailbox: kannan at isi.edu, skh at merit.edu,
yakov at watson.ibm.com
Pages: 19
Characters: 43,675
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1745.txt
This memo defines the various criteria to be used when designing an
Autonomous System Border Router (ASBR) that will run either BGP4 or
IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
This RFC is the product of the Inter-Domain Routing 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-REQUEST at NIC.DDN.MIL.
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: <941223122238.RFC at ISI.EDU>
SEND /rfc/rfc1745.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1745.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941223122238.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10832;
23 Dec 94 15:58 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13464;
23 Dec 94 15:58 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10811;
23 Dec 94 15:58 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10782;
23 Dec 94 15:55 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13426;
23 Dec 94 15:55 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10776;
23 Dec 94 15:55 EST
To: IETF-Announce: ;
cc: ip-atm at hpl.hp.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: ATM Signaling Support for IP over ATM to Proposed
Standard
Date: Fri, 23 Dec 94 15:55:46 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9412231555.aa10776 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the IP Over Asynchronous Transfer
Mode Working Group to consider "ATM Signaling Support for IP over ATM"
<draft-ietf-ipatm-sig-02.txt> for the status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
January 6, 1995.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11604;
23 Dec 94 17:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11594;
23 Dec 94 17:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15070;
23 Dec 94 17:35 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11579;
23 Dec 94 17:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11551;
23 Dec 94 17:33 EST
Received: from sifon.CC.McGill.CA by CNRI.Reston.VA.US id aa15017;
23 Dec 94 17:33 EST
Received: from java.cc.mcgill.ca (java.CC.McGill.CA [132.206.35.22]) by sifon.CC.McGill.CA (8.6.9/8.6.6) with SMTP id RAA21810 for <ietf at CNRI.Reston.VA.US>; Fri, 23 Dec 1994 17:32:49 -0500
Date: Fri, 23 Dec 1994 17:33:57 -0500 (EST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ian Duncan <id at cc.mcgill.ca>
To: ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
In-Reply-To: <199412222236.RAA02949 at enigma.acton.timeplex.com>
Message-ID: <Pine.SUN.3.91.941223165526.8948A-100000 at java.cc.mcgill.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 22 Dec 1994, Andy Malis wrote:
> IP and ATM both have their places,
[ ... ]
> The RSVP and int-serv groups are addressing the VBR traffic. CBR
> traffic is a lot harder in a variable-sized-datagram world, unless you
> are broadcasting and don't mind huge playback buffers. Real-time CBR
> is probably a very bad application for IP, anyway.
[ ... ]
> However, to me, the promise (or purpose) of ATM isn't to replace IP at
> all, but to be an efficient means to carry all kinds of traffic,
> including voice, video, CBR streams, IP, and all the rest using one
> single data transmission infrastructure, along with the speed
> efficiencies that come with hardware switching and replacing network
> layer switching with cell switching (where it makes sense - the ROLC
> WG is working on defining where it makes sense and where it doesn't).
CBR seems to me a bit of a boogie (or at the least straw or perhaps
boondoggle) creature. All of the interesting information streams currently
carried on traditional broadband (cable and telephony) are prime
candidates for compression in the dawning era of $1/mip processors. These
signals have highly variable entropy and, once compressed, won't fit nicely
into standard N-bit tall pipes. To maximize BW utilization and minimize
latency we'll need reasonably large and variable length packets with
mechanisms for reservation of max-BW requirements and fast forwarding with
predictable delays -- both in the realm of possiblity within near future
IPv?.
> It's the marketeers and the trade rags that try to push the idea of
> ATM uber alles, and if anyone should take the hit for pushing a
> technology before it is ready, it is them. However, once ATM has a
> couple of generations of switches under its belt, and the carriers
> start to deploy it enough that it is practical and cost-effective to
> use in the wide area, then it'll be time to judge how well ATM is
> doing.
At the risk of rekindling the flame and losing the seasonal spirit ...
If you'll accept the addition to the list of minor villians, engineers
either temporarily blinded from staring at little cells to long or a
vested interest created by stock options and other 'greed' incentives then
sure, give them their licks. My biggest beef with ATM and the promoters is
that the captive market of telephone customers among other unfortunates
are being taxed to fund development and deployment of a very questionable
technology.
... ian <id at cc.mcgill.ca>
Ian Duncan --- McGill University Computing Centre --- +.514.398.3710
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11973;
23 Dec 94 18:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11969;
23 Dec 94 18:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15855;
23 Dec 94 18:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11960;
23 Dec 94 18:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11956;
23 Dec 94 18:23 EST
Received: from linus.mitre.org by CNRI.Reston.VA.US id aa15817;
23 Dec 94 18:23 EST
Received: (maybury at localhost) by linus.mitre.org (8.6.7/RCF-6S) id SAA06804; Fri, 23 Dec 1994 18:08:23 -0500
Date: Fri, 23 Dec 1994 18:08:23 -0500
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Mark T. Maybury" <maybury at linus.mitre.org>
Message-Id: <199412232308.SAA06804 at linus.mitre.org>
To: vcl at arch4.ho.att.com, joel at arch4.ho.att.com, sig11 at roses.stanford.edu,
uist.chi at xerox.com, tf-mm at i4serv.informatik.rwth-aachen.de,
ir-l%uccvma.bitnet at cunyvm.cuny.edu, s-comput%tcsvm.BITNET at cunyvm.cuny.edu,
smds at CNRI.Reston.VA.US, iplpdn at CNRI.Reston.VA.US, cip at bbn.com,
icad-request at santafe.edu, sigmedia at bellcore.com, sound at acm.org,
announcements.chi at xerox.com, tcplw at cray.com, arl at arl1.wustl.edu,
ccrc at dworkin.wustl.edu, g-troup at dworkin.wustl.edu,
f-troup at aurora.cis.upenn.edu, end2end-interest at venera.isi.edu,
atm at bbn.com, rem-conf at es.net, ietf at venera.isi.edu, tccc at cs.umass.edu
Subject: Intelligent Multimedia Information Retrieval
<<CALL FOR PAPERS>> <<CALL FOR PAPERS>> <<CALL FOR PAPERS>> <<CALL FOR PAPERS>>
<<CALL FOR PAPERS>> <<CALL FOR PAPERS>> <<CALL FOR PAPERS>> <<CALL FOR PAPERS>>
<<CALL FOR PAPERS>> <<CALL FOR PAPERS>> <<CALL FOR PAPERS>> <<CALL FOR PAPERS>>
IJCAI-95 Workshop on
INTELLIGENT MULTIMEDIA INFORMATION RETRIEVAL
Fourteenth International Joint Conference on Artificial Intelligence (IJCAI-95)
Montreal, Canada
1 day during 19th-21st August 1995 (to be determined)
BACKGROUND
In the past there has been concerted effort, largely performed in independent
research communities, addressing the automated processing of single media
(e.g., text, imagery, audio). The advent of large, multimedia digital
libraries has focused attention on the integrated processing and coordination
of multiple media including the traditional focus on textual sources and the
increasing emphasis on media with spatial and temporal properties (e.g.,
sound, maps, graphics, images, video). While there have been focused
workshops on integration and coordination of multimedia in interfaces and a
national conference on the general subject of multimedia, to date there has
been no targeted forum to address processing issues which cross media
boundaries but have a fundamental basis in processing human language and
artifacts.
OBJECTIVES
Research in this area is in the formative stages and is just now beginning to
address difficult fundamental problems, such as the representation and
reasoning about spatial and temporal media. IJCAI-95 presents an opportunity
to move toward an integrated view of media processing by addressing a
specific technical area: multimedia information retrieval. The language
processing, speech processing, image/video processing and spatial/temporal
reasoning communities have much to offer and much to learn from one another.
The purpose of this workshop is to bring together researchers and
practitioners to report on current advances in multimedia information
retrieval systems and their underlying theories, to foster scientific
interchange among these individuals, and as a group to evaluate current
efforts and make recommendations for future investigations. A report on the
workshop will be submitted to appropriate magazines (e.g., AI Magazine, IEEE
Expert, ACL's FINITE String). An edited collection to include the best
papers is planned.
ISSUES
Submissions (papers and/or video/computer demonstrations) are invited on
original research in all aspects of multimedia information retrieval,
including, but not limited to:
* Content-based analysis and retrieval of multimedia sources (e.g., parsing
and integrating text, imagery, maps, audio, video)
* Application of speech, language, and image processing methods and
techniques to multimedia (e.g., signal analysis, parsing, generation,
discourse and user modeling)
* Multimedia browsing/visualization tools and cross-media query
(e.g, visual, linguistic, and auditory)
* Multimedia document/presentation design and display
* Tailoring multimedia interaction to particular users, tasks, and contexts
* Intra- and inter-media representation languages
* Architectures for multimedia information retrieval
* Evaluation methods and metrics for multimedia information retrieval
* Psychoperceptual and cognitive issues in multimodal information retrieval
* Control of user's attention, tension, mood, and sense of continuity by
use of appropriate sound, color, and editing
* Innovative applications of multimedia information retrieval
SUBMISSIONS
Interested participants should e-mail (prefered) or forward FIVE copies of a
2,000 to 3,000 word position paper (4-5 pages, double spaced)
addressing a specific intelligent multimedia information retrieval
issue or reporting novel results to:
Mark Maybury, MS-K331, The MITRE Corporation, Bedford, MA 01730 Tel: (617)
271-7230. maybury at mitre.org
Submissions must be *received* by February 1, 1994. Please include
name, affiliation, address, phone, and e-mail address. Video
submissions should be complemented with a written abstract or position
paper. Criteria for selection will include clarity, orginality,
relevance, and significance of results. Attendance at the workshop
will be limited to approximately 30 participants. All participants must
register with the main IJCAI conference. The IJCAI WWW home pge is
http://ijcai.org/.
ORGANIZING COMMITTEE
Mark Maybury (chair) The MITRE Corporation, Bedford, MA
(maybury at mitre.org)
Bill Hefley, Software Engineering Institute, Carnegie Mellon Univ.
(weh at sei.cmu.edu)
Peter Schauble, Swiss Federal Institute of Technology, Zurich
(schauble at inf.ethz.ch)
Alex "Sandy" Pentland, MIT Media Lab (sandy at media.mit.edu)
Stephen Smoliar, Inst of Systems Science, Univ Singapore, 0511
(smoliar at iss.nus.sg)
Oliviero Stock, IRST, Italy (stock at irst.it)
Wolfgang Wahlster, DFKI, Germany (wahlster at dfki.uni-sb.de)
Kent Wittenburg, Bellcore (kentw at bellcore.com)
Kazuo Tanaka, NTT, Japan (tanaka at aether.ntt.JP)
Philippe Aigrain, IRIT, France (aigrain at cerise.irit.fr)
IJCAI SCHEDULE
December 1, 1994 -- Call for participation
February 1, 1995 -- Submission deadline
February 2, 1995 -- Allocation to reviewers
February 30, 1995 -- Notification of acceptance (via e-mail)
March 15, 1995 -- Camera-ready workshop paper due
April 5, 1995 -- Workshop schedule/participants finalized
May 5, 1995 -- Workshop notes due to CRC
???, 1995 -- IJCAI early registration deadline
???, 1995 -- IJCAI late registration deadline
August 19, 20, or 21 -- Workshop
November 1, 1995 -- Workshop report to Workshops Chair
----------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02281;
24 Dec 94 14:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02275;
24 Dec 94 14:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08705;
24 Dec 94 14:33 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02255;
24 Dec 94 14:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02168;
24 Dec 94 14:21 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa08540;
24 Dec 94 14:21 EST
Received: from [128.102.17.23] (edi_test.arc.nasa.gov [128.102.17.23]) by Mordor.Stanford.EDU (8.6.9/8.6.6) with SMTP id LAA19272; Sat, 24 Dec 1994 11:21:53 -0800
Message-Id: <v03000f00ab22226efb20 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 24 Dec 1994 11:21:56 -0800
To: Ian Duncan <id at cc.mcgill.ca>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: J'Accuse, ATM
Cc: ietf at CNRI.Reston.VA.US
At 2:33 PM 12/23/94, Ian Duncan wrote:
>CBR seems to me a bit of a boogie (or at the least straw or perhaps
>boondoggle) creature. All of the interesting information streams currently
>carried on traditional broadband (cable and telephony) are prime
>candidates for compression in the dawning era of $1/mip processors. These
>signals have highly variable entropy and, once compressed, won't fit nicely
>into standard N-bit tall pipes. To maximize BW utilization and minimize
>latency we'll need reasonably large and variable length packets with
>mechanisms for reservation of max-BW requirements and fast forwarding with
>predictable delays -- both in the realm of possiblity within near future
>IPv?.
thank you. this particular line of analysis has been remarkably missing
from the many discussions indulging in the religious enthusiasm over ATM,
along with the failure to note the fragmentation/reassembly overhead for
dealing with cells (which Jon raised in his earlier note.)
It isn't that ATM is bad and IP is good. It is that the degree of
religious fervor over ATM is bad and seems to be leading many folks to make
very poor operations decisions, "standardizing" on the promise of ATM,
rather than on its reality.
Anyone who builds a large-scale, VBR/CBR service based on IP, today, is
making just as big a mistake as anyone doing a VBR data network on ATM.
That is, both are mistakes.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01088;
4 Dec 94 8:26 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01084;
4 Dec 94 8:26 EST
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa03980;
4 Dec 94 8:26 EST
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA22151 on Sun, 4 Dec 94 06:18:19 -0500
Received: from isdmnl.wr.usgs.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA22147 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Sun, 4 Dec 94 06:18:17 -0500
Message-Id: <9412041118.AA22147 at mocha.bunyip.com>
Received: from annexport6.er.usgs.gov by ISDMNL.WR.USGS.GOV (MX V4.1 VAX) with
SMTP; Sun, 04 Dec 1994 03:18:09 PST
X-Sender: echristian at isdmnl.wr.usgs.gov
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 04 Dec 1994 06:21:46 -0500
To: Eliot Christian <echristi at usgs.gov>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eliot Christian <echristi at usgs.gov>
Subject: GILS Announcement 12/7 at DOI Auditorium
X-Mailer: <Windows Eudora Version 2.0.2>
(Sorry if you're getting this multiple times. This announcement is being
retransmitted due to many errors from mailers that could not handle the long
cc: list.)
DUE TO HEAVY DEMAND
GILS EVENT HAS BEEN MOVED TO
INTERIOR DEPARTMENT AUDITORIUM
Administration to Announce
Government Information Locator Service
(REVISED ANNOUNCEMENT)
On Wednesday, December 7, 1994, at 2:00 pm, in the
INTERIOR DEPARTMENT MAIN AUDITORIUM, 18th & C Sts.,
N.W., the Clinton Administration will take a major step
toward creating a Government Information Locator
Service (GILS) to help the public locate and access
information across the federal government. GILS will
identify public information resources, describe the
information, and help the public get it. It will
include a network of decentralized, agency-based
information locators. The public will use GILS
directly or through intermediaries such as libraries,
private information providers, and academic
institutions. It will ultimately be accessible through
various media including Internet, by dial-up from the
Commerce Department's FedWorld system, and from the
World Wide Web through the "Welcome to the White House"
server. On December 7th, at 2:00 pm:
* Commerce Deputy Secretary David J. Barram will
announce the initiative;
* Sally Katzen, Administrator of the Office of
Management and Budget's Office of Information and
Regulatory Affairs, will announce the issuance of
an OMB Bulletin to implement the GILS; and
* Ray Kammer, Deputy Director of the National
Institute of Standards and Technology, will
announce the promulgation of a Federal Information
Processing Standard for the GILS.
The event will also include a demonstration of the
GILS and statements by other officials and private
sector representatives.
IMPORTANT INFORMATION: This event does NOT require
preregistration--the DOI Auditorium will be open to the
press and public.
Eliot Christian, US Geological Survey, 802 National Center, Reston VA 22092
echristi at usgs.gov Phone(703)648-7245 FAX(703)648-7069
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17742;
21 Dec 94 23:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17738;
21 Dec 94 23:44 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22893;
21 Dec 94 23:44 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17731;
21 Dec 94 23:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17727;
21 Dec 94 23:44 EST
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa22888;
21 Dec 94 23:44 EST
Received: from dbc.mtview.ca.us by dbc.mtview.ca.us (5.65/3.1.090690)
id AB14250; Wed, 21 Dec 94 20:44:12 -0800
Date: Wed, 21 Dec 1994 20:44:01 -0800
Message-Id: <14243.788071441.1 at dbc.mtview.ca.us>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: mrose.iesg at CNRI.Reston.VA.US
X-Orig-Sender: mrose at dbc.mtview.ca.us
Subject: Re: NetMetrix Power Agent Description (long)
Mime-Version: 1.0
Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa"
Content-Description: Blind Carbon Copy
------- =_aaaaaaaaaa
Content-Type: message/rfc822
Content-Description: Original Message
From: IETF NM-AD <mrose.iesg at dbc.mtview.ca.us>
To: venkat at nashua.hp.com (Venkat Rangan)
cc: rmonmib at muddcs.cs.hmc.edu
Subject: Re: NetMetrix Power Agent Description (long)
In-reply-to: Your message of "Wed, 21 Dec 1994 19:15:17 EST."
<9412220015.AA12274 at baldy.metrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14241.788071440.1 at dbc.mtview.ca.us>
Date: Wed, 21 Dec 1994 20:44:01 -0800
Message-ID: <14243.788071441 at dbc.mtview.ca.us>
Sender: mrose at dbc.mtview.ca.us
[ please note the From: line ]
> Copyright Disclaimer
> --------------------
>
> This document and the accompanying MIB is provided to the RMON2
> Working Group with the intent that certain concepts and MIB organization
> be incorporated into the RMON2 standard. These documents will be
> Copyrighted by Hewlett-Packard Company, 1991-1994 until the time they
> are included in the standard, and into the future, if they are not included.
This is unacceptable.
If you, and/or your company, wish to participate in the IETF, then you
play by the IETF's rules. One of our rules says that WGs produce
Internet-Drafts, which may, or may not, be elevated by the IESG to the
Internet standards track.
According to your text above, if the WG produces an I-D with this
material, then you assert copyright on that I-D. I don't think so.
I hereby direct the WG to disregard your message.
If you wish to repost your message without the above text, please do so.
In that case, the WG will give your message all due consideration,
without prejudice.
/mtr
IETF Area Director for Network Management
------- =_aaaaaaaaaa--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00506;
28 Dec 94 4:03 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00500;
28 Dec 94 4:03 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01088;
28 Dec 94 4:02 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00471;
28 Dec 94 4:02 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12392;
27 Dec 94 23:08 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa13334; 27 Dec 94 23:08 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-24.dialip.mich.net [35.1.48.225]) by merit.edu (8.6.9/merit-2.0) with SMTP id XAA17432 for <ietf at CNRI.Reston.VA.US>; Tue, 27 Dec 1994 23:08:35 -0500
Date: Tue, 27 Dec 94 20:32:40 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3593.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: J'Accuse, ATM
> From: Scott Brim <swb1 at cornell.edu>
> At 05:11 12/22/94, Jon Crowcroft wrote:
> >However, this technology has not been slected on the basis of
> >good, fair and proper evaluation. In fact, when talking to anyone
> >who has tried using it for computer-computer communciations, I have
> >yet to find someone who has positive things to say.
>
> >And yet at demonstrations in the RACE and other European research
> >programs, and in the gigabit programs in the US, behind the scenes,
> >under their breath, and so on, people are saying how painful this
> >technology is.
>
> Yes, in the past the switches were uniformly awful. They are certainly
> better than they used to be. I would say at least one is now
> acceptable.
>
I agree that the switches were uniformly awful.
Could you please identify the one acceptable vendor? This is the IETF,
after all; we want real result reports, not platitudes.
> What's new is the speed, so the bandwidth*delay exceeds thresholds we
> never even dreamed of on X.25.
What's new about the speed? The switches I've viewed all had worse
throughput than FDDI. We have plenty of experience with FDDI.
> For sure. That's the important question. Since there is so much
> motivation for the new internet applications, and so much motivation
> for a cost-saving technology like ATM, how can we make the two work
> together. Technically it's ugly, but that is not the overwhelming
> issue.
> ...
> Again, I agree, these are poor reasons. I don't know *anyone* who is
> planning on deploying ATM because of its technical superiority.
> ...
> Frankly, from what I can see there are now as many smart people in the
> ATM Forum as there are in the IETF, even in absolute numbers.
>
If no technical superiority, then no matter how brilliant those people,
they've done a bad job. Fire them.
> >Why should we have to put up with this?
>
> Money. (1) people want to use it because it saves them money;
> providers want to install it because it saves them money.
Where? How? When?
For local area nets, FDDI (which is still too expensive, and being
replaced by cheaper 100baseX) is vastly cheaper than ATM at each node,
on a ratio of 10:1. The small switches are more expensive than hubs by
800:1. The bigger switches are simply out of this world.
For WANs, where can you provision SONET/SDH? How did you arrive at your
savings, compared to what other tariff?
> (2) perhaps
> you're having trouble getting grants for other things? Otherwise I
> can't imagine why you would feel obligated to make IP work over ATM.
> You could just ignore it and let the providers who deploy it sink into
> oblivion.
>
I agree. After all the hoopla, I don't see why we are bothering with
IP over ATM. Let's ignore it until it has more deployment by providers
than ISDN. Let's watch the ATM vendors go bankrupt, just as they did
with ISDN.
> ...Scott, who will be out of touch Saturday-Saturday
>
This is different than some other time of year? (that's sarcastic
humor, folks.)
Bill.Simpson at um.cc.umich.edu
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04026;
28 Dec 94 17:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08004;
28 Dec 94 17:35 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03969;
28 Dec 94 17:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03814;
28 Dec 94 17:25 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa07805;
28 Dec 94 17:25 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA11721>; Wed, 28 Dec 1994 14:25:54 -0800
Message-Id: <199412282225.AA11721 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1750 on Randomness Recommendations for Security
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 28 Dec 94 14:26:54 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1750:
Title: Randomness Recommendations for Security
Author: D. Eastlake, 3rd, S. Crocker & J. Schiller
Date: December 1994
Mailbox: dee at lkg.dec.com, crocker at cybercash.com,
jis at mit.edu
Pages: 25
Characters: 73,842
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1750.txt
Security systems today are built on increasingly strong cryptographic
algorithms that foil pattern analysis attempts. However, the security
of these systems is dependent on generating secret quantities for
passwords, cryptographic keys, and similar quantities. The use of
pseudo-random processes to generate secret quantities can result in
pseudo-security. The sophisticated attacker of these security systems
may find it easier to reproduce the environment that produced the
secret quantities, searching the resulting small set of possibilities,
than to locate the quantities in the whole of the number space.
Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This paper points out many
pitfalls in using traditional pseudo-random number generation
techniques for choosing such quantities. It recommends the use of
truly random hardware techniques and shows that the existing hardware
on many systems can be used for this purpose. It provides suggestions
to ameliorate the problem when a hardware solution is not available.
And it gives examples of how large such quantities need to be for some
particular applications.
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-REQUEST at NIC.DDN.MIL.
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: <941228142400.RFC at ISI.EDU>
SEND /rfc/rfc1750.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1750.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941228142400.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04027;
28 Dec 94 17:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08002;
28 Dec 94 17:35 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03970;
28 Dec 94 17:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03736;
28 Dec 94 17:15 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa07602;
28 Dec 94 17:15 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA11357>; Wed, 28 Dec 1994 14:15:41 -0800
Message-Id: <199412282215.AA11357 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1748 on IEEE 802.5 MIB using SMIv2
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 28 Dec 94 14:16:41 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1748:
Title: IEEE 802.5 MIB using SMIv2
Author: K. McCloghrie & E. Decker
Date: December 1994
Mailbox: kzm at cisco.com, cire at cisco.com
Pages: 25
Characters: 43,224
Obsoletes: 1743, 1231
URL: ftp://ds.internic.net/rfc/rfc1748.txt
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing
subnetworks which use the IEEE 802.5 Token Ring technology described
in 802.5 Token Ring Access Method and Physical Layer Specifications,
IEEE Standard 802.5-1989. This memo is a replacement for RFC 1231.
This RFC is a product of the Interfaces MIB 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-REQUEST at NIC.DDN.MIL.
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: <941228141431.RFC at ISI.EDU>
SEND /rfc/rfc1748.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1748.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941228141431.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04028;
28 Dec 94 17:35 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08003;
28 Dec 94 17:35 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03971;
28 Dec 94 17:35 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03763;
28 Dec 94 17:21 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa07715;
28 Dec 94 17:21 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA11507>; Wed, 28 Dec 1994 14:21:53 -0800
Message-Id: <199412282221.AA11507 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1749 on 802.5 Station Source Routing MIB using SMIv2
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 28 Dec 94 14:22:53 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1749:
Title: IEEE 802.5 Station Source Routing MIB using SMIv2
Author: K. McCloghrie, F. Baker & E. Decker
Date: December 1994
Mailbox: kzm at cisco.com, fred at cisco.com, cire at cisco.com
Pages: 10
Characters: 17,563
Updates: 1748
URL: ftp://ds.internic.net/rfc/rfc1749.txt
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used by IEEE 802.5
end-stations for managing source routes on a Token Ring network where
IEEE source-routing is in use. IEEE source-routing is described in
802.5 Token Ring Access Method and Physical Layer Specifications and
related ISO publications. This memo is an incremental update to RFC
1748. It is documented separately from the RFC 1748 solely due to the
latter's maturity within the Internet standardization process. This
RFC is the product of the Interfaces MIB 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-REQUEST at NIC.DDN.MIL.
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: <941228141736.RFC at ISI.EDU>
SEND /rfc/rfc1749.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1749.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941228141736.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05567;
28 Dec 94 22:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05561;
28 Dec 94 22:46 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13659;
28 Dec 94 22:46 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05552;
28 Dec 94 22:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05520;
28 Dec 94 22:43 EST
Received: from inesc.inesc.pt by CNRI.Reston.VA.US id aa13584;
28 Dec 94 22:43 EST
Received: from jaguar.inesc.pt by inesc.inesc.pt with SMTP;
id AA08819 (/); Thu, 29 Dec 1994 04:42:48 +0100
Received: by jaguar.inesc.pt (4.1/SMI-4.1-940129)
id AA05749; Thu, 29 Dec 94 04:43:53 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Pedro Ramalho Carlos <Pedro.R.Carlos at inesc.pt>
Message-Id: <9412290343.AA05749 at jaguar.inesc.pt>
Subject: Re: J'Accuse, ATM
To: bsimpson at morningstar.com
Date: Thu, 29 Dec 1994 04:43:52 +0100 (MET)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <3593.bill.simpson at um.cc.umich.edu> from "William Allen Simpson" at Dec 27, 94 08:32:40 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 1840
Dear All
William Allen Simpson writes:
> > From: Scott Brim <swb1 at cornell.edu>
> > At 05:11 12/22/94, Jon Crowcroft wrote:
[...]
>
> For WANs, where can you provision SONET/SDH? How did you arrive at your
> savings, compared to what other tariff?
I've been wondering for some time now about how long it will take until some
carrier starts provisioning direct SONET/SDH service, and if they take too
long can one imagine reasonably priced SONET/SDH DSU's to use over (reasonably
priced ;-) black fiber? Is anyone considering this at some of the
Testbeds/Backbones in the US? Or is CBR ATM a good enough fat pipe for now?
>
> > (2) perhaps
> > you're having trouble getting grants for other things? Otherwise I
> > can't imagine why you would feel obligated to make IP work over ATM.
> > You could just ignore it and let the providers who deploy it sink into
> > oblivion.
> >
> I agree. After all the hoopla, I don't see why we are bothering with
> IP over ATM. Let's ignore it until it has more deployment by providers
> than ISDN. Let's watch the ATM vendors go bankrupt, just as they did
> with ISDN.
Well... Jon is in Europe in the research community, and I don't think
that he can just forget about ATM here... The EC research programs are very
(perhaps I should say "totally and religiously") focused on ATM, and
it certainly seems to be more than just a feeling that if you want a grant
then ATM has to be somewhere in the project.
I think that Jon's message was in part a consequence of that pressure...
(In fact it was quite useful to have that explicit message to trigger a
long due discussion inside our own organisation :-) thanks Jon!)
Season's Greetings
---
pedro ramalho carlos email: prc at inesc.pt INESC
tel: +351-1-3100050 Av. Duque de Avila, 23
fax: +351-1-3100008 1017 Lisboa Codex - PORTUGAL
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12923;
29 Dec 94 2:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12917;
29 Dec 94 2:38 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18064;
29 Dec 94 2:38 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12905;
29 Dec 94 2:38 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12879;
29 Dec 94 2:35 EST
Received: from cesium.clock.org by CNRI.Reston.VA.US id aa18016;
29 Dec 94 2:35 EST
Received: by cesium.clock.org id <5793>; Thu, 29 Dec 1994 02:35:53 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Sean Doran <smd at cesium.clock.org>
To: Pedro.R.Carlos at inesc.pt, bsimpson at morningstar.com
Subject: Re: J'Accuse, ATM
Cc: ietf at CNRI.Reston.VA.US
Message-Id: <94Dec29.023553est.5793 at cesium.clock.org>
Date: Thu, 29 Dec 1994 02:35:43 -0800
Don't shoot me for using a disclaimer asking people on the IETF
list not to ask my bosses to shoot me for saying things that might not
be officially endorsed by them (even though I post such things from my
account here rather than at work), but I had a recent nasty experience
that I'd rather not see repeated... :(
| I've been wondering for some time now about how long it will take until some
| carrier starts provisioning direct SONET/SDH service, and if they take too
| long can one imagine reasonably priced SONET/SDH DSU's to use over (reasonably
| priced ;-) black fiber? Is anyone considering this at some of the
| Testbeds/Backbones in the US? Or is CBR ATM a good enough fat pipe for now?
There is at least one large IP backbone in the USA actively looking at
SONET/SDH as a step up from clearchannel DS3 or multiple clearchannel
DS3s as a way of avoiding some of the problems inherent in IP/ATM
interoperability in the time frame before the ATM Forum puts forth its
solutions and hardware vendors implement them.
However, at the same time, to abuse a quote from a colleague, "ATM is
amazing" is a pretty common mindset. Amazing or not, if it works and
it becomes possible to push lots and lots of IP datagrams across ATM
as reliably as over clearchannel DS3s and with no worries whatsoever
then that same large backbone provider will certainly use ATM.
Currently that reliability is unproven and there are lots of worries...
As to the other questions, phone companies tend to sell what people
are willing to spend money on. If people are willing to spend money
on ATM (working or not) then phone companies will sell ATM. If people
are willing to spend money on SONET/SDH then that will get offered
also. The people in question can be infrastructure-buying customers
or agencies wanting to do experimental data networking (like DARPA or
the NSF).
Pricing will generally be set to recover costs plus a percentage in
the short run and then will drop as economies of scale are discovered
(especially on the hardware side) and competition ramps up, pace
the activities of various regulatory or tariff bodies.
Sean.
- --
Sean Doran <smd at clock.org> (at home) / <smd at sprint.net> (at work)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01640;
29 Dec 94 9:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01633;
29 Dec 94 9:21 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06610;
29 Dec 94 9:21 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01593;
29 Dec 94 9:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01501;
29 Dec 94 9:08 EST
Received: from THIALFI.CS.CORNELL.EDU by CNRI.Reston.VA.US id aa06121;
29 Dec 94 9:08 EST
Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99G)
id AA29064; Thu, 29 Dec 94 09:08:32 -0500
Received: from GUNGNIR.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99F)
id AA01891; Thu, 29 Dec 94 09:08:35 -0500
Message-Id: <9412291408.AA19852 at gungnir.cs.cornell.edu>
Received: by gungnir.cs.cornell.edu (5.67/N-0.13aa)
id AA19852; Thu, 29 Dec 94 09:08:30 -0500
To: Sean Doran <smd at cesium.clock.org>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
In-Reply-To: Your message of "Thu, 29 Dec 1994 02:35:43 PST."
<94Dec29.023553est.5793 at cesium.clock.org>
Date: Thu, 29 Dec 1994 09:08:30 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Werner Vogels <vogels at cs.cornell.edu>
> | I've been wondering for some time now about how long it will take until some
> | carrier starts provisioning direct SONET/SDH service, and if they take too
> | long can one imagine reasonably priced SONET/SDH DSU's to use over (reasonably
> | priced ;-) black fiber? Is anyone considering this at some of the
> | Testbeds/Backbones in the US? Or is CBR ATM a good enough fat pipe for now?
>
> There is at least one large IP backbone in the USA actively looking at
> SONET/SDH as a step up from clearchannel DS3 or multiple clearchannel
> DS3s as a way of avoiding some of the problems inherent in IP/ATM
> interoperability in the time frame before the ATM Forum puts forth its
> solutions and hardware vendors implement them.
Sean, your follow-up has got me puzzled: SONET/SDH and ATM live in different
architecture layers: SONET/SDH provides only a physical pipe, no switching,
while ATM is a just a switching technology without any physical
characteristics. Viewing ATM to run over SONET/SDH is more appropriate.
--
Werner
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04500;
29 Dec 94 13:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12380;
29 Dec 94 13:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04454;
29 Dec 94 13:17 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04284;
29 Dec 94 13:11 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12148;
29 Dec 94 13:11 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA06990>; Thu, 29 Dec 1994 10:11:22 -0800
Message-Id: <199412291811.AA06990 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1751 on Human-Readable 128-bit Keys
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 29 Dec 94 10:12:22 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1751:
Title: A Convention for Human-Readable 128-bit Keys
Author: D. McDonald
Date: December 1994
Mailbox: danmcd at itd.nrl.navy.mil
Pages: 15
Characters: 31,428
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1751.txt
The Internet community has begun to address matters of security.
Recent standards, including version 2 of SNMP, have explicit
requirements for an authentication mechanism. These require use of a
keyed message-digest algorithm, MD5, with a key size of 128-bits. A
128-bit key, while sufficiently strong, is hard for most people to
read, remember, and type in. This memo proposes a convention for use
with Internet applications and protocols using 128-bit cryptographic
keys.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
the 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-REQUEST at NIC.DDN.MIL.
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: <941229100852.RFC at ISI.EDU>
SEND /rfc/rfc1751.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1751.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941229100852.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04505;
29 Dec 94 13:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12379;
29 Dec 94 13:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04453;
29 Dec 94 13:17 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04243;
29 Dec 94 13:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12086;
29 Dec 94 13:08 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04235;
29 Dec 94 13:08 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: Interfaces MIB
Date: Thu, 29 Dec 94 13:08:37 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9412291308.aa04235 at IETF.CNRI.Reston.VA.US>
With the publication of RFC 1749, IEEE 802.5 Station Source Routing MIB
using SMIv2, the Interfaces MIB Working Group of the Network Management
Area has concluded.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09140;
29 Dec 94 18:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21135;
29 Dec 94 18:12 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09127;
29 Dec 94 18:12 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09025;
29 Dec 94 18:07 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-iab-assignment-guidance-00.txt
Date: Thu, 29 Dec 94 18:07:01 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9412291807.aa09025 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Architecture Board.
Title : Guidance in the Assignment of Internet Numbers
Author(s) : E. Gerich
Filename : draft-iab-assignment-guidance-00.txt
Pages : 3
Date : 12/28/1994
The IAB suggest that while RFC 1597 establishes reserved IP address space
for the use of private networks which are isolated and will remain isolated
from the Internet, any enterprise which anticipates external connectivity
to the Internet should apply for a globally unique address from an Internet
registry, or a service provider.
Comments on this draft should be sent to <iab at isi.edu>.
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-iab-assignment-guidance-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-iab-assignment-guidance-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iab-assignment-guidance-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19941228170503.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-iab-assignment-guidance-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-iab-assignment-guidance-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941228170503.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09537;
29 Dec 94 19:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22107;
29 Dec 94 19:00 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09526;
29 Dec 94 19:00 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09013;
29 Dec 94 18:07 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-iab-rfc-not-std-00.txt
Date: Thu, 29 Dec 94 18:06:59 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9412291807.aa09013 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Architecture Board.
Title : Not All RFCs are Standards
Author(s) : C. Huitema, J. Postel, S. Crocker
Filename : draft-iab-rfc-not-std-00.txt
Pages : 3
Date : 12/28/1994
This document discusses the relationship of the Request for Comments (RFCs)
notes to Internet Standards.
Comments on this draft should be sent to "iab at isi.edu".
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-iab-rfc-not-std-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-iab-rfc-not-std-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iab-rfc-not-std-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19941228171056.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-iab-rfc-not-std-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-iab-rfc-not-std-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19941228171056.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10308;
29 Dec 94 20:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10302;
29 Dec 94 20:32 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24098;
29 Dec 94 20:32 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10290;
29 Dec 94 20:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10258;
29 Dec 94 20:29 EST
Received: from darpa.mil by CNRI.Reston.VA.US id aa24022; 29 Dec 94 20:29 EST
Received: from [192.48.218.154] (next154.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5)
id <AA13798>; Thu, 29 Dec 1994 20:29:18 -0500
Date: Thu, 29 Dec 1994 20:29:18 -0500
Message-Id: <199412300129.AA13798 at vax.darpa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Guy Almes <almes at ans.net>, Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Thomas A. Kalil" <tkalil at arpa.mil>
Subject: Re: J'Accuse, ATM
Cc: ietf at CNRI.Reston.VA.US
Dear IETFers:
The G-7 governments (U.S., Japan, Germany, Italy, France, U.K., Canada +
the European Commission) are considering promoting int'l "interoperability
testbeds" -- possibly building on existing national efforts.
[This is in the context of a G7 summit on the Global Information Society that
will be held in Brussels in February 1995. Other applications that the
G7 may cooperate on include e-commerce, environmental monitoring, a
Web-based, global inventory of projects, digital libraries & museums,
telemedicine, &
training and education.]
One idea under consideration is a testbed that would promote multi-vendor
interoperability for ATM signalling, traffic management, and IP over ATM.
Since there is some concern that the governments not mandate ATM -- I'd
be interested to know what other technologies the governments should
consider sponsoring for research/testbed activities to advance
high-speed, wide-area networking.
Thanks!
****************************************************************************
Thomas Kalil "The NII - just do it!"
tkalil at arpa.mil
National Economic Council
The White House
Washington DC 20500
(p) 202-456-2802
(f) 202-456-2223
"Your taxpayer dollars at work."
****************************************************************************
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13481;
29 Dec 94 23:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13475;
29 Dec 94 23:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26819;
29 Dec 94 23:01 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13463;
29 Dec 94 23:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13420;
29 Dec 94 22:57 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa26747;
29 Dec 94 22:57 EST
Received: from [128.102.17.23] (edi_test.arc.nasa.gov [128.102.17.23]) by Mordor.Stanford.EDU (8.6.9/8.6.6) with SMTP id TAA05807; Thu, 29 Dec 1994 19:58:02 -0800
Message-Id: <v03000f03ab292c5aa8e6 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 29 Dec 1994 19:58:06 -0800
To: "Thomas A. Kalil" <tkalil at arpa.mil>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: J'Accuse, ATM
Cc: ietf at CNRI.Reston.VA.US
Tom,
Thanks for the query. Interesting set of tasks...
At 5:29 PM 12/29/94, Thomas A. Kalil wrote:
>will be held in Brussels in February 1995. Other applications that the
>G7 may cooperate on include e-commerce, environmental monitoring, a
>Web-based, global inventory of projects, digital libraries & museums,
>telemedicine, & training and education.]
>
>One idea under consideration is a testbed that would promote multi-vendor
>interoperability for ATM signalling, traffic management, and IP over ATM.
>
>Since there is some concern that the governments not mandate ATM -- I'd
More generally, I would suggest that there NOT be a great focus on media
and media access methods (anyone who doesn't like those terms may
substitute something generic, like "lower layers") in that they get plenty
of attention, money, and work on their own.
Looking at your list earlier in the message, it occurs to me that the major
interoperability problems, these days, come from "systems" level issues.
Hence, management and practical large-scale information interoperability
are examples. Internet-wide (cross-provider) performance management is a
current favorite of mine.
E-commerce is a 'systems' issue which runs counter to my comment. I'm
guessing that it is going to be a problem by virtue of TOO MANY deployed,
different specs, rather than too little attention. The issue in this
latter case won't be interoperability testing, it will be survival of the
fittest, I fear. In the case of the Web, there I'd guess that it's
popularity and flexibility are making it too easy for pair-wise conventions
between different users and different clients, so that a trend towards
interoperability problems is likely; sounds like a good candidate for your
efforts.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker at mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18486;
30 Dec 94 2:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18480;
30 Dec 94 2:04 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00683;
30 Dec 94 2:04 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18469;
30 Dec 94 2:03 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18442;
30 Dec 94 2:01 EST
Received: from piraya.electrum.kth.se by CNRI.Reston.VA.US id aa00620;
30 Dec 94 2:00 EST
Received: from beppe.electrum.kth.se by piraya.electrum.kth.se (5.61-bind 1.4+ida/4.0)
id AA15845; Fri, 30 Dec 94 08:00:38 +0100
Message-Id: <9412300700.AA15845 at piraya.electrum.kth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: binary
Date: Fri, 30 Dec 1994 08:03:36 +0100
To: "Thomas A. Kalil" <tkalil at arpa.mil>, Guy Almes <almes at ans.net>,
Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bjorn Pehrson <bjorn at it.kth.se>
Subject: Re: J'Accuse, ATM
Cc: ietf at CNRI.Reston.VA.US, tslab at it.kth.se
At 20.29 94-12-29 -0500, Thomas A. Kalil wrote:
>Since there is some concern that the governments not mandate ATM -- I'd
>be interested to know what other technologies the governments should
>consider sponsoring for research/testbed activities to advance
>high-speed, wide-area networking.
Thomas,
We are exploring a fast circuit switching concept, Dynamic synchronous
Transfer Mode (DTM), which would be a candidate to be tested in such a
testbed. Our current testbed is sponsored entirely by industry.
Publications available via our Web-server
http://www.it.kth.se/TSlab/DTM/pub.html
include
- L. Gauffin, B. Pehrson, "Will Fast Circuit-switching Replace ATM?", In
Proc. Interop, Berlin, Germany, June 1994, The paper discusses Fast Circuit
Switching as an alternative to ATM in future public networks.
- C. Bohm, P. Lindgren, L. Ramfelt, P. Sjodin, "The DTM Gigabit Network", In
Journal of High Speed Networks, Vol. 3, No. 2, 1994. This paper is a
comprehensive description of the DTM network and protocols. The paper also
describes the prototype implementation. New protocol primitives for
implementing multicast and broadcast mechanisms in the network are
discussed.
---------------------------
> Dear IETFers:
>
>The G-7 governments (U.S., Japan, Germany, Italy, France, U.K., Canada +
>the European Commission) are considering promoting int'l "interoperability
>testbeds" -- possibly building on existing national efforts.
>
>[This is in the context of a G7 summit on the Global Information Society that
>will be held in Brussels in February 1995. Other applications that the
>G7 may cooperate on include e-commerce, environmental monitoring, a
>Web-based, global inventory of projects, digital libraries & museums,
>telemedicine, &
>training and education.]
>
>One idea under consideration is a testbed that would promote multi-vendor
>interoperability for ATM signalling, traffic management, and IP over ATM.
>
>Since there is some concern that the governments not mandate ATM -- I'd
>be interested to know what other technologies the governments should
>consider sponsoring for research/testbed activities to advance
>high-speed, wide-area networking.
>
>Thanks!
>
>
>****************************************************************************
>Thomas Kalil "The NII - just do it!"
>tkalil at arpa.mil
>National Economic Council
>The White House
>Washington DC 20500
>(p) 202-456-2802
>(f) 202-456-2223
>
>"Your taxpayer dollars at work."
>****************************************************************************
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01670;
30 Dec 94 9:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01664;
30 Dec 94 9:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06780;
30 Dec 94 9:49 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01585;
30 Dec 94 9:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01373;
30 Dec 94 9:32 EST
Received: from sics.se by CNRI.Reston.VA.US id aa06484; 30 Dec 94 9:32 EST
Received: from matsb.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4)
with SMTP id AA22213; Fri, 30 Dec 94 15:09:19 +0100
Date: Fri, 30 Dec 94 15:09:19 +0100
Message-Id: <9412301409.AA22213 at sics.se>
X-Mime-Version: 1.0
X-Content-Type: text/plain; charset="us-ascii"
To: "Thomas A. Kalil" <tkalil at arpa.mil>, Guy Almes <almes at ans.net>,
Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mats Brunell <matsb at sics.se>
Subject: Re: J'Accuse, ATM
Cc: ietf at CNRI.Reston.VA.US
At 20.29 94-12-29 -0500, Thomas A. Kalil wrote:
>The G-7 governments (U.S., Japan, Germany, Italy, France, U.K., Canada +
>the European Commission) are considering promoting int'l "interoperability
>testbeds" -- possibly building on existing national efforts.
The question is what taxpayers money really should be spent on.
Given the information I have have from the US the market has seen the light
of the information infrastructure. And there is enough risk capital to
drive teh development from those revenues. At least some of the main
telecom players have also seen that there is a lack of technology
solutions.
Many are planning increased capacity networks in towns and internationally.
What part of this research or trials should be funded by the industry or by
taxpayers money? It is not a simple question.
The question is whether the right technology will be choosen. It is not a
political issue today (or ever?), it is a strict technical issue. The worst
situation is if the G7 group thinks is shall adopt ATM or any other
technology at this point in time. Testbeds are being built "everywhere"
based on ATM, (and the results are not pointing to ATM as _the_ solution,
rather the opposite). IP is, and will be the main protocol as it also
integrates other carrier technologies (X.25, ISDN, leased lines, radio etc)
as well as LAN technologies, Ethernet, FDDI, Cable TV etc.
The issue at hand is to set the real requirements for a set of new
solutions ranging from access methods, carrier technologies, LAN
technologies, protocol support etc for a _global_ scalable infratructur.
The real mistake would be to say that ISDN or ATM (or anything else that is
available for that matter) as technology should be _the_ basis for the
future on any political level. It is simply to early. We have the
IP/Internetworking solution to integrate on today. ANy other technology
shoudl be able to compete on equal terms and fight its way based on sound
technical merits. Political solution in the history in the telecomm field
such as X.25 and ISDN has not proven to solve the technical problems nor
reaced the global level as it is not suited technically. Everyone looses.
Even worse if my taxpayers money is put into it.
My very personal suggestion is to promote a set of competing activities
where the best peole gets a chance to work togheter and we will see a set
of soultions that can be tried over the next years. These programs can not
be politically "directed". It is combination of intelligent feel for
risking money on good research and good industry related development, and
having the right people involved of cource. No committees please!
Anyhow, I hope you bear in mind that any actions taken must not subsidize a
single or only few teleoperators or company...
--mats
--------------------------------------------------------------------------
Mats Brunell
SICS
Box 1263 Tel: +46 8 752 15 63 Mobile: +10 668 22 46
S-164 28 Kista Fax: +46 8 751 72 30
Internet: Mats.Brunell at sics.se
--------------------------------------------------------------------------
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04934;
30 Dec 94 14:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14343;
30 Dec 94 14:54 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04909;
30 Dec 94 14:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04751;
30 Dec 94 14:38 EST
Received: from [128.9.160.160] by CNRI.Reston.VA.US id aa13890;
30 Dec 94 14:38 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA12776>; Fri, 30 Dec 1994 11:38:23 -0800
Message-Id: <199412301938.AA12776 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1746 on Ways to Define User Expectations
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 30 Dec 94 11:39:24 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1746:
Title: Ways to Define User Expectations
Author: B. Manning & D. Perkins
Date: December 1994
Mailbox: bmanning at isi.edu, dperkins at tenet.edu
Pages: 18
Characters: 46,176
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1746.txt
This paper covers basic fundamentals that must be understood when
one defines, interprets, or implements methods to control user
expectations on or over the Internet. This RFC is the product of the
Internet School Networking 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-REQUEST at NIC.DDN.MIL.
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: <941230113702.RFC at ISI.EDU>
SEND /rfc/rfc1746.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1746.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <941230113702.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06943;
30 Dec 94 21:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06937;
30 Dec 94 21:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22402;
30 Dec 94 21:00 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06925;
30 Dec 94 21:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06890;
30 Dec 94 20:56 EST
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa22296;
30 Dec 94 20:55 EST
Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14605(7)>; Fri, 30 Dec 1994 17:53:32 PST
Received: by redwing.parc.xerox.com id <57153>; Fri, 30 Dec 1994 17:53:07 -0800
Date: Fri, 30 Dec 1994 17:53:01 PST
X-Orig-Sender: Lixia Zhang <lixia at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Lixia Zhang <lixia at parc.xerox.com>
To: "Thomas A. Kalil" <tkalil at arpa.mil>
Cc: Guy Almes <almes at ans.net>, Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>,
ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
In-Reply-To: Your message of Thu, 29 Dec 1994 17:29:18 -0800
Message-ID: <CMM.0.88.788838781.lixia at parc.xerox.com>
> Since there is some concern that the governments not mandate ATM -- I'd
> be interested to know what other technologies the governments should
> consider sponsoring for research/testbed activities to advance
> high-speed, wide-area networking.
I'd like to add on Mats comments.
To advance high-speed, wide-area, internetworking, we need more
research on the protocol architecture, rather than focusing on a
particular technology.
ATM is a particular switching technology.
As any new technology, it comes and it also goes. Unless we stop
research, new technologies will keep coming on horizon (e.g. how many
talks have we heard lately about wavelength-division optical
networks).
As a specific technology, ATM does not fit well with all different
media; for example, in a wireless mobile environment where bandwidth
is scare resource, the tiny ATM cell size does not seem a sensible
engineering choice.
As a specific technology, it will not have a 100% penetration to cover
all networkland--it may make a nice subnet technology, a LAN or a
backbone, here or there, but personally I just dont see ATM as the way
of providing ubiquitous connectivity.
(I even wouldnt bother to mention how poorly ATM protocol was
designed)
IP has taught us that there will never be one single technology, and
that's why IP was invented, as a glue to hook up all different network
technologies for a global internet. I recall a talk by Vint Cerf I
heard over the net a while ago, where Vint pointed out that when IP was
being developed the underneath subnet technologies were ARPANET, PRnet
(packet radio), and 3Mbps Ethernet (perhaps SATnet too?). Now almost
20 years down the road, none of those networks exists anymore, yet IP
is enjoying an ever faster growth, reaching out to cover the whole
world. This is the kind of research that I'd like to see my tax
dollars spent on.
We need to worry about the *infrastructure* of the future global
internet, issues like system robustness, scalability, and
heterogeneity (of the underneath technologies); let the industry and
market take care of technologies. As long as we do our IP/IPng right,
we'll just run IP on top of whatever technology they happen to provide
for the day.
Lixia
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02596;
31 Dec 94 14:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02590;
31 Dec 94 14:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11005;
31 Dec 94 14:28 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02563;
31 Dec 94 14:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02446;
31 Dec 94 14:11 EST
Received: from goshawk.lanl.gov by CNRI.Reston.VA.US id aa10736;
31 Dec 94 14:11 EST
Received: from localhost.lanl.gov (localhost.lanl.gov [127.0.0.1]) by goshawk.lanl.gov (8.6.9/8.6.4) with SMTP id MAA17161; Sat, 31 Dec 1994 12:11:22 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Peter S. Ford" <peter at goshawk.lanl.gov>
Message-Id: <199412311911.MAA17161 at goshawk.lanl.gov>
X-Authentication-Warning: goshawk.lanl.gov: Host localhost.lanl.gov didn't use HELO protocol
To: lixia at parc.xerox.com, matsb at sics.se
cc: "Thomas A. Kalil" <tkalil at arpa.mil>, ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
In-reply-to: Your message of Fri, 30 Dec 94 17:53:01 -0800.
<CMM.0.88.788838781.lixia at parc.xerox.com>
Date: Sat, 31 Dec 94 12:11:21 MST
Mats and Lixia,
I think you are missing a lesson from history when you push back on in
government involvement in the development of a global, scalable
infrastructure. The Internet is a case study in the effective use of
"testbeds" brought about by government involvement. This is one of the
big reasons you see industry *asking* governments to support testbeds.
Many people believe that one of the reasons the Internet
experience has been successful is that it forced deployment and testing
of technologies with a keen focus on interoperability. Many of these
people believe this was THE major reason GOSIP(s) failed. Compare:
The technologies of the future are listed in this GOSIP
document
with
The following network(backbone) is being built, and if you run this
set of protocols you may have interconnectivity with
a large set of people/machines you are interested in
talking to.
Both of these are effectively what voices in the U.S. government
said at about the same time. And, I don't think this was unique to the U.S.
Testbeds are just that, testbeds. If they indicate that some technology
is not up to snuff, that is a great result. I would rather see real
results from a testbed than read the debates on the ietf mailing lists
that try to pass for thought experiments (the ATM discussions seem to
come to mind). A good mix of venture capital and government spending
seems to have yielded pretty good results in the past. I would argue
this is a good test for spending government funds is if more than
just the government is willing to, and actually do, pony up
significant funding for testbed or technology deployment trials. In
these cases you are more likely to be using "the taxpayers' money"
wisely.
Another nice feature of testbeds is that they foster inter-enterprise
collaborations. This is critically important in the global telecom
world, where the actions of old monopolies are often so heavily
scrutinized and feared that it hampers innovation, experimentation and
work with similar companies.
It is currently fashionable to pronounce that anything involving the
government is politically motivated and that committees are bad. I
suspect historians will record that the word "committee" fell out of
favour in late 20th century rhetoric as a result of anti-communist
phrasology, and instead the PC phrases became "working groups",
"representative delegations", etc(back to the Marxist phrases :-)).
However, the Internet experience would seem to point out that
government led and funded programs can be a very positive thing,
especially when partnered with people and organizations
that have great ideas and the drive to see things through.
>>> We need to worry about the *infrastructure* of the future global
>>> internet, issues like system robustness, scalability, and
>>> heterogeneity (of the underneath technologies); let the industry and
>>> market take care of technologies. As long as we do our IP/IPng right,
>>> we'll just run IP on top of whatever technology they happen to provide
>>> for the day.
At one level this sounds right, but I think it is tragically flawed. If
IP/IPng is a base technology for "the future global internet" then it
should be able to meet the requirements of "the industry and market".
We want the industry to deploy this stuff (IP/IPng) in a big way. I would
like my telecom providers to be able to deploy and operate Internet
technology in a cost effective manner. Today this is really hard and not
very cost effective. We are getting to the point where we *HAVE* to worry
about consolidating the telecom switching fabric so that it is scalable and
cost effective. Today carriers deploy too many switching solutions and
it is keeping telcom costs high. And simply layering routers on top is
a reasonable intermediate solution to get an Internet, but I would much
rather see a simple layering:
Internet Switching and Signalling
Transmission (current leading candidates: SONET and T-* hierarchy)
The techology needs of the industry and market are include those of the
future global Internet. I have yet to see a reason why telecom
switching and signalling technology needs to be different from
Internet switching and signalling technology. I would agree that
Internet switching and signalling should not depend on telcom
switching and signalling.
In this light, the current IPng efforts run the risk of being a big
thought experiment. Perhaps one of the testbeds that the G-7 crew
should think about is an IPng testbed that ties together a few
national/regional IPng testbeds. This presupposes the existence of
national/regional/local IPng testbeds. I would like to think vendors who
plan to ship IPng products will drive the creation of testbeds, prior
to shipping product by the boatload and really messing up people who have
to manage and support Internet networks.
To get a great technology we might have to weed out a few pretenders along
the way, and testbeds can play a big part in the process.
Best wishes in the new year,
peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11662;
9 Jan 95 16:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11656;
9 Jan 95 16:13 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16488;
9 Jan 95 16:13 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11647;
9 Jan 95 16:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10918;
9 Jan 95 16:10 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa16415; 9 Jan 95 16:10 EST
Received: from rhyolite.denver.sgi.com by sgi.sgi.com via SMTP (941129.SGI.8.6.9/910110.SGI)
for <@sgi.sgi.com:ietf at nri.reston.va.us> id NAA02323; Mon, 9 Jan 1995 13:10:49 -0800
Received: by rhyolite.denver.sgi.com (920330.SGI/911001.SGI)
for @sgi.sgi.com:ietf at nri.reston.va.us id AA20267; Mon, 9 Jan 95 14:10:09 -0700
Date: Mon, 9 Jan 95 14:10:09 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vernon Schryver <vjs at rhyolite.denver.sgi.com>
Message-Id: <9501092110.AA20267 at rhyolite.denver.sgi.com>
To: ietf at nri.reston.va.us
Subject: Re: Last Call: Routing Information Protocol to Historic
> From: rgm3 at is.chrysler.com (Robert Moskowitz)
> ...
> We learned the hard way here that as soon as you go to variable sized
> subnets, i.e. what classless routing is for. RIP breaks bad.
>
> We did this to conserve addresses, as our WAN links were eating us alive.
> The result was many meetings explaining to the UNIX support staff why they
> had to turn RIP listen off and code default routes. Even when we showed
> them UNIX systems that could no longer reach parts of our network they
> fought it. In the end, RIP listen is off, and RIP is partically gone. Some
> systems still require it, and the routers on their subnets play games, but
> we strickly limit that.
>
> PLEASE, RIPv1 belongs to historical.
>
> Even disconnected large nets can't use it. Anyone that is forced to
>variable sized subnets to conserve IPv4 addresses will have to move on from it.
I do not want to re-open the question of whether RIPv1 should be
historical. However, the text above is technically wrong. It's errors
should not be allowed to accumulate with the many other, ancient errors
about RIP. (E.g. the familiar claims that RIP cannot deal with more
than a dozen networks).
- it is not necessary to switch to variable sized subnets on
moderate sized internets (e.g. 1000's of hosts and ~400
(sub)networks work fine).
- it is not always necessary to give up on RIPv1 for all variable
sized subnet masks, even when those varying masks are applied
to the same base network number. RIPv1 can deal with variable
sized subnet masks if you are careful enough about their
organization (and sometimes with the addition of what look like
host routes).
- even when varying subnet masks make RIPv1 the wrong IS-IS
protocol, they do not necessarily make it the wrong IS-ES
protocol. E.g. when RIPv1 is turned off on all routers,
advertising a modest number of routes, sometimes including a
default, is effective.
Of course, RIPv2, OSPF, etc. handle varying subnet masks far better
than RIPv1, and should be used when available.
This mailing list is not the place to offer existence proofs of those
truths, and they are no doubt obvious to many. Of course, I can offer
such proofs privately.
Vernon Schryver, vjs at sgi.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08092;
9 Jan 95 13:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08088;
9 Jan 95 13:52 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa12728;
9 Jan 95 13:52 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <NAA05742 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 13:19:22 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA24966; Mon, 9 Jan 95 13:16:41 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <NAA05737 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 13:19:18 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA08904; Mon, 9 Jan 95 13:19:16 EST
Message-Id: <9501091819.AA08904 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Updating charter and milestones
Date: Mon, 09 Jan 1995 13:19:16 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
CAT fanciers:
We have a large number of activities underway and under discussion
within the WG, and it's a strategic point to revisit and update the
WG's charter and milestones to replace the now-dated version resident
in the IETF directories and to assess where we stand and how we should
proceed. Here's a proposed draft revision for "Description of Working
Group" and "Goals and Milestones". Discussion solicited.
--jl
Common Authentication Technology (cat)
--------------------------------------
Description of Working Group:
The goal of the Common Authentication Technology Working Group is to
provide strong authentication, integrity, and confidentiality services
to a variety of protocol callers in a manner which insulates those
callers from the specifics of underlying security mechanisms. We
anticipate future work in extensions to support authorization
services.
By separating security implementation tasks from the tasks of
integrating security data elements into caller protocols, those tasks
can be partitioned and performed separately by implementors with
different areas of expertise. This provides leverage for the IETF
community's security-oriented resources, and allows protocol
implementors to focus on the functions their protocols are designed to
provide rather than on characteristics of security mechanisms. CAT
seeks to encourage uniformity and modularity in security approaches,
supporting the use of common techniques and accommodating evolution of
underlying technologies.
In support of these goals, the working group pursues several
interrelated tasks. We have defined a common service interface
allowing callers to invoke security services, and a common security
token format, incorporating means to identify the mechanism type in
conjunction with which security data elements should be interpreted.
We are currently working on a revision to these documents ("GSS-V2")
in response to implementation experience.
In addition to interface and token framing issues, the CAT Working
Group also works towards agreements on suitable underlying mechanisms
to implement security functions; Kerberos V5 and Simple Public-Key
Mechanism (SPKM) proposals are discussed in currently active Proposed
Standards and Internet-Drafts, with a prior public-key proposal
(Distributed Authentication Security Services (DASS)) documented in an
Informational RFC.
The CAT Working Group also consults with other IETF working groups
responsible for candidate caller protocols, pursuing and supporting
design refinements as appropriate. FTP Security is a particular
integration example; preparation of this specification has proceeded
within the CAT WG.
Goals and Milestones (as of January 1995):
Done: Standards-track RFCs 1508 and 1509, Internet-Drafts on GSS-V2,
Kerberos V5 GSS-API Mechanism, SPKM, IOP, Kerberos One-Time
Password integration, and FTP Security.
Jan 95: Agree on revision to WG charter and on scope of GSS-V2
changes vs. issues to be deferred for later consideration.
Jan 95: Issue Internet-Draft proposal re GSS-API Windows bindings.
Mar 95: Finalize FTP Security Internet-Draft for advancement to
Proposed Standard.
Mar 95: Finalize Kerberos V5 GSS-API Mechanism Internet-Draft for
advancement to Proposed Standard.
Apr 95: Finalize GSS-V2 Internet-Draft as basis for advancement of
GSS-API to Draft Standard or for submission to become new Proposed
Standard. [NOTE: This date assumes that GSS-V2 scope does not grow
significantly beyond the issues identified in the December 1994
meeting minutes, and that no major impacts are identified as results
of parallel work on the GSS-API negotiation mechanism.]
Apr 95: Revision of RFC-1509 for GSS-V2.
Apr 95: Initial Internet-Draft for GSS-API negotiation mechanism,
exchanging tokens to identify a common security mechanism shared
between peers and then proceeding to establish a security context
using that mechanism.
Apr 95: Revised IOP Internet-Draft.
Apr 95: Submit SPKM as Proposed Standard, assuming sufficient and
suitable implementation experience.
Jul 95: Initial Internet-Draft for GSS-API multi-mechanism
registration (SPI) facilities.
Jul 95: Plan next phase of activities to follow GSS-V2.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09302;
9 Jan 95 14:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09298;
9 Jan 95 14:43 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14277;
9 Jan 95 14:43 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <OAA06730 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 14:12:03 -0500
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA00477; Mon, 9 Jan 95 14:09:04 EST
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4 + 8.6.9, dpg hack 5dec94) with UUCP id LAA18998; Mon, 9 Jan 1995 11:08:31 -0800
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA04044; Mon, 9 Jan 95 10:33:59 -0800
Date: Mon, 9 Jan 95 10:33:59 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9501091833.AA04044 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Rich Salz <rsalz at osf.org>
Subject: Re: Multi-Mech Implementations and an SPI definition???
Cc: tytso at mit.edu, cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
> From: Rich Salz <kerby!osf.org!rsalz>
> Date: Mon, 9 Jan 95 11:00:40 -0500
>
> >That's one reason why you might want to isolate state data in a
> >user-managed context structure, yes. The other reason might be to
> >provide for a certain amount of thread safety.
>
> I'm particularly concerned about thread-safety.
>
> >In general, I believe it's a good thing for a library to never
need
> >to store any static state; if there needs to be any such state, it
> >should be isolated in a some sort of context variable --- either a
> >security association context (as we already have) or a library
> >session context (if that makes sense).
>
> I agree. For example, right now I can't use a GSSAPI in my
> NNTP server, because it's one executable that handles
> all incoming connections.
>
> Using GSSAPI in DCE (it's bundled in DCE 1.1) can be
> problematic because of the threads issue.
>
> The changes may be pervasive, however, and (3 in a row)
> Ted's right that the APi should be examined to see if it's
> really worthwhile.
> /r$
>
Doesn't thread safety go beyond the GSS-API layer to the
mechanism layers too? A thread conscious GSS-API would
be of limited value if the mechanisms aren't thread
conscious. (If the mechanisms aren't thread conscious
then you must implement course locking which may impede
the benefits of threading.)
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14010;
9 Jan 95 16:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14006;
9 Jan 95 16:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa17511;
9 Jan 95 16:51 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <QAA09625 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 16:26:45 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Received: from gatekeeper.icl.co.uk by MIT.EDU with SMTP
id AA16044; Mon, 9 Jan 95 16:24:02 EST
Received: by gatekeeper.icl.co.uk (4.1/UNIPALM-Vevision: 1.3 gatekeeper.icl.co.uk)
id AA12367; Mon, 9 Jan 95 21:20:51 GMT
Received: from unknown(145.227.14.59) by gatekeeper via smap (V1.3mjr)
id sma012351; Mon Jan 9 21:20:00 1995
Received: from trojan.oasis.icl.co.uk by ming.oasis.icl.co.uk
id AA22642; Mon, 9 Jan 95 21:24:24 GMT
Message-Id: <9501092125.AA07926 at getafix.oasis.icl.co.uk>
Date: Mon, 9 Jan 95 21:25:22 GMT
Reply-To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: Confused about gss_display_name()
To: cat-ietf at mit.edu
> I am coding another version of the GSS-API against
> RFC-1509 and am confused about the parameter
> output_name_type to gss_display_name().
>
> Section 3.15's description of output_name_type states
> "The type of the returned name. The returned gss_OID will
> be a pointer into static storage, and should be treated as
> read-only by the caller."
>
> What is output_name_type? Is it input_name_type passed
> to gss_import_name()
It's the same syntax.
> or a mechanism OID as returned in
> the MIT GSS-API?
It's a name OID not a mechanism oid.
> If output_name_type is a mechanism OID, how should we
> choose a mechanism OID in the presence of multiple
> mechanisms?
It's not a mechanism OID.
Where multiple name-types exist they are differentiated by oid.
We have obtained the 1,3,12,1,46,6 arc for this purpose and,
for example, have allocated {1,3,12,1,46,6,1} for X.500 DNs.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15204;
9 Jan 95 17:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15197;
9 Jan 95 17:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18799;
9 Jan 95 17:41 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15187;
9 Jan 95 17:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15137;
9 Jan 95 17:38 EST
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa18727;
9 Jan 95 17:38 EST
Received: (from ole at localhost) by Csli.Stanford.EDU (8.6.9/8.6.9) id OAA21564; Mon, 9 Jan 1995 14:37:57 -0800
Date: Mon, 9 Jan 95 14:37:53 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: ietf at CNRI.Reston.VA.US, tcp-ip at nic.ddn.mil, iso at nic.ddn.mil
Phone: +1 415 578-6900 (SOFTBANK Expos)
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 578-6988 (Office) +1 415 998-4427 (Pager)
FAX: +1 415 525-0194 (SOFTBANK Expos) +1 415 826-2008 (Home)
Address: 303 Vintage Park Drive, Foster City, CA 94404-1138
Subject: Call for Voiunteers: NetWorld+Interop CATs
Message-ID: <CMM.0.90.4.789691073.ole at Csli.Stanford.EDU>
Please distribute as widely as possible:
Call for Volunteers:
The INTEROP Conference Assessment Team (CAT)
Interop Company is seeking student volunteers to serve as quality
control monitors for NetWorld+Interop 95, to be held in Las Vegas
March 27-31, 1995. (Conference March 28-30). This is a unique
opportunity for students to attend the industry's premier networking
conference and tradeshow, while helping us improve the quality and
consistency of the conference.
As a CAT member you will receive:
* Complimentary conference registration for all three conference days
* Complimentary conference notes
As a CAT member you will be asked to:
* Monitor preassigned conference sessions by submitting written
reports and acting as the "eyes and ears" of the conference
organizers. We will provide you with a basic evaluation form to aid
the preparation of the reports.
(You will be free to attend any conference session and the
NetWorld+Interop exhibition when you are not assigned CAT duty, but
you will be strongly encouraged to complete evaluation forms for any
session you attend.)
* Provide an accurate count of the number of people attending the
sessions you are assigned to. ("Clickers" will be provided!)
Successful CAT candidates will be students currently enrolled in a
computer science or electrical engineering course at undergraduate,
graduate or post-graduate level. Applicants should have some
understanding of (and interest in) computer networking issues. All
applications must be received by February 20, 1995, but note that this
program is popular, and operates on a first-come-first-served basis.
Previous CAT members are encouraged to apply again!
Please note that Interop Company cannot cover any travel or
accommodation costs associated with the CAT program, however as a CAT
member you will be elligible for the standard conference discount rate
at a number of Las Vegas hotels.
Note also, that the CAT program is *separate from* the network volunteers
program organized by Interop. Participation in both is possible, but
not recommended (you won't get any sleep for a week!)
To apply, send e-mail ONLY to: ole at interop.com with a *brief*
biography and relevant contact information. Don't forget to send a
POSTAL address as we need to send you a NetWorld+Interop program.
Please include your postal address at the *end of your message* in the
following plain form:
John Applicant
Flymore University
1234 Main Street
Sometown, MN 98765
Only ONE applicant per message please!
****PLEASE DO NOT INCLUDE THIS MESSAGE IN YOUR REPLY!!****
Ole
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report,
Interop Company, a division of SOFTBANK Expos, 303 Vintage Park Drive,
Foster City, CA 94404-1138, USA. Ph: +1 (415) 578-6988 Fax: +1 (415) 525-0194.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15264;
9 Jan 95 17:45 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15260;
9 Jan 95 17:45 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa18879;
9 Jan 95 17:45 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <RAA10681 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 17:16:10 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA21862; Mon, 9 Jan 95 17:13:29 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <RAA10677 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 17:16:07 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA01052; Mon, 9 Jan 95 17:16:06 EST
Message-Id: <9501092216.AA01052 at dun-dun-noodles.cam.ov.com>
To: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Cc: cat-ietf at mit.edu
Subject: Re: Confused about gss_display_name()
In-Reply-To: Dennis Glatting's message of 9 Jan 1995 20:01:51 -0000
Date: Mon, 09 Jan 1995 17:16:05 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> What is output_name_type? Is it input_name_type passed
>> to gss_import_name() or a mechanism OID as returned in
>> the MIT GSS-API?
It should be a name type OID as passed to gss_import_name().
On checking, the MIT code does do the wrong thing. FWIW, This is
fixed in the OV sources; I've appended a patch, which I will forward
along to Ted.
Marc
*** display_name.c 1993/12/21 05:13:43 1.10
--- display_name.c 1994/09/13 19:24:22 1.11
***************
*** 59,64 ****
*minor_status = 0;
if (output_name_type)
! *output_name_type = (gss_OID) gss_mech_krb5;
return(GSS_S_COMPLETE);
}
--- 59,64 ----
*minor_status = 0;
if (output_name_type)
! *output_name_type = (gss_OID) gss_nt_krb5_name;
return(GSS_S_COMPLETE);
}
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15308;
9 Jan 95 17:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15302;
9 Jan 95 17:46 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18905;
9 Jan 95 17:46 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15290;
9 Jan 95 17:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15243;
9 Jan 95 17:44 EST
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa18857;
9 Jan 95 17:44 EST
Received: (from ole at localhost) by Csli.Stanford.EDU (8.6.9/8.6.9) id OAA21795; Mon, 9 Jan 1995 14:44:08 -0800
Date: Mon, 9 Jan 95 14:44:01 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: ietf at CNRI.Reston.VA.US
Cc: tcp-ip at nic.ddn.mil
Phone: +1 415 578-6900 (SOFTBANK Expos)
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 578-6988 (Office) +1 415 998-4427 (Pager)
FAX: +1 415 525-0194 (SOFTBANK Expos) +1 415 826-2008 (Home)
Address: 303 Vintage Park Drive, Foster City, CA 94404-1138
Subject: Call for Participation: BOFs at NetWorld+Interop
Message-ID: <CMM.0.90.4.789691441.ole at Csli.Stanford.EDU>
Following a long tradition, we will once again offer the opportunity
for interested parties to meet and discuss topics of mutual interest
in Birds of a Feather (BOF) sessions. The venue is NetWorld+Interop 95
Las Vegas. This time, BOFs will be held Tuesday and Wednesday nights,
March 28th and 29th, from 7:30pm until 9:30pm. All BOFs will take
place at the Las Vegas Hilton.
BOFs provide attendees with an opportunity to discuss networking
issues in an informal, after hours, atmosphere. BOFs have become a
forum for users to meet with other users and with implementation
experts. These sessions are not intended for formal presentations, and
certainly NOT for vendor product presentations, but rather as a forum
for discussions of "unsolved problems." BOFs are open to all
Networld+Interop attendees, including Exhibition attendees, and no
special registration is necessary. Examples of some BOF topics from
previous Interop events include:
o Network Device Performance Testing
o Internet information tools (WWW, Gopher, WAIS, Archie....)
o Internet Firewalls and Hackers
o SNMP Testing
o Fast Ethernet Standards
o Networked multimedia systems
o Resource Reservations Protocols
o Using Facsimile Devices around the World as Remote Printers
o The Internet and K-12 schools
To suggest a topic for a BOF at NetWorld+Interop 95 Las Vegas please
send a 50 word abstract along with the name of a contact person (BOF
moderator) to Ole Jacobsen (ole at interop.com) as soon as possible.
Space is limited, first come, first served.
For your information, the following is a sample BOF description:
Internet Firewalls and Hackers
------------------------------
In the wake of recent well-publicized hacking attacks, interest has
grown in the hacker's methods and the tools used to exclude them. The
use of firewalls and one-time password schemes can foil most common
hacking schemes. This BOF will be an informal interactive discussion
of hacking techniques, and the various tools and approaches commonly
used to implement a denial-of-hacker service. It will undoubtedly
include war stories and firewall designs and philosophy.
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report,
Interop Company, a division of SOFTBANK Expos, 303 Vintage Park Drive,
Foster City, CA 94404-1138, USA. Ph: +1 (415) 578-6988 Fax: +1 (415) 525-0194.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17033;
9 Jan 95 20:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17029;
9 Jan 95 20:04 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21719;
9 Jan 95 20:04 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <TAA13185 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 19:29:51 -0500
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA29958; Mon, 9 Jan 95 19:27:06 EST
Received: by dcl.MIT.EDU (5.0/4.7) id AA06659; Mon, 9 Jan 1995 19:27:05 +0500
Date: Mon, 9 Jan 1995 19:27:05 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9501100027.AA06659 at dcl.MIT.EDU>
To: dpg at ocsg.com
Cc: Rich Salz <rsalz at osf.org>, cat-ietf at mit.edu
In-Reply-To: Dennis Glatting's message of Mon, 9 Jan 95 10:33:59 -0800,
<9501091833.AA04044 at war04.ocsg.com>
Subject: Re: Multi-Mech Implementations and an SPI definition???
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 713
Date: Mon, 9 Jan 95 10:33:59 -0800
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
> I'm particularly concerned about thread-safety.
Doesn't thread safety go beyond the GSS-API layer to the
mechanism layers too? A thread conscious GSS-API would
be of limited value if the mechanisms aren't thread
conscious. (If the mechanisms aren't thread conscious
then you must implement course locking which may impede
the benefits of threading.)
True.... and funny that you should mention that. We're currently in
the midst of adding a library session context parameter to Kerberos V5
library, for precisely this reason. That's why I was suggesting it for
the GSS-API.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17068;
9 Jan 95 20:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa17064;
9 Jan 95 20:08 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21807;
9 Jan 95 20:08 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <TAA13348 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 19:33:48 -0500
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA00274; Mon, 9 Jan 95 19:31:00 EST
Received: by dcl.MIT.EDU (5.0/4.7) id AA06724; Mon, 9 Jan 1995 19:30:59 +0500
Date: Mon, 9 Jan 1995 19:30:59 +0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9501100030.AA06724 at dcl.MIT.EDU>
To: Marc Horowitz <marc at cam.ov.com>
Cc: Dennis Glatting <war04!dennisg at kerby.ocsg.com>, cat-ietf at mit.edu
In-Reply-To: Marc Horowitz's message of Mon, 09 Jan 1995 17:16:05 -0500,
<9501092216.AA01052 at dun-dun-noodles.cam.ov.com>
Subject: Re: Confused about gss_display_name()
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 419
Date: Mon, 09 Jan 1995 17:16:05 -0500
From: Marc Horowitz <marc at cam.ov.com>
It should be a name type OID as passed to gss_import_name().
On checking, the MIT code does do the wrong thing. FWIW, This is
fixed in the OV sources; I've appended a patch, which I will forward
along to Ted.
Thanks for pointing this out, and sending out a patch. I've fixed it in
our sources as well now.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18549;
9 Jan 95 22:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18528;
9 Jan 95 22:52 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24268;
9 Jan 95 22:52 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18240;
9 Jan 95 22:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18022;
9 Jan 95 22:49 EST
Received: from prosit.Stanford.EDU by CNRI.Reston.VA.US id aa24209;
9 Jan 95 22:49 EST
Received: (from chon at localhost) by Prosit.Stanford.EDU (8.6.9/8.6.9) id TAA29208; Mon, 9 Jan 1995 19:45:19 -0800
Date: Mon, 9 Jan 1995 19:45:19 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Kilnam Chon <chon at prosit.stanford.edu>
Message-Id: <199501100345.TAA29208 at Prosit.Stanford.EDU>
To: apng-all at apng.org, ccirn at lbl.gov, iepg at aarnet.edu.au,
ietf at CNRI.Reston.VA.US, newsletter at terena.nl
Subject: submission of abstract for INET'95 is due this Friday
13 January 1995 is the due date for the submission of the abstract for paper
presentation at INET'95. Please submit the abstract to inet-submission@
interop.com, or let me know on your intention if you are interested in the
presentation at INET'95 in Honolulu, 27-30 June 1995.
Kilnam Chon
INET'95 Program Committee Co-Chair (with Dan Lynch)
Email: chon at prosit.stanford.edu
Fax: +1-415-723-0758
Tel: +1-415-723-6890
--------------------------------------------------------------------------------
PC.02
Call for Paper - Full 11.14
******************************************************************************
CALL FOR PAPERS
INET'95
The 5th Annual Conference of the Internet Society
The Internet: Towards Global Information Infrastructure
Honolulu, Hawaii, USA
27-30 June 1995
INET'95, the 5th Annual Conference of the Internet Society, focusing on
worldwide issues of Internet networking, will be held on 26-30 June 1995 in
Hawaii. The goal of this conference is to provide a platform that will bring
together those developing and implementing Internet networks, technologies,
applications, and policies worldwide for infrastructure development. The theme
of INET'95 is "The Internet: Towards Global Information Infrastructure."
Since 1991, The INET conferences have become a common meeting ground for
participants interested in the design, implementation, operation and use of
the Internet. Global policy and economic issues, ethical concerns, and many
technical issues are raised in a variety of contexts. The rapid influx of
commercial and individual uses on the Internet has influenced the nature of
the system and broadened its utility. The importance of the Internet and its
technology to all sectors of the global economy is growing as is the social
impact of access to the Internet. Internet Society encourages its members
and all other interested parties to submit papers and to plan active
participation in this conference.
In addition to the Network Training Workshop for Developing Countries prior to
the INET Conference, the K12 Workshop, a special workshop for elementary and
secondary school use of the Internet is also planned.
Conference Topics.
The conference will be organized into the following 8 tracks.
1. Network Technology
2. Network Engineering and Operation
3. Application Technology
4. Users
5. Regional Issues
6. Policy Issues
7. Commercial and Business Aspects
8. Education
Presentation Topics.
Topics for presentations within these tracks include, but are not limited to,
the following:
1. Network Technology
- Broadband technology
- Community networking technology
- Mobility
- Global networking
- Next generation of Internet technology
2. Network Engineering and Operation
- Interoperability
- Network management
- Scalability
- Emergency response organizations and support
- Resource allocation and control
- Routing and addressing
3. Application Technology
- Collaboration technologies
- Multimedia technologies and applications
- Distributed applications and environments
- Networked information tools
- High, low and variable bandwidth applications
4. Users
- Community networking services
- Education and research communities
- Library services and networked information
- Public health and medical care
- Environment
- Entertainment
- Arts and humanities
5. Regional Issues
- National and regional initiatives
- Mission oriented networks
- National and regional funding models
- Empowering new users
- Sociological and cultural impact
- Internationalization and localization
6. Policy Issues
- Information infrastructure and role of governments
- Policy on Internet operation
- Privacy and freedom of speech
- Intellectual property rights
- Economy Policy
7. Commercial and Business Aspects
- Commercial use of Internet
- Electronic Commerce
- Publication
- Emerging business opportunities
- Legal considerations
- Global issues
8. Education
- Building new global learning communities
- Teacher training and support models
- Promoting new cultures of learning and teaching
- The Internet in educational reform
- Connectivity and access models
- Using technology to reach learners with special needs and interest
- Encouraging new partnership; industry, government, community
In addition to the above tracks, INET'95 will encompass certain
horizontal subject threads. One such thread is the World Wide Web(WWW),
and papers are solicited relating to WWW developments as furthering Global
Information Infrastructure.
Information for Paper Submission.
The official language of the conference is English.
Papers will be selected based on two-page extended abstracts. The abstracts
should include name, address, affiliation, phone number, fax number, and
email address. They should also include a keyword list, tied to the track
topics listed above. Upon acceptance, full papers will be required.
Instructions for preparation of these papers will be provided upon acceptance.
some of the submitted papers will be presented at Poster Sessions.
Extended abstracts in plain ASCII text should be submitted by 13 January 1995 to
inet-submission at interop.com
The Program Committee can be contacted at
inet-program at interop.com, or
by fax: +1-415-723-0758 (Attn.: Prof. Kilnam Chon).
Demonstrations.
Participants may present their projects or activities in demonstration form.
Proposed demonstrations should be documented with a description not exceeding
one page.
Tutorials.
The tutorials will be held in 27 June. You may submit the proposal for the
tutorials by 13 January 1995 to
inet-tutorial at interop.com
Developing Country Workshop.
The Network Training Workshop for Developing Countries will be a week-long
program in 18-24 June of intensive instruction, with a hands-on emphasis on
Internet set-up, operations, maintenance, and management. The Workshop covers
the four program tracks:
Dial-up Networking Technology
TCP/IP Networking Technology
Network Navigation and Services
National Network Management
For information and general questions about the workshop, please send email to
workshop-info at isoc.org
For applying to attend the workshop, please send email to:
workshop-apply at isoc.org
K12 Workshop.
The INET'95 will also be preceded by a tentative two-day program bringing
together active K12(Kindergarten through Secondary School) Internet innovators
from around the world to share experiences and learn new advanced tools and
collaboration techniques. For information and general questions about the
K12 Workshop, please send email to
inet-k12-request at isoc.org
Important Dates.
13 January 1995: Extended abstract, and Tutorial proposal due
15 January 1995: Deadline for priority admission to Developing Countries
Workshop
3 March 1995: Notification of paper acceptance to author(s)
28 April 1995: Camera-ready papers due
18-24 June 1995: Developing Countries Workshop
26-27 June 1995: K12 Workshop
27 June 1995: Tutorials
28-30 June 1995: INET'95
Publications.
Conference proceedings containing full papers will be distributed to
the participants at the conference. They are also available in WWW at
Internet Society.
Points of Contact.
Program Committee Chairs: Dan Lynch dlynch at interop.com
Kilnam Chon chon at prosit.stanford.edu
Developing Countries Workshop: George Sadowsky George.Sadowsky at nyu.edu
K12 Workshop: Kathy Rutkowski kmr at isoc.org
Local Arrangements: David Lassner david at hula.oit.hawaii.edu
Publicity: Elizabeth Barnhart barnhart at educom.edu
Internet Society Liaison: Larry Landweber lhl at cs.wisc.edu
Information and Registration:
INET'95 will be held at the Sheraton Waikiki Conference Center with
some events at the adjoining Royal Hawaiian Hotel. General information
concerning the conference, registration, and a variety of hotel
accommodations booked at special rates will be available from the Internet
Society Secretariat in a separate announcement in early 1995 and accessible
on the Society's WWW, Gopher, and FTP servers.
URLs: http://www.isoc.org/inet95.html
gopher: //gopher.isoc.org/11/isoc/inet95
ftp: //ftp.isoc.org/isoc/inet95
Email: inet95 at isoc.org (for information)
inet-registration at isoc.org (for registration)
Tel: +1-703-648-9888
Fax: +1-703-648-9887
Address:Internet Society Secretariat
12020 Sunrise Valley Drive, Suite 270
Reston, VA 22091
USA
******************************************************************************
--tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25441;
10 Jan 95 0:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25437;
10 Jan 95 0:48 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa26081;
10 Jan 95 0:48 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <AAA18042 at pad-thai.cam.ov.com>; Tue, 10 Jan 1995 00:11:31 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: roxana at qsun.ho.att.com
Received: from gw1.att.com by MIT.EDU with SMTP
id AA21237; Tue, 10 Jan 95 00:08:50 EST
Received: from qsun.ho.att.com by ig1.att.att.com id AA28169; Tue, 10 Jan 95 00:09:06 EST
Received: by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS)
id AA24276; Tue, 10 Jan 95 00:08:43 EST
Date: Tue, 10 Jan 95 00:08:43 EST
Message-Id: <9501100508.AA24276 at qsun.ho.att.com>
To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Updating charter and milestones
Hi,
Can someone please point me to the archives for this list?
The charter referred to in the IETF proceedings mentions
bitsy.mit.edu but not the protocol. I tried ftp and http
but both were unsuccessful. Your assistance would be greatly
appreciated.
Thanks in advance,
Roxana
----------------------------------------------------------------------------
Roxana Bradescu E-Mail: roxana at qsun.att.com
AT&T Bell Laboratories Voice: +1 (908) 949-2002
----------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25781;
10 Jan 95 2:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25775;
10 Jan 95 2:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27293;
10 Jan 95 2:10 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25763;
10 Jan 95 2:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa25718;
10 Jan 95 2:07 EST
Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa27154;
10 Jan 95 2:07 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 10 Jan 95 16:06:50 +0859
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9501100707.AA04700 at necom830.cc.titech.ac.jp>
Subject: Re: Last Call: Tags for the identification of languages to Proposed
To: ietf at CNRI.Reston.VA.US
Date: Tue, 10 Jan 95 16:06:48 JST
In-Reply-To: <9501031752.aa09083 at IETF.CNRI.Reston.VA.US>; from "IESG Secretary" at Jan 3, 95 5:52 pm
X-Mailer: ELM [version 2.3 PL11]
> The IESG has received a request from the Mail Extensions Working Group
> to consider "Tags for the identification of languages"
> <draft-ietf-mailext-lang-tag-01.txt> for the status of Proposed
> Standard.
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
> January 17, 1994.
To make it proposed standard? Doesn't it mean to make it an RFC?
But, <draft-ietf-mailext-lang-tag-01.txt> contains non-ASCII characters
of ISO 8859/1 without any "charset" tagging.
As it uses MIME Quoted-Printable encoding to represent 8859 specific
characters, it violates RFC rules on form feed characters (that is,
form feed charaters are not '^L' but "=0C").
So, how can it be an RFC?
The only possible way, it seems to me, is to edit it to be pure
ASCII without Quoted-Printable encoding. The draft does not
essentially need non-ASCII characters.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04369;
10 Jan 95 10:53 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04363;
10 Jan 95 10:53 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08091;
10 Jan 95 10:53 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04346;
10 Jan 95 10:53 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04293;
10 Jan 95 10:50 EST
Received: from inet-gw-3.pa.dec.com by CNRI.Reston.VA.US id aa08017;
10 Jan 95 10:50 EST
Received: from skidrow.tay.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94)
id AA28177; Tue, 10 Jan 95 07:40:39 -0800
Received: by skidrow.tay.dec.com (5.65/MS-081993);
id AA13446; Tue, 10 Jan 1995 10:45:42 -0500
Message-Id: <9501101545.AA13446 at skidrow.tay.dec.com>
To: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Tags for the identification of languages to Proposed
In-Reply-To: Your message of "Tue, 10 Jan 95 16:06:48 +0200."
<9501100707.AA04700 at necom830.cc.titech.ac.jp>
Date: Tue, 10 Jan 95 10:45:42 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.tay.dec.com>
X-Mts: smtp
All the formating stuff you are talking about it taken care of
by the RFC Editor.
Donald
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Sender: ietf-request at IETF.CNRI.Reston.VA.US
To: ietf at CNRI.Reston.VA.US
In-Reply-To: <9501031752.aa09083 at IETF.CNRI.Reston.VA.US>; from "IESG Secretary" at Jan 3, 95 5:52 pm
X-Mailer: ELM [version 2.3 PL11]
>> The IESG has received a request from the Mail Extensions Working Group
>> to consider "Tags for the identification of languages"
>> <draft-ietf-mailext-lang-tag-01.txt> for the status of Proposed
>> Standard.
>To make it proposed standard? Doesn't it mean to make it an RFC?
Yes.
>But, <draft-ietf-mailext-lang-tag-01.txt> contains non-ASCII characters
>of ISO 8859/1 without any "charset" tagging.
>
>As it uses MIME Quoted-Printable encoding to represent 8859 specific
>characters, it violates RFC rules on form feed characters (that is,
>form feed charaters are not '^L' but "=0C").
That's too bad. I find drafts much more readable when the have real
form feeds in them so the pages don't drift relative to physical
pages if I print them out.
>So, how can it be an RFC?
>
>The only possible way, it seems to me, is to edit it to be pure
>ASCII without Quoted-Printable encoding. The draft does not
>essentially need non-ASCII characters.
All drafts that become RFCs, whether standards track or not,
go thought the RFC editing process.
> Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07166;
10 Jan 95 13:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07159;
10 Jan 95 13:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12583;
10 Jan 95 13:54 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07148;
10 Jan 95 13:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07080;
10 Jan 95 13:49 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa12481;
10 Jan 95 13:49 EST
Received: by ginger.lcs.mit.edu
id AA07241; Tue, 10 Jan 95 13:50:07 -0500
Date: Tue, 10 Jan 95 13:50:07 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9501101850.AA07241 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US, vjs at rhyolite.denver.sgi.com
Subject: Re: Last Call: Routing Information Protocol to Historic
Cc: jnc at ginger.lcs.mit.edu
From: Vernon Schryver <vjs at rhyolite.denver.sgi.com>
> We learned the hard way here that as soon as you go to variable sized
> subnets, i.e. what classless routing is for. RIP breaks bad. ... Anyone
> that is forced to variable sized subnets to conserve IPv4 addresses will
> have to move on from it.
the text above is technically wrong. It's errors should not be allowed to
accumulate with the many other, ancient errors about RIP. (E.g. the
familiar claims that RIP cannot deal with more than a dozen networks).
Perhaps this is a conflation of the RIP *diameter* limit of 16, which *has*
caused problems in real networks. (Of course that diameter limit is even
smaller if you are injecting external routes with non-minimal metrics.)
- it is not necessary to switch to variable sized subnets on
moderate sized internets (e.g. 1000's of hosts and ~400
(sub)networks work fine).
With CIDR, this may no longer be true. Remember, the C-space is only 12.5% of
the total address space, whereas A space is 50%. I don't know what the current
consumption rate is, but I assume we will run out of C-space at some point,
at which point, we're going to have to start handing out chunks of A's. So,
your net will be a chunk of an A (i.e. one subnet mask), which you chop into
smaller pieces (another subnet mask).
Since I assume running out of C-space is not too many years off, and we know
how long it takes to get something widely available in products, and deployed,
this says to me that we should move as energetically as possible to getting
RIP-2 out to replace RIP-1.
- even when varying subnet masks make RIPv1 the wrong IS-IS
protocol, they do not necessarily make it the wrong IS-ES
protocol. E.g. when RIPv1 is turned off on all routers,
advertising a modest number of routes, sometimes including a
default, is effective.
The problem here is that it continues to involve the hosts in a) knowing what
the structure of IP addresses is, and b) in running a routing protocol, even
as passive listeners. Both of these have historially been proven to be
architecturally unsound, and I hope we stomp them out as soon as possible.
Noel
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07937;
10 Jan 95 14:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13915;
10 Jan 95 14:47 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07904;
10 Jan 95 14:47 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07801;
10 Jan 95 14:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pem-dev at tis.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pem-sigenc-03.txt
Date: Tue, 10 Jan 95 14:38:34 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501101438.aa07801 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.
Title : Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted
Author(s) : J. Galvin, S. Murphy, S. Crocker, N. Freed
Filename : draft-ietf-pem-sigenc-03.txt
Pages : 12
Date : 01/09/1995
This document defines a framework within which security services may be
applied to MIME body parts. MIME, an acronym for "Multipurpose Internet
Mail Extensions", defines the format of the contents of Internet mail
messages and provides for multi-part textual and non-textual message
bodies. The new content types are subtypes of multipart: signed and
encrypted. Each will contain two body parts: one for the protected data
and one for the control information necessary to remove the protection. The
type and contents of the control information body parts are determined by
the value of the protocol parameter of the enclosing multipart/signed or
multipart/encrypted content type, which is required to be present.
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-pem-sigenc-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pem-sigenc-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-pem-sigenc-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950109162254.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-pem-sigenc-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pem-sigenc-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950109162254.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08486;
10 Jan 95 15:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14828;
10 Jan 95 15:15 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08437;
10 Jan 95 15:15 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08247;
10 Jan 95 15:05 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-relative-url-03.txt
Date: Tue, 10 Jan 95 15:05:21 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501101505.aa08247 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Relative Uniform Resource Locators
Author(s) : R. Fielding
Filename : draft-ietf-uri-relative-url-03.txt
Pages : 11
Date : 01/09/1995
A Uniform Resource Locator (URL) is a compact representation of the
location and access method for a resource available via the Internet. When
embedded within a base document, a URL in its absolute form may contain a
great deal of information which is already known from the context of that
base document's retrieval, including the scheme, network location, and
parts of the url-path. In situations where the base URL is well-defined
and known to the parser (human or machine) it is useful to be able to embed
URL references which inherit that context rather than re-specifying it in
every instance. This document defines the syntax and semantics for such
Relative Uniform Resource Locators.
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-uri-relative-url-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-relative-url-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-relative-url-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950109171048.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-relative-url-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-relative-url-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950109171048.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08749;
10 Jan 95 15:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15045;
10 Jan 95 15:26 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08732;
10 Jan 95 15:26 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08644;
10 Jan 95 15:23 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-mib-05.txt
Date: Tue, 10 Jan 95 15:23:16 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501101523.aa08644 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Open Shortest Path First IGP
Working Group of the IETF.
Title : OSPF Version 2 Management Information Base
Author(s) : F. Baker, R. Coltun
Filename : draft-ietf-ospf-mib-05.txt
Pages : 108
Date : 01/09/1995
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Open Shortest Path First
Routing Protocol.
This memo does not, in its draft form, specify a standard for the Internet
community.
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-ospf-mib-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-mib-05.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-ospf-mib-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950109174942.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-mib-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-mib-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950109174942.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10607;
10 Jan 95 17:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10601;
10 Jan 95 17:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17977;
10 Jan 95 17:00 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10578;
10 Jan 95 17:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10509;
10 Jan 95 16:58 EST
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa17916;
10 Jan 95 16:58 EST
Received: by atlas.xylogics.com id AA25023 (5.65c/UK-2.1-940401);
Tue, 10 Jan 1995 17:00:14 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Tue, 10 Jan 1995 17:00:14 -0500
Message-Id: <25023.199501102200 at atlas.xylogics.com>
To: jnc at ginger.lcs.mit.edu
Cc: ietf at CNRI.Reston.VA.US, vjs at rhyolite.denver.sgi.com
In-Reply-To: Noel Chiappa's message of Tue, 10 Jan 95 13:50:07 -0500 <9501101850.AA07241 at ginger.lcs.mit.edu>
Subject: Last Call: Routing Information Protocol to Historic
> With CIDR, this may no longer be true. Remember, the C-space is only 12.5% of
> the total address space, whereas A space is 50%. I don't know what the current
> consumption rate is, but I assume we will run out of C-space at some point,
> at which point, we're going to have to start handing out chunks of A's. So,
> your net will be a chunk of an A (i.e. one subnet mask), which you chop into
> smaller pieces (another subnet mask).
I'm a little confused by that. There are only 126 class A networks and
over 16 million class C networks.
Obviously, I believe that we need to encourage deployment of RIP-2. The
question is, does moving RIP-1 to Historic status accomplish this. Maybe
we need a new status level to indicate that the protocol was supplanted
by a newer version.
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(617) 272-8140 Pick two!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10858;
10 Jan 95 17:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10851;
10 Jan 95 17:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18549;
10 Jan 95 17:15 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10840;
10 Jan 95 17:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10800;
10 Jan 95 17:13 EST
Received: from ginger.lcs.mit.edu by CNRI.Reston.VA.US id aa18407;
10 Jan 95 17:13 EST
Received: by ginger.lcs.mit.edu
id AA08920; Tue, 10 Jan 95 17:13:40 -0500
Date: Tue, 10 Jan 95 17:13:40 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9501102213.AA08920 at ginger.lcs.mit.edu>
To: gmalkin at xylogics.com, jnc at ginger.lcs.mit.edu
Subject: Re: Last Call: Routing Information Protocol to Historic
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu,
vjs at rhyolite.denver.sgi.com
From: Gary Scott Malkin <gmalkin at xylogics.com>
> With CIDR, this may no longer be true. Remember, the C-space is only
> 12.5% of the total address space, whereas A space is 50%.
I'm a little confused by that. There are only 126 class A networks and
over 16 million class C networks.
Here in the world of CIDR, we don't hand out "network numbers", we hand out
"chunks of the address space"; i.e. some number of potential unique addresses
(i.e. bit patterns). The A-space contains 2^31 unique patterns, 50% of the
total (although some is already allocated), whereas the C-space contains 2^29
unique pattersn, 12.5% (again, some already allocated) of the total 2^32
unique patterns in the IPv4 address space.
The question is, does moving RIP-1 to Historic status accomplish this.
Foo! (Sounds of Malkin being attacked with a large stick! :-) We deliberately
were not saying anything about this particular point!
Maybe we need a new status level to indicate that the protocol was
supplanted by a newer version.
Not an unreasonable idea, but I'll let the IESG/IAB tackle that quesstion.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11137;
10 Jan 95 17:36 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11130;
10 Jan 95 17:36 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19255;
10 Jan 95 17:36 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11110;
10 Jan 95 17:36 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11061;
10 Jan 95 17:34 EST
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa19186;
10 Jan 95 17:34 EST
Received: by atlas.xylogics.com id AA06041 (5.65c/UK-2.1-940401);
Tue, 10 Jan 1995 17:36:45 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Tue, 10 Jan 1995 17:36:45 -0500
Message-Id: <6041.199501102236 at atlas.xylogics.com>
To: jnc at ginger.lcs.mit.edu
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: Noel Chiappa's message of Tue, 10 Jan 95 17:13:40 -0500 <9501102213.AA08920 at ginger.lcs.mit.edu>
Subject: Last Call: Routing Information Protocol to Historic
> Here in the world of CIDR, we don't hand out "network numbers", we hand out
> "chunks of the address space"; i.e. some number of potential unique addresses
> (i.e. bit patterns). The A-space contains 2^31 unique patterns, 50% of the
> total (although some is already allocated), whereas the C-space contains 2^29
> unique pattersn, 12.5% (again, some already allocated) of the total 2^32
> unique patterns in the IPv4 address space.
Oh, I see. Too many overused terms in the Internet.
> Foo! (Sounds of Malkin being attacked with a large stick! :-) We deliberately
> were not saying anything about this particular point!
I've had worse :-)
> Not an unreasonable idea, but I'll let the IESG/IAB tackle that quesstion.
Whatever.
----------------------------------------------------------------------
Gary Malkin Cheap, Fast, Good
(617) 272-8140 Pick two!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11265;
10 Jan 95 17:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11259;
10 Jan 95 17:43 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19425;
10 Jan 95 17:43 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11248;
10 Jan 95 17:43 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11213;
10 Jan 95 17:41 EST
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa19385;
10 Jan 95 17:41 EST
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/;
Relayed; Tue, 10 Jan 1995 16:35:55 +0000
X400-Received: by /PRMD=surf/ADMD=400net/C=nl/; Relayed;
Mon, 9 Jan 1995 12:42:16 +0000
Date: Mon, 9 Jan 1995 12:42:16 +0000
X400-Originator: kiers at terena.nl
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=surf/ADMD=400net/C=nl/;<ab372be906021004b71c at [192.87.30]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Preliminary P...
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: kiers at terena.nl
Message-ID: <ab372be906021004b71c at [192.87.30.3]>
To: terena-ga at terena.nl, wg-all at terena.nl, newsletters at terena.nl,
ceec at terena.nl, M2107 at eurokom.ie, tcp-ip at nic.ddn.mil,
iepg at nri.reston.va.us, ietf at nri.reston.va.us, ccirn at lbl.gov,
acpccirn at aarnet.edu.au, ripe at ripe.net
Subject: Preliminary Programme JENC6 Conference Tel Aviv, May 15-18, 1995
X-Sender: kiers at erasmus.terena.nl
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
------------------------------------------------
PRELIMINARY PROGRAMME AND INVITATION
- JENC6 -
6th Joint European Networking Conference
Tel Aviv, Israel, May 15-18, 1995
Organised by TERENA
Trans-European Research and Education Networking Association
(Established by merger of RARE and EARN)
PROGRAMME COMMITTEE
Jose Barbera, Fundesco, Spain: Chairman
Judith Kiers, TERENA Secretariat,
The Netherlands: Programme Support
Marieke Dekker, TERENA Secretariat,
The Netherlands: Conference Support
Steve Druck, Weizmann Institute, Israel: Local Organisation
Luis Rodriguez Rosello, EU, Belgium: European Union Liaison
Tony Rutkowski, ISOC Reston VA, USA: Internet Society Liaison
Bernhard Plattner, ETH Zurich, Switzerland: TERENA VP Conferences
John Dyer, UKERNA, United Kingdom: Track I
Jeroen Houttuin, TERENA Secretariat,
The Netherlands: Track I
Manfred Bogen, GMD St. Augustin, Germany: Track II
Hannes Lubich, SWITCH, Switzerland: Track II
Ruediger Grimm, GMD Darmstadt, Germany: Track III
Rogelio Montanana, University of Valencia,
Spain: Track IV
David Sitman, Tel Aviv University, Israel: Track IV & VI
Glenn Kowack, EUnet, The Netherlands: Track IV, V & VI
Lajos Balint, Hungarian Academy of Sciences,
Hungary: Track V & VI
Antoine Barthel, RESTENA, Luxembourg: Track V & VI
PRE-CONFERENCE PROGRAMME
TERENA Working Groups
Prior to the conference TERENA Working Group meetings will take place.
During these meetings the different Working Groups will introduce their
current activities and discuss various high priority topics. The meetings
are open to all those who are interested.
IPng TUTORIAL
During this one day tutorial, which is scheduled for Sunday,
May 14, IP New Generation will be discussed by an expert in the field.
This tutorial aims to instruct those that already have a working knowledge
of the subject material.
The fee for the tutorial is USD 250. Please note that this is not included
in the conference registration fee. It is recommended that you register as
soon as possible for the tutorial as the number of places is limited.
NETWORK TECHNOLOGY TRAINING WORKSHOP
May 7 - 14, 1995
A workshop on the installation and use of networking technology is
being planned for the week preceding the conference.
The workshop will cover all aspects of dial-up & TCP/IP connectivity,
and, thus, it is ideally suited for regions with little or no
networking infrastructure. Participants will learn the fundamentals
of establishing and maintaining a TCP/IP network and becoming part
of the global Internet. Topics covered include IP addresses, routers,
name servers, network security, monitoring, network management, and
all aspects of networking over dial-up modems.
The workshop is intended primarily for participants from the
Middle East region, but applications from outside this area will be
accepted if places are available. There will be a limit of approximately
30 participants.
For more information, please contact David Sitman <david at ccsg.tau.ac.il>.
OVERVIEW of Conference Programme
Monday, May 15
01 14:00-15:30 Opening Session
02 16:00-17:30 Parallel Sessions
Tuesday, May 16
03 09:00-10:30 Parallel Sessions
04 11:00-12:30 Parallel Sessions
05 14:00-15:30 Parallel Sessions
06 16:00-17:30 Plenary: interactive session on
'Bringing the world to the desktop'
Wednesday, May 17
07 14:00-15:30 Parallel Sessions
08 16:00-17:30 Parallel Sessions
Thursday, May 18
09 09:00-10:30 Parallel Sessions
10 11:00-12:30 Closing Session
SESSION DESCRIPTIONS and OUTLINE
The programme is divided into six subject tracks, with two, three or four
sessions per track. There will be two parallel streams of sessions.
- TRACK I: NETWORKING TECHNOLOGY AND ENGINEERING
Session I-1: Mobile Computing and Intermittent Connectivity
Chair: Jeroen Houttuin, TERENA Secretariat, The Netherlands
This session examines the technology needed for home working and working
whilst on the move. It also looks at the technological requirements for
small sites that do not require permanent connectivity via leased lines.
Session I-2: Network Performance Issues
Chair: Victor Reijs, SURFnet, The Netherlands
Examines the performance of ATM and IP networks with a view to the
requirements of group and multimedia working, including the specialist
requirements of video
Session I-3: ATM Implementations
Chair: John Dyer, UKERNA, United Kingdom
Practical issues from Networking Groups that have implemented ATM networks.
- TRACK II: COMPUTER SUPPORT FOR COOPERATIVE WORK
Session II-1: Enabling Technologies for Computer-Supported Cooperative Work
(CSCW)
Chair: Prof. Sylvia Wilbur, Queen Mary and Westfield College
(QMW), United Kingdom
This session deals with underlying software technologies necessary to
design effective CSCW applications.
Session II-2: CSCW Integration
Chair: Manfred Bogen, GMD St. Augustin, Germany
The combination of existing communication services with cooperation and
coordination tools is presented in this session.
Session II-3: Information Aspects of CSCW
Chair: Hannes Lubich, SWITCH, Zurich, Switzerland
In this session, aspects of generic representation of information required
for CSCW applications and environments are discussed.
- TRACK III: SECURITY AND PRIVACY
Session III-1: Security Applications
Chair: Manel Medina, UPC Barcelona, Spain
This session presents papers on experiences with the implementation of
secure commmunication applications, in particular network management and
document exchange.
Session III-2: Security Architectures and Infrastructures
Chair: Ruediger Grimm, GMD Darmstadt, Germany
This session presents papers on requirements for service, technical design
and structure of security systems and public key certification authorities.
- TRACK IV: PROVIDING AND ACCESSING INFORMATION
Session IV-1: World-Wide Web Applications: the cutting edge
Chair: Rogelio Montanana, University of Valencia, Spain
New developments in the use and management of the World-Wide Web.
Session IV-2: Advances in Directory Services
Chair: Paul Barker, University College London, United Kingdom
New ways of manipulating X.500.
Session IV-3: Electronic Publishing and Information Retrieval
Chair: David Sitman, Tel Aviv University, Israel
The changing face of publishing and retrieving information over the net.
- TRACK V: POLICY RELATED ISSUES
Session V-1: Networking for Europe
Chair: Tomaz Kalin, TERENA Secretariat, The Netherlands
Building a high speed networking infrastructure for the European research
and academic community is a key activity in the mid-90's. The selection of
presentations will disseminate information about the latest results and
plans.
Session V-2: The changing scene: Case studies
Chair: Glenn Kowack, EUnet, The Netherlands
The case-studies presented are illustrating several important aspects of
how the networking infrastructure and the accessible services
improve and even refashion the communication and cooperation related
affairs in research and education.
- TRACK VI: REGIONAL ISSUES - 'Towards Networked Communities'
Session VI-1: Building the national infrastructure
Chair: Lajos Balint, Hungarian Academy of Sciences, Hungary
Several brief contributions will illustrate the emerging activities toward
the establishment of solid national networking infrastructures and services
in developing areas.
Session VI-2: High performance networking and services in
regional and metropolitan areas
Chair: Antoine Barthel, RESTENA, Luxembourg
The papers presented in this session are trying to give an overview of
those different activities devoted to upgrading, expanding and enhancing
regional and metropolitan area networking infrastructures and information
services.
DEMONSTRATIONS
At the Conference there will be a demonstrations area where participants
may visit a number of stands to see displays and demonstrations of various
projects and applications of networking services for the academic
community.
CONFERENCE EVENTS
All participants and accompanying persons are invited to attend the
following events. We hope these events will provide an opportunity to
renew old friendships and to create new ones with colleagues from all
over the world.
- OPENING RECEPTION
Monday, May 15 from 18:00-19:00
You will be able to enjoy light refreshments and entertainment in an
enchanting environment.
- GALA DINNER
Tuesday, May 16 from 20.00 - 23.00
An evening of fine dining, entertainment and Middle Eastern hospitality.
- BOFs / Special Interest Groups
Wednesday, May 17 from 18.00 - 20.00
This timeslot is allocated to Birds of a Feather Sessions and Special
Interest Groups that are keen to present and/or demonstrate their projects.
- JERUSALEM TOUR
Wednesday morning, May 17 or Thursday afternoon, May 18, 1995
All participants are invited to join in a visit to the holy city of
Jerusalem, capital of three world religions, with attractive old and new
monuments.
CONFERENCE VENUE
Dan Panorama Convention Center
10 Y. Kaufman Street
TEL AVIV
ISRAEL
Tel. +972(3)519 0190
Fax. +972(3)517 1777
REGISTRATION INFORMATION
CONFERENCE REGISTRATION FEE(S):
Early Registration (Before April 10) ECU 425 USD 520
Late Registration (April 10 - May 6) ECU 475 USD 580
Desk Registration (from May 6) ECU 525 USD 640
Accompanying Person(s)
(Includes Opening Reception,
Gala Dinner and Jerusalem Tour) ECU 75 USD 92
Tutorial ECU 205 USD 250
REGISTRATION FEE COVERS
The registration fee covers attendance to all conference sessions,
the Opening Reception, Gala Dinner, Jerusalem Tour as well as luncheons
and coffee or tea. Of course also all conference materials, including the
programme, full paper proceedings and other conference publications can be
found in the conference bag.
The accompanying person's fee includes the Opening Reception, the Gala
Dinner and the Jerusalem Tour. Attendance at the sessions, drinks or meals
during the day and conference materials are not included in this fee.
CONFIRMATION OF REGISTRATION
A letter confirming conference registration and hotel accommodation will be
sent to each participant upon receipt of the completed registration form
and accompanying payment.
This letter should be presented upon registration for the conference.
REGISTRATION DESK
The registration desk will be open on Sunday, May 14 8:00-18:00 and Monday,
May 15, from 08:00 to 20:00 and throughout the Conference from 8:00 to
18:00.
NETWORKING FACILITIES
A terminal room will be available to conference participants with computers
and terminals connected to the Internet for electronic mail and other
network services.
CONFERENCE VENUE
The conference will be held at the Dan Panorama Hotel, 10 Y. Kaufman
street, Tel Aviv. The Dan Panorama Hotel offers 5-star facilities and
services. This is the largest convention hotel complex in Tel Aviv,
overlooking the beachfront, only a short walk from Tel Aviv's new
commercial centers and close to the city center. It distinguishes itself
by a range of 5-stars facilities and services such as bars and a choice of
restaurants, swimming pool, sundeck and a fully equipped Health and Fitness
Center. The Dan Panorama hotel is located approximately 25 kilometers from
Ben Gurion International Airport.
HOTEL ACCOMMODATION
The following hotels have rooms at specially reduced conference rates: Dan
Panorama hotel (5-star) - Conference Venue, the Metropolitan Hotel (4 star)
and City hotel (3 star) as follows:
HOTEL SINGLE ROOM DOUBLE ROOM
(1 person) (2 persons)
DAN PANORAMA USD 134 USD 154
(Deluxe room)
DAN PANORAMA USD 104 USD 124
(Regular room)
METROPOLITAN* USD 75 USD 92
CITY* USD 69 USD 88
Hotel rates are in US dollars per night, and include full Israeli buffet
breakfast and service charges.
*Please note that the Metropolitan and City Hotel are at approximately 20
minutes walking distance from the Conference Center.
HOTEL RESERVATIONS
It is important to make hotel reservations early as rooms will be released
on April 10, 1995. In order to benefit from these rates, reservations and
payments for accommodation must be made through International Travel &
Congresses Ltd., and not directly to the hotel. Reservations should be made
as soon as possible on the enclosed Accommodation Form, accompanied by a
1 night accommodation per person.
PAYMENT METHOD
- By bankers draft, payable to: INTERNATIONAL TRAVEL & CONGRESSES LTD.
- By bank transfer to INTERNATIONAL TRAVEL & CONGRESSES LTD.
Account No. 396699, Israel Discount Bank, Branch 100, 4 Rothschild
Boulevard, 66881 Tel Aviv, Israel
- The following credit cards are accepted: Visa, Diners Club,
American Express, MasterCard & EuroCard
Only MasterCard/EuroCard is accepted for Desk registration payment.
CANCELLATION CONDITIONS FOR ACCOMMODATION / TOURS
Refund of accommodation and tour payment will be made if written
cancellation is received as follows:
- Before April 1 - full refund less USD 40.- handling fee
- After April 1 - the cost of one night's accommodation and 25% of
the tour payments will be deducted.
GENERAL INFORMATION
OFFICIAL CARRIER
EL-AL is the official carrier for this conference.
FLIGHT RECONFIRMATION.
Most airlines require reconfirmations for flights out of Israel 72 hours
before flight time. The Registration Desk will gladly reconfirm your
reservation for you if you bring them a copy of your ticket.
VISAS
Residents of most countries are issued tourist visas when entering Israel
and there is no need to obtain visas ahead of time. We suggest, however,
that you check this with your travel agent. Delegates requiring a visa
should apply directly to the nearest Israeli Consulate approximately
3 months prior to the conference. If you need any assistance please contact
INTERNATIONAL TRAVEL & CONGRESSES at least 6 weeks before the conference.
CURRENCY / CREDIT CARDS.
The unit of currency is the Israeli Shekel (IS). International credit
cards are accepted for payment in most hotels, restaurants and shops.
The exchange rate (December 1994): USD 1.- is approximately IS 3.-
VOLTAGE
The electricity supply in Israel is 220 V AC.
WEATHER AND CLOTHING.
May is pleasantly warm and dry. Average temperatures are 16-28 C (59-76 F).
Dress will be informal for most occasions. A light coat may be necessary
for the evenings. Comfortable walking shoes, head coverings and bathing
suits are also recommended.
THE CITY OF TEL AVIV - JAFFA.
Tel Aviv is the commercial and entertainment capital of Israel. It lies
along the Mediterranean Sea. Tel Aviv houses many institutions of culture,
art and entertainment such as museums, theaters, the Philharmonic
Orchestra, and Tel Aviv University. Jaffa, now a neigbourhood of Tel Aviv,
is on the shores of the Mediterranean Sea, south of Tel Aviv. According to
tradition it was named after Jepheth son of Noah, who built the town. Jaffa
served as an ancient Israeli port during the reign of King Solomon, and
later as a Hellenistic and Roman port. The ancient city of Jaffa has been
partially restored and today is an artists' colony and entertainment
center.
LOCAL TRANSFER
Transportation from Ben Gurion International Airport to Tel Aviv
(approx. 30 minutes) is available as follows:
- Taxi: approx USD 15.- per ride (night supplement of 25% after 18:00
hours)
- Airport Bus No. 222 (every 15 minutes)
From Ben Gurion Airport to Tel Aviv. Approx. USD 4.- per person
Sun - Fri 04:00 - 24:00 hours
Sat 13:00 - 24:00 hours
CONFERENCE REGISTRATION, ACCOMMODATION AND TOURS
INTERNATIONAL TRAVEL & CONGRESSES LTD
P.O.Box 29313
9 Rothschild Blvd.
61292 Tel Aviv
Israel
Tel: +972 3 5102538 Fax: +972 3 5160604 Telex: 371767 INTVL IL.
E-mail: info at jenc6.ac.il - for tourist information
register at jenc6.ac.il - to register for the Conference
GENERAL ENQUIRIES
TERENA Secretariat
Singel 466-468
NL-1017 AW AMSTERDAM
The Netherlands
Tel: +31 20 639 1131 Fax: +31 20 639 3289
E-mail: jenc6-sec at terena.nl
TOURS INFORMATION
PRE-CONFERENCE TOUR
TOUR A - 2 DAYS GALILEE, MAY 11 - 13, 1995
Thursday, May 11
Overnight in Metropolitan or Dan Panorama Hotel in Tel Aviv.
Friday, May 12
Drive northwards along the Mediterranean coast to Caesarea (antiquities of
Roman and Crusader periods). Arrive in Haifa, Israel's main port city.
Continue to Akko and the subterranean Crusader city. Drive through the
Galilean Hills to Safed, ancient city of the Kabbala and artists colony.
Dinner and overnight Kibbutz Guest House
Saturday, May 13
Boat ride on the Sea of Galilee (Lake Kinnereth). Visit Tabgha -
traditional site of the Miracle of the Loaves and Fishes: Capernaum -
ancient synagogue. Drive southward along the Rift Valley to view the
archaeological excavations at Beit Shean, which include a Byzantine city
and 1st century theater. Return to Tel Aviv. End of tour.
Price: For a minimum of 15 participants
Metropolitan - USD 241 per person sharing a twin room
- USD 310 per person in a single room
Dan Panorama - USD 270 per person sharing a twin room
- USD 326 per person in a single room
Price Includes:
1 nights' accommodation in first class hotel in Tel Aviv and 1 night in
kibbutz guest house. Entrance fees, porterage, 1 dinner, 2 full touring
days with a licensed English-speaking guide in a modern air-conditioned
bus.
POST CONFERENCE TOURS
TOUR B - EILAT, May 19 - 21
Price of package includes flight to Eilat from Tel Aviv and return to Tel
Aviv; 2 nights accommodation on a bed and breakfast basis; one day yacht
cruise including lunch.
Price:First class hotel - USD 311 per person sharing a twin room
USD 383 per person in a single room
Deluxe hotel - USD 402 per person sharing a twin room
USD 510 per person in a single room
TOUR C - 2 DAYS GALILEE AND GOLAN HEIGHTS, May 19 - 21
Friday, May 19
Pick up from your hotel and drive northwards to the ancient ruins of
Megiddo. Visit King Solomon's stables and the famous water tunnel. On to
Nazereth to visit the Church of the Annunciation. Visit the mystical city
of Safed, with its ancient synagogues and artists's quarter.
Dinner and overnight at Kibbutz Guest House
Saturday, May 20
Tour the Golan Heights and visit the new city of Katzrin, capital of the
Golan. Enjoy a boat ride on the Sea of Galilee. Travel to Beit Shean to
tour the archaeological excavations, which include a Byzantine city and
1st century theater. Return to Tel Aviv. End of tour.
Price: For a minimum of 15 participants
USD 196 per person sharing a twin room.
USD 235 per person in a single room.
Price includes: 1 night accommodation in a Kibbutz Guest House. Entrance
fees, porterage, 1 dinner, 2 full touring days with an English-speaking
licensed guide and a modern air-conditioned bus.
(Extra accommodation may be reserved at the specified conference rates.)
TOUR D - HALF DAY TOUR TEL AVIV CITY (Monday, May 15)
Drive through the modern city of Tel Aviv. Visit the ancient port city of
Jaffa, with its cobblestone alleyways. On to the Tel Aviv University campus
to visit the Museum of the Diaspora.
Price: USD 22 per person
TOUR E - FULL DAY TOUR TO MASSADA AND THE DEAD SEA (Tuesday, May 16)
Drive through the Judean Wilderness to the Dead Sea, lowest spot on
earth. Ascend by cable car to the Herodian fortress of Massada. See the
ancient water supply system, synagogue, Herod's palace, Roman camp, and
more. Descend by cable car and visit the Ein Gedi spa for a swim in the
Dead Sea. Return to Tel Aviv.
Price: USD 59 per person
TOUR F - FULL DAY TOUR TO CAESAREA, AKKO, ROSH HANIKRA (Wednesday, May 17)
The tour includes Caesarea (Roman and Crusader ruins); Haifa, Mt. Carmel
and the Bahai Shrine; Akko, Crusader buildings and crypts; the grotto at
Rosh Hanikra. Return to Tel Aviv.
Price: USD 53 per person
All Tours are based on minimum of 25 participants per tour.
Tours do not include: Tips, extra meals, drinks or any other personal
items.
Deposit : USD 100 per person per tour for tour B and C
Full pre-payment for pre-conference tour A
OPTIONAL DINNER & ENTERTAINMENT - Wednesday-evening, May 17.
Optional Dinner and Entertainment, Dinner at a Restaurant in Jaffa's
Ancient Port proceeding on to one of Israel's Exclusive Clubs in the
Artist's Quarter of old Jaffa for an Evening of Music and Comedy.
Price: USD 55 per person.
Price includes: Transfers by deluxe bus from/to Dan Panorama
Hotel accompanied by a hostess, Dinner and
Entertainment.
REGISTRATION AND ACCOMMODATION FORM
===================================
Please type or fill out in BLOCK letters and mail to:
JENC6 - May 1995
c/o International Travel & Congresses Ltd.
P.O. Box 29313, 61292 Tel Aviv, Israel
Tel: + 972-3-5102538; Fax: + 972-3-5160604
E-mail: register at jenc6.ac.il
----------------------------------------------------------------------
CONFERENCE REGISTRATION FEE(S):
Early Registration (Before March 30) ECU 425 USD 520 USD ____
Late Registration (March 30 - May 6) ECU 475 USD 580 USD ____
Desk Registration (from May 6) ECU 525 USD 640 USD ____
Accompanying Person(s)
(Includes Opening Reception,
Gala Dinner and Jerusalem Tour) ECU 75 USD 92 USD ____
Tutorial ECU 205 USD 250 USD ____
TOTAL AMOUNT TO BE CHARGED: USD ____
----------------------------------------------------------------------
----------------------------------------------------------------------
ACCOMMODATION & TOURS RESERVATION:
Name _________________________________________________________________
Last First Middle Initial Title
Full Mailing Address
______________________________________________________________________
______________________________________________________________________
Country Telephone Fax E-mail
______________________________________________________________________
I will share a room with _____________________________________________
Accommodation:
A deposit of 1 night hotel accommodation is required in order to guarantee
your reservation
Dan Panorama Tel Aviv
(Deluxe) USD 134 USD 154
Dan Panorama Tel Aviv
(Regular) USD 104 USD 124
Metropolitan
USD 75 USD 92
City
USD 69 USD 88
Arrival Date:_______ Departure Date:_______ No of nights:____
Optional Pre/Post conference tours:
USD 100.- deposit per person for post conference tours.
Full pre-payment for pre-conference tour.
p/p in SGL p/p in DBL
Pre-conference tour A
Metropolitan USD 310 USD 241
Dan Panorama USD 326 USD 270
Post-conference tour B
First Class hotel USD 383 USD 311
Deluxe hotel USD 510 USD 402
Post-conference tour C USD 235 USD 196
Tour D USD 22 (no hotel)
Tour E USD 59 (no hotel)
Tour F USD 53 (no hotel)
Dinner/Entertainment USD 55
TOTAL Accommodation & Tours USD ______
Deposit USD ______
Balance Due USD ______
Do you have a special accommodation request?___________________
Do you have a special diet?____________________________________
Jerusalem Tour (please select): Wednesday AM __ Thursday PM __
Payments should be made in US Dollars only. All costs of bank transfers to
be paid by the transmitter.
Please state JENC6 and your name on all payments
For Israeli participants: Payments to be made according to "Shaar
Yatsig" on day of payment + VAT
Method of payment:
________________________________________________________________
Date of Expiry ________________
Cardholder's name __________________
Account no: 396699, Israel Discount Bank, Branch 100, 4 Rothschild
Boulevard 66881 Tel Aviv, Israel
Date ________________ Signature ____________________
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11437;
10 Jan 95 17:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11431;
10 Jan 95 17:50 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19601;
10 Jan 95 17:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11420;
10 Jan 95 17:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11363;
10 Jan 95 17:48 EST
Received: from Valinor.BARRNET.NET by CNRI.Reston.VA.US id aa19555;
10 Jan 95 17:48 EST
Received: (from vaf at localhost) by valinor.barrnet.net (8.6.8/8.6.6) id OAA20757; Tue, 10 Jan 1995 14:47:49 -0800
Date: Tue, 10 Jan 95 14:47:49 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.barrnet.net>
To: Gary Scott Malkin <gmalkin at xylogics.com>
Cc: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US,
vjs at rhyolite.denver.sgi.com
Office: Spruce Hall F15, (415) 723-6860
USMail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Re: Last Call: Routing Information Protocol to Historic
In-Reply-To: Your message of Tue, 10 Jan 1995 17:00:14 -0500
Message-ID: <CMM.0.90.2.789778069.vaf at valinor.barrnet.net>
> With CIDR, this may no longer be true. Remember, the C-space is only
> 12.5% of the total address space, whereas A space is 50%. I don't know
> what the current consumption rate is, but I assume we will run out of
> C-space at some point, at which point, we're going to have to start
> handing out chunks of A's. So, your net will be a chunk of an A (i.e.
> one subnet mask), which you chop into smaller pieces (another subnet
> mask).
I'm a little confused by that. There are only 126 class A networks and
over 16 million class C networks.
Don't think of space in terms of classful network numbers, think of it in
terms of bits or total addresses (note that the numbers which follow don't
include "reserved" network numbers like 0.0.0.0 or 127.0.0.0).
Total IP address space is 32 bits or 4,294,967,296 possible addresses.
One bit determines if address is "class-A". This leaves 31 bits of "class-A"
space, for a possible 2,147,483,648 addresses. This is equal to 128 networks of
16,777,216 addresses each, 8,388,608 networks of 256 addresses, or whatever
combination of network/address bits desired if pure CIDR is used.
Two bits determine if address is "class-B". This leaves 30 bits of "class-B"
space, for a possible 1,073,741,824 addresses.
Three bits determine if address is "class-C". This leaves 29 bits of "class-C"
space, for a possible 536,870,912 addresses. This is equal to 2,097,152
networks of 256 addresses.
Remainder of address space ("class-D", etc.) is also 29 bits.
Once all of the "class-C" space is gone, the unused class-A space is the
obvious place to start making new address assignments. Read Geoff Huston's
recent Internet Draft which discusses some considerations which must be made
before we start doing this.
--Vince
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11581;
10 Jan 95 18:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11575;
10 Jan 95 18:04 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19919;
10 Jan 95 18:04 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11563;
10 Jan 95 18:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11537;
10 Jan 95 18:02 EST
Received: from milou.inria.fr by CNRI.Reston.VA.US id aa19819;
10 Jan 95 18:00 EST
Received: by milou.inria.fr
(5.65c8/IDA-1.2.8) id AA01025; Tue, 10 Jan 1995 18:38:08 +0100
Message-Id: <199501101738.AA01025 at milou.inria.fr>
To: mice at cs.ucl.ac.uk, end2end-interest at isi.edu, hipparch at sophia.inria.fr,
effelsberg at pi4.informatik.uni-mannheim.de, antony at ee.uts.edu.au,
herrmann at ls4.informatik.uni-dortmund.de, afifi at rsm.enst-bretagne.fr,
erbi at eurecom.fr, fuchs at informatik.tu-cottbus.de, oivind at brage.nta.no,
carle at telematik.informatik.uni-karlsruhe.de,
Burkhard.Stiller at cl.cam.ac.uk, aps at ee.uts.edu.au, calvert at cc.gatech.edu,
schmidt at cs.wustl.edu, ilka at prz.tu-berlin.d400.de, ichris at sophia.inria.fr,
oechslin at di.epfl.ch, diaz at laas.fr, bengta at sics.se, per at sics.se,
schmidt at telematik.informatik.uni-karlsruhe.de,
zit at telematik.informatik.uni-karlsruhe.de, plageman at unik.no,
a.ghosh at cs.ucl.ac.uk, j.crowcroft at cs.ucl.ac.uk, ddc at lcs.mit.edu,
llp at cs.arizona.edu, Danthine at vm1.ulg.ac.be, melfyn at pophost.dstc.edu.au,
dlt at lcs.mit.edu, sean at cs.arizona.edu, craig at aland.bbn.com,
stefis at pi4.informatik.uni-mannheim.de, cmw at sce.carleton.ca,
meyden at theory.ntt.jp, sajkowski at pozn1v.tup.edu.pl,
Fabrice.Clerot at lannion.cnet.fr, mistral at sophia.inria.fr,
drobnik at terra.tm.informatik.uni-frankfurt.de, bansal at ccrl.nj.nec.com,
MIKE.CASEY at wkap.nl, dcf at bellcore.com, yutaka at kuamp.kyoto-u.ac.jp,
ajc at inesc.pt, tohme at res.enst.fr, hp at csc.ncsu.edu,
Guy.Pujolle at prism.uvsq.fr, hr at zurich.ibm.com,
spaniol at i4.informatik.rwth-aachen.de, P.Kirstein at cs.ucl.ac.uk,
M.Handley at cs.ucl.ac.uk, besson at medoc.cica.fr, reres at laas.fr,
trace at irisa.fr, toutibp at ibp.fr
To: gdr-prog at geocub.greco-prog.fr, roro at enstb.enst-bretagne.fr,
rs at cma.cma.fr, ruget at chorus.fr, sandoz at eldi.epfl.ch, schnoebelen at imag.fr,
schwaab at loria.loria.fr, shapiro at corto.inria.fr, sifakis at imag.fr,
sorel at seti.inria.fr, stefani at issy.cnet.fr,
steyaert at absinthe.polytechnique.fr, toinard at asimov.cnam.fr,
trystram at imag.fr, valette at laios.cert.fr, Jean-Pierre.Verjus at imag.fr,
vidalnaq at aar.alcatel-alsthom.fr, virot at univ-orleans.fr,
wileden at aenegada.inria.fr, yolande at cs.kuleuven.ac.be,
yrobert at lip.ens-lyon.fr, A18613 at ccsmvs.u-strasbg.fr,
DDUVAL at frgren81.bitnet, Jacques.Morgenstern at sophia.inria.fr,
collette at inria.fr, dduval at cict.fr, dellado at alpe.imag.fr,
dezou at frbdx11.bitnet, dp at litp.ibp.fr, martinet at ceremab.greco-prog.fr,
mlv at frunip62.bitnet, rauzy at lumimath.univ-mrs.fr, tcsmn at litp.ibp.fr,
vallee at geocub.greco-prog.fr, dony at crim.fr, em at info.ucl.ac.be,
eychenne at aar.alcatel-alsthom.fr, fabre at laas.fr, fandre at irisa.fr,
feraud at irit.fr, fernand at imag.fr, ferrie at crim.laas.fr,
xtp-relay at cs.concordia.ca, jain at engin.umich.edu, jajodia at sitevax.gmu.edu,
jakobs at informatik.rwth-aachen.de, jeffay at cs.unc.edu, mrj at rod.mitre.org,
kado at isl.hiroshima-u.ac.jp, kahn at parc.xerox.com, tkarren at ingres.com,
kawagoe at tsl.cl.nec.co.jp, rnk at sei.cmu.edu, keith at pioneer.arc.nasa.gov,
klas at icsi.berkeley.edu, korfhage at icarus.lis.pitt.edu,
korfhage at weston.poly.edu, hfk at mitl.com, fl08+ at andrew.cmu.edu,
lam at cs.utexas.edu
To: laukee at canon.co.uk, dlee at cis.ohio-state.edu,
klaus at informatik.rwth-aachen.de, ying at saturn.cs.swin.oz.au,
haim at cs.uml.edu, ylien at ihlpy.att.com, hlinger at fcit.monash.edu.au,
tdcl at enga.bu.edu, sdl at mitre.org, liu at ernie.scr.siemens.com,
maraninx at imag.imag.fr, rmarcus at atc.boeing.com, h133mar at ella.hu,
71431.3312 at compuserve.com, edward.martini at eng.sun.com,
masui at shpcsl.sharp.co.jp, pmatsira%wcu.BITNET at mitvma.mit.edu,
rajiv at ms.uky.edu, kmw at informatik.uni-erlangen.de, midkiff at vtvm1.cc.vt.edu,
miyamoto at shpcsl.sharp.co.jp, miyao at mis.hiroshima-u.ac.jp,
morimoto at trlvm.vnet.ibm.com, bam at a.gp.cs.cmu.edu,
klara at gradient.cis.upenn.edu, neuhold at darmstadt.gmd.de, nigam at mitre.org,
okamoto at csd.sumikin.co.jp, ola at adm.csc.ncsu.edu, osborne at software.org,
ozsu at cs.ualberta.ca, cap1 at thumper.bellcore.com, pax at ankh.metrolink.com,
pezze at ipmel2.elet.polimi.it, picone at csc.ti.com, rakow at darmstadt.gmd.de,
wilko at informatik.rwth-aachen.de, s.reisman at compmail.com,
riedl at hannibal.cs.umn.edu, roman at wucs1.wustl.edu, marek at uh.edu,
sato at huis.hiroshima-u.ac.jp, schnorf at canon.com, schooler at isi.edu,
schwan at cc.gatech.edu, cts at cs.hut.fi, senay at seas.gwu.edu,
mshakar at vrit01.eg, shan at hplmcs.hpl.hp.com, shekhar at cs.umn.edu,
sheng at mis.arizona.edu, bjshep at ausvm6.vnet.ibm.com, ben at cs.umd.edu,
sinha at trl.mei.co.jp, sklar at era.com, son at server.cs.virginia.edu,
asood at gmuvax.gmu.edu, speegle at mercury.baylor.edu,
steinmet%dhdibm1.BITNET at mitvma.mit.edu
To: sms at sei.cmu.edu, pds at cis.ufl.edu, stro at merl.com, jks at usa.ece.cmu.edu,
sugihara at freiland.ics.hawaii.edu, deborah at citi.umich.edu,
pete at icbl.heriot-watt.ac.uk, tanimoto at cs.washington.edu,
tappan at software.org, tsotras at kanchi.poly.edu, jurban at enws104.eas.asu.edu,
ventre at icsi.berkeley.edu, vetter at cs.umn.edu, walpole at cse.ogi.edu,
wei at csufres.csufresno.edu, kywhang at mozart.kaist.ac.kr,
klwu at watson.ibm.com, wuu at ctt.bellcore.com, yama at trdc008.csc.ti.com,
yoshi at huis.hiroshima-u.ac.jp, yu at dbis.eecs.uic.edu, psyu at watson.ibm.com,
magda at pender.ee.upenn.edu, znati at cs.pitt.edu, blattner at ocfkms.llnl.gov,
jol at hpl.hp.com, mmm-people at isi.edu, rem-conf at es.net, nik at clos.nnov.su,
kas at clos.nnov.su, Geoff Coulson <geoff at comp.lancs.ac.uk>,
ifip-6-1 at labs-n.bbn.com, nossdav95 at telecomm.hpl.hp.com,
ietf at CNRI.Reston.VA.US, ripe at ripe.net, cost237_1 at aaf.alcatel.at,
hippi at think.com
Subject: HPDC-4 Call For Papers
Date: Tue, 10 Jan 1995 18:38:07 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Walid Dabbous <Walid.Dabbous at sophia.inria.fr>
Dear collegue,
Here follows the CFP for HPDC-4. Please note that the deadline
is February 3, 1995. Sorry if you receive this more than once.
Walid Dabbous
dabbous at sophia.inria.fr
---------------------------------------------------------
CALL FOR PAPERS
FOURTH IEEE INTERNATIONAL SYMPOSIUM ON
HIGH PERFORMANCE DISTRIBUTED COMPUTING (HPDC-4)
August 1-4, 1995
The Ritz Carlton, Pentagon City, Virginia USA
SPONSORS:
- IEEE Computer Society - TC on Distributed Processing
- Northeast Parallel Architectures Center (NPAC) at Syracuse University
IN COOPERATION WITH:
- ACM SIGCOMM
- Rome Laboratory
THEME:
The Fourth International Symposium on High Performance Distributed
Computing is a forum for presenting the latest research findings on the
application of parallel and distributed computing for solving computationally
intensive applications across a network of high-performance computers.
Authors are invited to submit full papers on all aspects of high performance
distributed computing. Papers that deal with high-level tools,
languages, and environments, as well as novel applications, are of
particular interest. Papers receiving the best reviews
will also be considered for publication in a special issue
of the journal Concurrency: Practice and Experience
on high-performance distributed computing.
TOPICS OF INTEREST (include, but are not limited to):
- Software environments and language support
for high performance distributed computing
- Parallel and distributed algorithms to solve computationally
intensive problems across a LAN, MAN, or WAN.
- High performance I/O and file systems
- Fault tolerance
- Architectural support for high-speed communications or
interconnection networks
- Efficient communication interfaces for distributed computing
- Gigabit network architectures
- Networking for multimedia data
- HPDC applications and case studies
SYMPOSIUM GENERAL CHAIR: Geoffrey Fox, NPAC, Syracuse University,
(315)443-4741, hpdc at nova.npac.syr.edu
SYMPOSIUM STEERING COMMITTEE:
- Salim Hariri, Syracuse University (Chair)
(315) 443-4282 hariri at cat.syr.edu
- Tilak Agerwala, IBM
- Andrew Grimshaw, University of Virginia
- H. T. Kung, Harvard University
- Daniel McAuliffe, Rome Laboratory
- C. S. Raghavendra, Washington State University
PROGRAM COMMITTEE CHAIR: A. S. Grimshaw, University of Virginia
Charlottesville, VA
PROGRAM COMMITTEE:
- Dharma Agrawal, North Carolina State University
- Prathima Agrawal, AT&T Bell Labs
- Ishfaq Ahmad, Hong Kong University of Science and Technology
- Ian F. Akyildiz, Georgia Tech
- Marco Annaratone, DEC
- Abhaya Asthana, AT&T
- Ken Birman, Cornell University
- Suresh Chalasani, University of Wisconsin, Madison
- Monsong Chen, IBM Research
- Roger Chen, Syracuse University
- Ray Cline, Sandia National Laboratory
- Jon Crowcroft, University College London
- Walid Dabbous, INRIA, France
- Jack Dongarra, University of Tennessee
- Patrick Dowd, SUNY Buffalo
- Dennis Duke, SCRI/Florida State University
- Stuart Elby, NYNEX Science and Technology
- Richard Freund, NRaD
- J.J. Garcia-Luna, University of California, Santa Cruz
- Salim Hariri, Syracuse University
- S. H. Hosseini, University of Wisconsin, Milwaukee
- T. V. Lakshman, Bell Communications Research
- C. R. Mechoso, UCLA
- Paul Messina, Caltech
- Dick Metzger, Rome Laboratory
- Paul Mockapetris, USC/ISI
- John Morrison, Los Alamos National Laboratory
- Ira Pramanick, IBM
- Michael Quinn, Oregon State University
- C. S. Raghavendra, Washington State University
- Karsten Schwan, Georgia Institute of Technology
- Nita Sharma, Ncube Inc.
- A. Skjellum, Missippi State University
- Rick Stevens, Argonne National Laboratory
- Vaidy Sunderam, Emory University
- Makoto Takizawa, Tokyo Denki University, Japan
- Alexander Thomasian, IBM Research
- Satish Tripathi, University of Maryland
- Anujan Varma, UCSC
- Pen-Chung Yew, University of Minnesota
PUBLICITY CHAIRS:
North America: T. V. Lakshman, Bell Communications Research
Europe: Walid Dabbous, INRIA, France
Asia: Makoto Takizawa, Tokyo Denki University, Japan
TUTORIAL CHAIR: Vaidy Sunderam, Emory University, (404) 727-5926,
vss at mathcs.emory.edu
EXHIBITS CHAIR: C. S. Raghavendra, Washington State University
REGISTRATION AND LOCAL ARRANGEMENTS:
Peggy Van Arnam, Syracuse University
Phone:(315) 443-3333 Fax: (315) 443-1168 e-mail: MJVANARN at SUADMIN.syr.edu
PAPER SUBMISSIONS:
Authors are requested to submit by February 3, 1995 five copies
of their manuscript (not to exceed 25 double-spaced pages) to:
Prof. A. S. Grimshaw
Department of Computer Science, Olsson Hall
University of Virginia
Charlottesville, VA 22903-2442
USA
804-982-2200
grimshaw at virginia.edu
Authors will be notified by April 25,1995.
Final camera-ready copies are due by May 26, 1995.
Tutorials proposals should be submitted to the Tutorials Chair.
For more information about the symposium,
e-mail to hpdc at nova.npac.syr.edu
or
see our WWW page at: http://uvacs.cs.virginia.edu/~hpdc95/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14406;
10 Jan 95 21:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14400;
10 Jan 95 21:39 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24043;
10 Jan 95 21:39 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14378;
10 Jan 95 21:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14307;
10 Jan 95 21:36 EST
Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa23992;
10 Jan 95 21:36 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 11 Jan 95 11:35:55 +0859
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9501110236.AA08580 at necom830.cc.titech.ac.jp>
Subject: Re: Last Call: Tags for the identification of languages to Proposed
To: "Donald E. Eastlake 3rd" <dee at skidrow.tay.dec.com>
Date: Wed, 11 Jan 95 11:35:53 JST
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9501101545.AA13446 at skidrow.tay.dec.com>; from "Donald E. Eastlake 3rd" at Jan 10, 95 10:45 am
X-Mailer: ELM [version 2.3 PL11]
> All the formating stuff you are talking about it taken care of
> by the RFC Editor.
>
> Donald
Yes, the confusion on the format of RFCs are already taken care of
as a clear document of RFC 1543,
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00691;
11 Jan 95 5:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00685;
11 Jan 95 5:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01946;
11 Jan 95 5:01 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00665;
11 Jan 95 5:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00573;
11 Jan 95 4:47 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01738;
11 Jan 95 4:47 EST
Received: from relay2.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA19120>; Wed, 11 Jan 1995 01:47:13 -0800
Received: from trane.uninett.no by relay2.UU.NET with SMTP
id QQxyex16741; Wed, 11 Jan 1995 04:47:01 -0500
Received: by trane.uninett.no id AA21223
(5.67b/IDA-1.5 for info-ietf at uunet.uu.net); Wed, 11 Jan 1995 10:46:49 +0100
To: info-ietf at uunet.uu.net
Path: uninett.no!hta
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Harald T. Alvestrand" <hta at uninett.no>
Newsgroups: info.ietf
Subject: Re: Last Call: Tags for the identification of languages to Proposed
Date: 11 Jan 1995 09:46:47 GMT
Organization: Uninett
Lines: 14
Distribution: world
Message-Id: <3f09e7$kn3 at trane.uninett.no>
References: <9501100707.AA04700 at necom830.cc.titech.ac.jp> <9501101545.AA13446 at skidrow.tay.dec.com>
Nntp-Posting-Host: domen.uninett.no
The draft unfortunately shows the result of lack of MIME support at the
IETF secretariat.
But the point is moot, since the RFC Editor insists on marking up the
source from scratch on all RFCs.
And yes, the draft DOES need ISO 8859-1 characters if the examples
of non-English text are to be properly represented.
--
Harald Tveit Alvestrand
Harald.T.Alvestrand at uninett.no
G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
http://domen.uninett.no/~hta/
+47 73 59 70 94
My son's name is Torbjxrn. The letter between "j" and "r" is o with a slash.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01024;
11 Jan 95 5:45 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01018;
11 Jan 95 5:45 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02520;
11 Jan 95 5:45 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01007;
11 Jan 95 5:45 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00971;
11 Jan 95 5:43 EST
Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa02484;
11 Jan 95 5:43 EST
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 11 Jan 95 19:42:32 +0900
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9501111042.AA10411 at necom830.cc.titech.ac.jp>
Subject: Re: Last Call: Tags for the identification of languages to Proposed
To: "Harald T. Alvestrand" <hta at uninett.no>
Date: Wed, 11 Jan 95 19:42:31 JST
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <3f09e7$kn3 at trane.uninett.no>; from "Harald T. Alvestrand" at Jan 11, 95 9:46 am
X-Mailer: ELM [version 2.3 PL11]
> The draft unfortunately shows the result of lack of MIME support at the
> IETF secretariat.
Wrong. Even if IETF secretariat support MIME, it does not mean
that local (to the secretariat) representation of ISO-8859-1 message
is the direct CTE decoding of the MIME content. Local representation
may be anything including EBCDIC.
Moreover, as FTP ASCII mode does not support 8bit ISO 8859/1, your 8
bit draft can't be placed in ftp archive unless you have assumed UNIX
binary.
So, the Internet Draft secretariate have had done the best possible
thing.
> But the point is moot, since the RFC Editor insists on marking up the
> source from scratch on all RFCs.
RFCs MUST be ftp'able.
> And yes, the draft DOES need ISO 8859-1 characters if the examples
> of non-English text are to be properly represented.
Not at all. It's easy to extract MIME's capability to avoid ISO
8859/1 characters to represent ISO 8859/1 characters.
You can change the following current example:
Content-Language: de
Content-Type: text/plain; charset=3Diso-8859-1
Content-Transfer-encoding: 8bit
Der schnelle braune Fuchs h=FCpft =FCber den faulen Hund
to
Content-Language: de
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-encoding: quoted-printable
Der schnelle braune Fuchs h=FCpft =FCber den faulen Hund
That's all.
The other place you used ISO-8859-1:
ISO 3166 Maintenance Agency Secretariat
c/o DIN Deutches Institut F=FCr Normung
can painlessly be:
ISO 3166 Maintenance Agency Secretariat
c/o DIN Deutches Institut Fur Normung
Masataka Ohta
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07531;
11 Jan 95 14:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13411;
11 Jan 95 14:37 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07469;
11 Jan 95 14:37 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07290;
11 Jan 95 14:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iplpdn at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iplpdn-frmib-dte-03.txt
Date: Wed, 11 Jan 95 14:27:02 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501111427.aa07290 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Over Large Public Data
Networks Working Group of the IETF.
Title : Management Information Base for Frame Relay DTEs
Author(s) : C. Brown, C. Carvalho, F. Baker
Filename : draft-ietf-iplpdn-frmib-dte-03.txt
Pages : 32
Date : 01/10/1995
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing Frame Relay.
This memo does not specify a standard for the Internet community.
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-iplpdn-frmib-dte-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-iplpdn-frmib-dte-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-iplpdn-frmib-dte-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950110140521.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-iplpdn-frmib-dte-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iplpdn-frmib-dte-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950110140521.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07554;
11 Jan 95 14:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13393;
11 Jan 95 14:37 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07473;
11 Jan 95 14:37 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07289;
11 Jan 95 14:27 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mobile-ip at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mobileip-protocol-08.txt
Date: Wed, 11 Jan 95 14:26:59 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501111427.aa07289 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Routing for
Wireless/Mobile Hosts Working Group of the IETF.
Title : IP Mobility Support
Author(s) : C. Perkins
Filename : draft-ietf-mobileip-protocol-08.txt
Pages : 43
Date : 01/10/1995
This document specifies protocol enhancements that allow transparent
routing of IP datagrams to mobile nodes in the Internet. Each mobile node
is always identified by its home address, regardless of its current point
of attachment to the Internet. While situated away from its home, a mobile
node is also associated with a care-of address, which provides information
about its current point of attachment to the Internet. The protocol
provides for registering the care-of address with a home agent. The home
agent sends traffic destined for the mobile node through a tunnel to the
care-of address.
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-mobileip-protocol-08.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-protocol-08.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mobileip-protocol-08.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 cnri.reston.va.us.
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: <19950110133712.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mobileip-protocol-08.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mobileip-protocol-08.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950110133712.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08963;
11 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15013;
11 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08933;
11 Jan 95 15:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08815;
11 Jan 95 15:31 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa14910;
11 Jan 95 15:31 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA01740>; Wed, 11 Jan 1995 12:31:58 -0800
Message-Id: <199501112031.AA01740 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1747 on SNADLC SDLC MIB using SMIv2
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 11 Jan 95 12:33:00 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1747:
Title: Definitions of Managed Objects for SNA Data Link
Control (SDLC) using SMIv2
Author: J. Hilgeman, Chair, S. Nix, A. Bartky,
& W. Clark, Editor
Date: January 1995
Mailbox: jeffh at apertus.com, snix at metaplex.com,
alan at sync.com, wclark at cisco.com
Pages: 67
Characters: 147,388
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1747.txt
This specification defines an extension to the Management Information
Base (MIB) for use with SNMP-based network management. In particular,
it defines objects for managing the configuration, monitoring and
control of data link controls in an SNA environment. This RFC
identifies managed objects for SNA Synchronous Data Link Control
(SDLC) links only. This RFC is a product of the SNA DLC Services MIB
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-REQUEST at NIC.DDN.MIL.
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: <950111122848.RFC at ISI.EDU>
SEND /rfc/rfc1747.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1747.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950111122848.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10409;
11 Jan 95 16:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16960;
11 Jan 95 16:48 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10355;
11 Jan 95 16:48 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10180;
11 Jan 95 16:42 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dns-security at tis.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-dnssec-as-map-01.txt
Date: Wed, 11 Jan 95 16:42:43 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501111642.aa10180 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS Security Working Group of
the IETF.
Title : Mapping Autonomous Systems Number into
the Domain Name System
Author(s) : D. Eastlake
Filename : draft-ietf-dnssec-as-map-01.txt
Pages : 7
Date : 01/10/1995
One requirement of secure routing is that independent routing entities,
such as those identified by Internet Autonomous System Numbers, be able to
authenticate messages to each other. Modifications currently being
developed (see other draft-ietf-dnssec-*.txt) to the Domain Name System
will enable it to be used for convenient public key distribution. This
draft maps all Autonomous System numbers into DNS Domain Names so that the
DNS can be used to distribute their public keys.
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-dnssec-as-map-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-dnssec-as-map-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 cnri.reston.va.us.
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: <19950111122236.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnssec-as-map-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnssec-as-map-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950111122236.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10895;
11 Jan 95 17:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10888;
11 Jan 95 17:04 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17791;
11 Jan 95 17:04 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10857;
11 Jan 95 17:04 EST
Received: from saab.erg.sri.com by IETF.CNRI.Reston.VA.US id aa10784;
11 Jan 95 17:02 EST
Received: from localhost.erg.sri.com by saab.erg.sri.com (5.65/2.7davy)
id AA03845; Wed, 11 Jan 95 14:03:26 -0800
Message-Id: <9501112203.AA03845 at saab.erg.sri.com>
To: ietf at IETF.CNRI.Reston.VA.US
Cc: denny at erg.sri.com
Subject: Call for Papers - IC3N'95
Date: Wed, 11 Jan 95 14:03:24 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: denny at erg.sri.com
IC3N'95 PRELIMINARY CALL FOR PAPERS
FOURTH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS
September 20 -- 23, 1995, Las Vegas, Nevada, USA
Sponsored by USC Communication Sciences Institute, SRI International, and
Datatech
In cooperation with NASA, NSF, NIST~, IEEE Computer Society, ACM~, and
IEEE Communication Society~ (~ Pending approval)
Steering Committee
- -------------------
V. Li (chair), USC The objective of this conference is to provide
T. Suda, UC Irvine an effective forum for original and fundamental
J.W. Wong, U. Waterlo advances in Computer Communications and Networks and
S. S. Lam, UT. Austin to foster communication among researchers and
J.S. Meditch, U. Washing practioners working in a wide variety of scientific
R. Pickholtz, GWU areas with a common interest in improving
K. Makki, UNLV Computer Communications and Networks. Therefore
B. Ip, Siem. AG, Germany
J.F. Chang, NCU, Taiwan SCOPE
B.G. Lee, SNU, Korea The primary focus of the conference is on new and
original research results in the areas of design,
implementation and applications of Computer
Communications and Networks. We solicit the
submission of papers that address novel, challenging
and innovative results. Therefore, the topics that
will be addressed include, but are not limited to:
o ATM Networking
Conference Chair
- ----------------- o Distributed Multimedia Applications
E.K. Park, Naval Academy
o Quality of Services (QoS) Issues
Program Chair
- -------------- o Interoperability
K. Makki, UNLV
o Network Management
Program Co-Chair o Intelligent Networks
- -----------------
N. Pissinou, CACS/USL o Network Security
Program Vice Chairs o Reliable Networks
- --------------------
O. Frieder, GMU o Video-on-Demand
I. Khan, SRI Int.
W. Liu, BellSouth A. o Multimedia Human-Machine Interface
European Coordinators
- ---------------------- o Internet Services/Applications
C. Fayet, INT, France
A. Gaivoronski, ITA, Italy o Real Time Communications
U. Krieger, DBP, Germany
o LAN/WAN internetworking
Program Committee
- ------------------ o Personal Communication Services
M.H. Ammar, Georgia Tech
S.K. Das, U. of N. Texas o Wireless networks
T.-Y. Feng, NSF/Penn State
D. Fernadez-Beca, Iowa St. o Multicast Protocols
F. Golshani, Arizona St. U.
M. Gouda, UT Austin o Optical Networks
M. Halem, NASA
O. Ibera, UC Santa Barbara o High Speed Network OAM/Protocols
X. Jia, U. Queensland
D. Kazakos, USL o Traffic Management
J. Kim, Bellcore
S. S. Lam, UT. Austin o Performance Modeling/Analysis
Y. Lee, U. Florida
D. Lee, AT&T Bell Lab
V. Li, USC SUBMISSION
M.T. Liu, Ohio State U.
J.S. Meditch, U. Washing Authors are invited to submit complete and original
M. Mizuno, Kansas State U. papers. Papers that may be submitted for considera-
R. Miller, U. Maryland tion include those that have not previously been
W.M. Moh, San Jose S. U. published in another forum, or are not currently
T. Nakassis, NIST being published or reviewed by another journal or
M.T. Ozsu, Univ. of Alberta conference. All submitted papers will be refereed
M. Papazouglou, Queensl. U. for quality, correctness, originality and relevance
W. Peng, S. Texas St. U. The program committee reserves the right to accept
K. Qiu, Acadia U. Canada a submission as long, short or poster presentation.
S. Sahni, U. Florida Of particular interest are papers which address
H. Saito, NTT, Japan experiences with concrete Computer Communications
M. Segal, Ballcore and applications. All accepted papers will be
H. Shi, AT&T published in the conference proceedings. Authors
S.Y. Shin, S.Dakoda St.U. will be interested to know that special issues of
A. Silberschatz, AT&T Bell journals containing outstanding papers from the
M. Singhal, Ohio State U. conference are being planned.
T. Suda, UC Irvine
J. Tsai, UIC
D.H.K. Tsang, Hong Kong
Others
Publicity Chair Registration Chair
- --------------- ------------------
M. Mizuno, Kansas State U. S. Busovaca, Cal. State Univ. Sac.
Local Arrang. Chairs: B. Nassersharif, NSCEE and E. Salehi, UNLV
- ---------------------
Manuscripts should include an abstract and be limited to 5000 words. Submissions
should include the title, author(s), author's affiliation, e-mail address, fax
number and postal address. In case of multiple authors , an indication of which
author is responsible for correspondence and preparing the camera ready paper
for the proceedings should also be included.
SIX copies of the manuscript should be submitted by FRIDAY, MARCH 17, 1995 to
Dr. Kia Makki, the Program Chair:
Professor Kia Makki
c/o Ms Chris Nienaber
National Supercomputing Center
For Energy and the Environment
4505 Maryland Parkway
Box 454028
Las Vegas, Nevada 89154-4028, USA
(kia at unlv.edu)
Tel: (702) 895-4024. Fax:(702) 895-4156
For more information about the conference (as opposed to paper submissions)
please send e-mail to ic3n at cacs.usl.edu.
IMPORTANT DATES:
----------------
Paper submission deadline : March 17, 1995
Notification of acceptance: May 30, 1995
Camera ready papers due : June 26, 1995
Workshops and Tutorials:
- ------------------------
Proposals are solicited for organizing workshops and tutorials.
Please send your proposal by March 17, 1995 to Professor Niki Pissinou,
the Program Co-Chair, The Center for Advanced Computer Studies, The
University of Southwestern Louisiana, Lafayette, LA 70504, USA
(pissinou at cacs.usl.edu, Tel: (318) 482-6604, Fax: (318) 482-5791).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04955;
12 Jan 95 13:51 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa04949;
12 Jan 95 13:51 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11794;
12 Jan 95 13:51 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04897;
12 Jan 95 13:51 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa04668;
12 Jan 95 13:29 EST
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa11275;
12 Jan 95 13:29 EST
Received: from survival.surfnet.nl by survis.surfnet.nl with SMTP (PP);
Thu, 12 Jan 1995 19:29:53 +0100
To: ietf at CNRI.Reston.VA.US
Subject: Stepping down
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903
Date: Thu, 12 Jan 1995 19:29:50 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Erik Huizer (SURFnet BV)" <Erik.Huizer at surfnet.nl>
Message-ID: <9501121329.aa11275 at CNRI.Reston.VA.US>
I am sorry to have to use this impersonal way of getting this message
across, but the ietf is just getting to big for personal mails.
I have recently been given a new task within SURFnet, a task that involves
building a business unit from scratch. Experience shows that such a task
does not combine well with an IESG membership. So, although my term is not
over for another year, I have decided to step down as an IESG member and
applications area co-director. I will step down at the end of the upcoming
IETF in Danvers, at the same time as the new IESG members will take their
place. I have already informed the nominations committee on my decision.
I will remain active in the IETF, and will probably attend meetings, so this
certainly is not a 'goodbye'. However I want to take the opportunity to
thank all the people who edited documents or otherwise participated in
working groups in my area. I have enjoyed the incredible enthusiasm and
energy that gets devoted on a virtually volunteer basis into the IETF
activities. I have lots of friends (and unavoidably if you are on the IESG:
enemies), and I have learned a lot from my time on the IESG.
I want to specifically thank the WG chairs that I worked with and the
memebers of the application area directorate, without the none of the work
would have been done.
Finally I want to thank all the IESG members that I have worked with in
these three years. It has been fun (really! :-). Especially Dave Piscitello
Russ Hobby and John Klensin, my buddies who did most of the work, and let me
take the credit.
I hope to see all of you in Danvers, and until the end of that meeting my
WGs are stuck with me.
Thanks,
Erik
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05943;
12 Jan 95 14:59 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa05936;
12 Jan 95 14:59 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13188;
12 Jan 95 14:58 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05912;
12 Jan 95 14:58 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa05824;
12 Jan 95 14:54 EST
Received: from oit.gatech.edu by CNRI.Reston.VA.US id aa13095;
12 Jan 95 14:54 EST
Received: (from ccoprmm at localhost) by oit.gatech.edu (8.6.9/8.6.9) id OAA25052 for ietf at cnri.reston.va.us; Thu, 12 Jan 1995 14:54:28 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Michael Mealling <Michael.Mealling at oit.gatech.edu>
Message-Id: <199501121954.OAA25052 at oit.gatech.edu>
Subject: Xserver used w/Liveboard in San Jose?
To: ietf at CNRI.Reston.VA.US
Date: Thu, 12 Jan 1995 14:54:28 -0500 (EST)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 438
I'm going to be using a Liveboard with some mbone tools and I'd like
to find out which PC Xserver was used in San Jose and if there were
any large snags to watch out for. Any info will be greatly appreciated!
-MM
--
------------------------------------------------------------------------------
<HR><A HREF="http://www.gatech.edu/michael.html";>
<ADDRESS>Michael Mealling</ADDRESS>
<ADDRESS>michael.mealling at oit.gatech.edu</ADDRESS></A>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06119;
12 Jan 95 15:05 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa06111;
12 Jan 95 15:05 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13391;
12 Jan 95 15:05 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06092;
12 Jan 95 15:05 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa06021;
12 Jan 95 15:02 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13261;
12 Jan 95 15:01 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA13627>; Thu, 12 Jan 1995 11:59:50 -0800
Message-Id: <199501121959.AA13627 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: ietf at CNRI.Reston.VA.US
Subject: Internet Monthly Report - December 1994
Reply-To: cooper at isi.edu
Date: Thu, 12 Jan 95 11:59:49 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
December 1994
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.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
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:
Ann Westine Cooper (Cooper at ISI.EDU)
NSF Regional reports - To obtain the procedure describing how to
submit information for the Internet Monthly Report, send an email
message to mailserv at is.internic.net and put "send imr-procedure" in
the body of the message (add only that one line; do not put a
signature).
Requests to be added or deleted from the Internet Monthly report list
should be sent to "imr-request at isi.edu".
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
Cooper [Page 1]
Internet Monthly Report December 1994
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
ANSNET/NSFNET BACKBONE ENGINEERING . . . . . . . . . . . page 7
DANTE . . . . . . . . . . . . . . . . . . . . . . . . . . page 7
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 10
ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 15
MERIT/NSFNET ENGINEERING. . . . . . . . . . . . . . . . . page 27
MIDNET. . . . . . . . . . . . . . . . . . . . . . . . . . page 29
NORTHWESTNET . . . . . . . . . . . . . . . . . . . . . . page 30
PREPnet . . . . . . . . . . . . . . . . . . . . . . . . . page 34
SPRINT NAP PI . . . . . . . . . . . . . . . . . . . . . . page 35
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 36
USER SERVICES REPORT . . . . . . . . . . . . . . . . . . page 37
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 49
TERENA CALENDAR. . . . . . . . . . . . . . . . . . . . . . page 53
Cooper [Page 2]
Internet Monthly Report December 1994
INTERNET RESEARCH REPORTS
-------------------------
INTERNET ENGINEERING REPORTS
----------------------------
1. The IETF met for the third time this year in San Jose,
California. This meetings was hosted by Sun Microsystems, with
network connectivity being supplied by Barrnet. Though the
numbers are still unofficial, this meeting was the largest by
far with over 1,000 attendees.
The IETF meetings for 1995 are starting to firm up. The IETF
will be meeting in Danvers, Massachusetts (a suburb of Boston)
from April 3-7, 1995. The summer IETF meeting will be held in
Stockholm, Sweden the week of July 17-21, 1995. Due to the
meeting costs, the IETF attendance fee for the Stockholm meeting
will be US$300.
The final meeting for 1995 will be held in Dallas, Texas. 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
2. 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:
November 17, 1994 (iesg.94-11-17)
3. The IESG approved or recommended the following two Protocol
Actions during the month of December, 1994:
o IEEE 802.5 Station Source Routing MIB be published as a
Proposed Standard.
o Definitions of Managed Objects for SNA Data Link Control:
SDLC be published as a Proposed Standard.
Cooper [Page 3]
Internet Monthly Report December 1994
4. The IESG issued four Last Calls to the IETF during the month of
December, 1994:
o Remote Network Monitoring Management Information Base
<draft-ietf-rmonmib-rmonmib-03> for consideration as a Draft
Standard.
o Printer MIB <draft-ietf-printmib-printer-mib-04> for
consideration as a Proposed Standard.
o ATM Signaling Support for IP over ATM
<draft-ietf-ipatm-sig-02> for consideration as a Proposed
Standard.
o Routing Information Protocol <RFC1058> be reclassified as
Historic.
5. One Working Group was created during this period:
New Generation Transition (ngtrans)
and one was concluded:
Interfaces MIB (ifmib)
6. A total of 29 Internet-Draft actions were taken during the month
of December, 1994:
(Revised draft (o), New Draft (+) )
(mhsds) o MHS use of the X.500 Directory to support MHS
Routing <draft-ietf-mhsds-routdirectory-06.txt, .ps>
(rolc) o NBMA Next Hop Resolution Protocol (NHRP)
<draft-ietf-rolc-nhrp-03.txt>
(none) + MIME Encapsulation of EDI Objects
<draft-ietf-edi-mime-00.txt, .ps>
(mailext) o Tags for the identification of languages
<draft-ietf-mailext-lang-tag-01.txt>
(none) o Definitions of Managed Objects for the Fabric
Element in Fibre Channel Standard
<draft-chu-fabric-mib-02.txt>
(pppext) o PPP Magnalink Variable Resource Compression
<draft-ietf-pppext-magnalink-01.txt>
(nasreq) o Remote Authentication Dial In User Service (RADIUS)
<draft-ietf-nasreq-radius-02.txt>
(none) o TCP Embedded Trailer Checksum
<draft-bridges-tcp-checksum-01.txt>
(printmib) o Printer MIB <draft-ietf-printmib-printer-mib-04.txt>
(uri) o Functional Requirements for Internet Resource
Cooper [Page 4]
Internet Monthly Report December 1994
Locators <draft-ietf-uri-irl-fun-req-02.txt>
(pppext) o The PPP Banyan Vines Control Protocol (BVCP)
<draft-ietf-pppext-vines-02.txt>
(tftpexts) o TFTP Option Extension
<draft-ietf-tftpexts-option-ext-02.txt>
(ifmib) o IEEE 802.5 Station Source Routing MIB
<draft-ietf-ifmib-ssr-mib-02.txt>
(html) o Form-based File Upload in HTML
<draft-ietf-html-fileupload-01.txt>
(pppext) o The PPP Encryption Control Protocol (ECP)
<draft-ietf-pppext-encryption-01.txt>
(none) o Hypertext Transfer Protocol -- HTTP/1.0
<draft-fielding-http-spec-01.txt, .ps>
(dnsind) + Notify: a mechanism for prompt notification of
authority zone changes
<draft-ietf-dnsind-notify-00.txt>
(bgp) + Application of the Border Gateway Protocol in the
Internet <draft-ietf-bgp-app-00.txt>
(none) + Extended IS-IS: Metric Feeding
<draft-reijnierse-topology-00.txt>
(none) + The Secure HyperText Transfer Protocol
<draft-rescorla-shttp-00.txt>
(whip) o Requirements for an Internet White Pages Service
<draft-ietf-whip-reqs-summary-01.txt>
(tftpexts) + TFTP Timeout Interval and Transfer Size Options
<draft-ietf-tftpexts-options-00.txt>
(none) + PGP Message Exchange Formats
<draft-pgp-pgpformat-00.txt>
(idr) + A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-00.txt>
(none) + Report on MD5 Performance
<draft-touch-md5-performance-00.txt>
(tftpexts) + TFTP Option Negotiation Analysis
<draft-ietf-tftpexts-analysis-00.txt>
(iab) + Guidance in the Assignment of Internet Numbers
<draft-iab-assignment-guidance-00.txt>
(none) + Not All RFCs are Standards
<draft-iab-rfc-not-std-00.txt>
(none) + A Proposed Extension Mechanism for HTTP
<draft-kristol-http-extensions-00.txt, .ps>
7. There were 25 RFC's published during the month of December,
1994:
RFC St WG Title
------- -- -------- -------------------------------------
RFC1709 I (isn) K-12 Internetworking Guidelines
RFC1714 I (none) Referral Whois Protocol (RWhois)
Cooper [Page 5]
Internet Monthly Report December 1994
RFC1719 I (none) A Direction for IPng
RFC1726 I (none) Technical Criteria for Choosing IP:The
Next Generation (IPng)
RFC1727 I (iiir) A Vision of an Integrated Internet
Information Service
RFC1728 I (iiir) Resource Transponders
RFC1729 I (iiir) Using the Z39.50 Information Retrieval
Protocol in the Internet Environment
RFC1730 PS (imap) INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4
RFC1731 PS (imap) IMAP4 Authentication mechanisms
RFC1732 I (imap) IMAP4 COMPATIBILITY WITH IMAP2 AND
IMAP2BIS
RFC1733 I (imap) DISTRIBUTED ELECTRONIC MAIL MODELS IN
IMAP4
RFC1734 PS (none) POP3 AUTHentication command
RFC1735 E (rolc) NBMA Address Resolution Protocol (NARP)
RFC1737 I (uri) Functional Requirements for Uniform
Resource Names
RFC1738 PS (uri) Uniform Resource Locators (URL)
RFC1739 I (none) A Primer On Internet and TCP/IP Tools
RFC1740 PS (none) MIME Encapsulation of Macintosh files -
MacMIME
RFC1741 I (none) MIME Content Type for BinHex Encoded
Files
RFC1743 DS (ifmib) IEEE 802.5 MIB using SMIv2
RFC1744 I (none) Observations on the Management of the
Internet Address Space
RFC1745 PS (idr) BGP4/IDRP for IP---OSPF Interaction
RFC1748 DS (ifmib) IEEE 802.5 MIB using SMIv2
RFC1749 S (ifmib) IEEE 802.5 Station Source Routing MIB
using SMIv2
RFC1750 I (none) Randomness Recommendations for Security
RFC1751 I (none) A Convention for Human-Readable 128-bit
Keys
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( E) Experimental
( I) Informational
Steve Coya <scoya at cnri.reston.va.us>
Cooper [Page 6]
Internet Monthly Report December 1994
INTERNET PROJECTS
-----------------
ANSNET/NSFNET BACKBONE ENGINEERING
----------------------------------
Network Status Summary
=======================
ANSnet total packet traffic decreased by about 11.82% in December
'94. An increase in the ANSnet forwarding table size of 3.82% was
observed during the month December.
August Backbone Traffic Statistics
==================================
The total inbound packet count for the ANSnet (measured using SNMP
interface counters) was 78,393,599,694 on T3 ENSS interfaces, down
12.91% from November. The total packet count into the network
including all ENSS serial interfaces was 89,000,109,937 down 11.82%
from November.
Router Forwarding Table Statistics
================================
The maximum number of destinations announced to ANSnet during
December was 20,252 up 3.82% from November.
The number of network destinations configured for announcement to
the ANSnet but never announced (silent nets) during December was
21,251.
Jordan Becker <becker at ans.net>
DANTE
-----
_________________________________________________________________
* * A bi-monthly electronic news bulletin
* * reporting on the activities of DANTE,
* the company that provides international
* network services for the European
THE WORKS OF D A N T E research community.
No.7, January 1995 Editor: Josefien Bersee
__________________________________________________________________
Cooper [Page 7]
Internet Monthly Report December 1994
EUROPANET GROWTH IN 1994
EuropaNET, DANTE's international network for the European research
networks, grew fast in 1994. In total the traffic load on the network
more than quadrupled. The total EuropaNET backbone access point
capacity is currently 24 Mbps, with each access point connected to at
least two trunk lines (the total trunk capacity of EuropaNET is
30 Mbps). An overview of total traffic growth and traffic growth of
the ten 'largest' access ports can be obtained from URLs:
http://www.dante.net/traffic.GIF and http://www.dante.net/top-10.GIF.
EUROCAIRN STUDY SUBMITTED
In view of its current customer base and pan-European backbone
management experience, DANTE is in an excellent position to be at
the forefront of the development of the next generation research
backbone in Europe. The Eureka EuroCAIRN project, set up to
improve network facilities for European researchers, contracted
DANTE in June 1994 to prepare a plan for the immediate procurement
of a high speed network for research in Europe.
The draft Final Report of the EuroCAIRN study was submitted to the
EuroCAIRN Committee on December 24th 1994 and they will consider it
at their next meeting on 20 January 1995. The study details the high
speed networking requirements of the European research network
organisations, presents a technical and commercial options
analysis as well as a detailed plan for the immediate deployment
of a 34 Mbps pan-European network for research.
Earlier, on 8 November 1994, DANTE had organised a meeting in
Brussels with representatives of the national research networks to
receive their feedback on the preliminary findings of the study.
During the meeting several attendees stressed again the urgency of
setting up the new high speed infrastructure as soon as possible.
TRANSATLANTIC CONNECTIVITY INCREASING
The first circuits as part of the plans to upgrade EuropaNET
connectivity from Europe to the US have been acquired. A new T1
(1.5 Mbps) line between Amsterdam and New York became operational
in December 1994. This brings the total capacity of EuropaNET's US
connectivity to 5 Mbps. The order for the second T1 link from
Amsterdam has been placed and the link is expected to be in place
by February.
At the request of SURFnet and DFN, DANTE will manage a direct link
between Germany and the Netherlands. One use of this additional
capacity will be for traffic between the Dutch and the German
Cooper [Page 8]
Internet Monthly Report December 1994
Aviation and Space Research institutes. For this purpose DANTE
will set up a Point of Presence (PoP) in Aachen, Germany. In addition
DFN has decided to obtain additional intercontinental connectivity
from DANTE which can be delivered via Amsterdam and this new
German-Dutch link. A further T1 circuit will be ordered to provide
the extra capacity needed. To improve the US service for other
EuropaNET subscribers ways of upgrading the capacity of the DANTE
gateway in Amsterdam (which provides them with US access) are being
discussed with Unisource.
DANTE has started work under a contract with the European
Commission to set up a connection between EuropaNET and Canada.
The first phase of the work will be to assess what sort of
capacity is needed and how it can best be organised. A
recommendation will follow on which the actual implementation plan
will be based.
DANTE SECURITY SERVICE
At the request of a number of national networks, DANTE will create a
European level CERT (Computer Emergency Response Team) service. DANTE
is currently working on a detailed service specification which will
be published shortly. The objectives of the CERT service will be: the
coordination of incident handling between member CERTs and with other
incident response teams worldwide; the coordination of technical
assistance to member CERTs; the maintenance of an information server
on operational aspects of computer security; assistance for the
establishment of new CERTs and the provision of backup and support to
resolve problems that cannot be handled by a member CERT.
The DANTE CERT service will build on the expertise and experience
of the national CERTs that are already in place. The DANTE CERT will
participate fully in existing international bodies dealing with
incident response and security. Full membership of FIRST (Forum on
Incident Response and Security Teams) will be applied for. As is
DANTE's normal practice, many of the operational components of the
DANTE CERT activity will be sub-contracted; discussions on how best
to do this are already taking place with organisations which are
interested in carrying out this task.
CESSATION OF DISCUS
DISCUS, the continuation of the CONCISE central European
information service for the research community, was funded by the
European Commission during 1994. In the knowledge that this
funding would come to an end on 31 December 1994 DANTE and Level-7,
the service operator, have looked into several options to continue
the service on a self-sustaining basis. The concept of a locally
Cooper [Page 9]
Internet Monthly Report December 1994
maintained information service such as DISCUS has, to a great
extent, been overtaken by distributed services such as the WWW and
Gopher. It has not proved possible to find a sufficiently large
customer base to continue the service on a commercial basis.
Therefore DISCUS will cease to exist in its current form by 31
January 1995. By courtesy of FUNET (Finnish research network) the
current information will remain accessible for at least six months at
URL: ftp://ftp.funet.fi/index/DISCUS. DANTE is considering the
possibility of continuing some elements of the service if required.
NEW EUROPANET POSTER AVAILABLE
An updated version of the EuropaNET topology poster is available
on request. The new version gives a slightly more streamlined
overview of the network topology. To receive a copy of the poster
send <send poster> in a message to dante at dante.org.uk (please
include your surface mail address).
_________________________________________________________________
DANTE - Lockton House - Clarendon Road - Cambridge - CB2 2BH - UK
telephone +44 1223 302992
fax +44 1223 303005
E-mail dante at dante.org.uk
S=dante; O=dante; P=dante; A=mailnet; C=fi
WWW server http://www.dante.net/
Gopher server gopher://gopher.dante.net/
Anonymous ftp ftp://ftp.dante.net/pub/
INTERNIC
--------
INFORMATION SERVICES
Contact Information:
Reference Desk Information
Phone +1 619 455-4600
email info at internic.net
Fax +1 619 455-4640
InterNIC Suggestions or Complaints
Suggestions suggestions at internic.net
Complaints complaints at internic.net
Cooper [Page 10]
Internet Monthly Report December 1994
NSF Network News
newsletter subscriptions newsletter-request at internic.net
newsletter comments newsletter-comments at internic.net
NICLink
General Information info at internic.net
Problems/bugs niclink-bugs at is.internic.net
InterNIC Seminar Series
General Information seminars at internic.net
Listserv lists
net-happenings majordomo at is.internic.net
net-resources majordomo at is.internic.net
scout-report majordomo at is.internic.net
InfoGuide
Host Name is.internic.net
Host Address 192.153.156.15
URL: http://www.internic.net/
Postal address
InterNIC Information Services
General Atomics
P.O. BOX 85608
San Diego, CA 92186-9784
THE InterNIC INFOGUIDE
The InterNIC InfoGuide is a comprehensive online information
service which provides information about the Internet and online
Internet resources. Accessible through gopher and the WorldWideWeb,
the InterNIC InfoGuide replaces the older InterNIC information
server, the InfoSource. The InfoGuide includes new services such as
the Scout Report and an online hypertext version of the _NSF
Network News_.
To access the InterNIC InfoGuide, point your WorldWideWeb client
to: http://www.internic.net/infoguide.html
or your gopher client to: is.internic.net
NET-HAPPENINGS
The net-happenings list is a service of InterNIC Information
Services and the list moderator, Gleason Sackman of North Dakota's
SENDIT Network. The purpose of the list is to distribute to the
community announcements of interest to network staffers and end
Cooper [Page 11]
Internet Monthly Report December 1994
users. This includes conference announcements, call for papers,
publications, newsletters, network tools updates, and network
resources. Net-happenings is a moderated, announcements-only
mailing list which gathers announcements from many Internet sources
and concentrates them onto one list.
To access net-happenings, point your gopher client to:
is.internic.net
and search the InterNIC InfoGuide for Net-Happenings.
THE SCOUT REPORT:
A Weekly Summary of Internet Highlights
At last count the Scout Report was reaching over 18,000 subscribers
and the HTML versions on the InfoGuide are still receiving
thousands of accesses each week. A new and improved version of the
Scout Report will debut next month.
The Scout Report is a weekly publication offered to the Internet
community as a fast, convenient way to stay informed on network
activities. Its purpose is to combine in one place the highlights
of new resource announcements and other news which occurred on the
Internet during the previous week.
The Scout Report is released every Friday in multiple formats --
electronic mail, gopher, and WorldWideWeb. WorldWideWeb versions
of the Report include links to all listed resources allowing
instantaneous browsing of items of interest. Comments and
contributions to the Scout Report are encouraged and can be sent to
scout at internic.net.
How to Get the Scout Report
To receive the electronic mail version of the Scout Report each
Friday, join the scout-report mailing list. This mailing list will
be used only to distribute the Scout Report once a week. Send mail
to:
majordomo at is.internic.net
In the body of the message, type: subscribe scout-report
youremailaddress
To access the hypertext version of the Report, point your WWW
client to:
http://www.internic.net/infoguide.html
Cooper [Page 12]
Internet Monthly Report December 1994
Gopher users can tunnel to: is.internic.net/Information Services
THE InterNIC SEMINAR SERIES
"Learning the Whole Internet" is now available for users needing
Internet training. The InterNIC has already presented a beta
version of the course which includeded a copy of _The Whole
Internet_ as well as class handouts of the PowerPoint presentation.
NSF NETWORK NEWS
The _NSF Network News_ Vol. 1, No. 5 is in the works. This
newsletter will spotlight legal issues presently revolving around
the Internet. Projected highlights are: the future of domain
registration; a seminar spotlight; and the regular features of the
_NSF Network News_ such as the InterNIC Event Calendar and news
briefs. To subscribe, send email to newsletter-
request at internic.net.
The September/October issue of the _NSF Network News_ is available
on the WorldWideWeb at
http://www.internic.net/newsletter/sep-oct94/index.html
The newsletter is also available via gopher to the InterNIC
InfoGuide at is.internic.net and mailserv to
mailserv at is.internic.net with the following text in the body of the
message: get /about-internic/newsletter/nsfnews-aug94.txt
REFERENCE DESK
The following table gives a summary of Reference Desk contacts for
December:
Method Contacts % of Total
------- -------- ---------
Email 516 47
Phone 166 15
Fax 338 31
US Mail 25 2
Referral 49 5
------- -------- ---------
Total 1094 100.0
by Anna Knittle <aknittle at is.internic.net>
Cooper [Page 13]
Internet Monthly Report December 1994
INTERNIC DIRECTORY AND DATABASE SERVICES
In December, we upgraded the X.500 server on ds0.internic.net to the
ISODE Consortium's version 2.1. This version should appear the same to
users in terms of user interface and features supported, but it is
faster than the system we had been using, and should also be more
reliable.
We run two X.500 DSA's, one on ds0.internic.net and the other on
ds2.internic.net. They back each other up; in case of failure or
maintenance on one, X.500 clients will automatically go to the other.
The server on ds2.internic.net will be upgraded to the new release in
January.
X.500 provides a "Directory Information Tree", or DIT, that supports
organizations all over the world. Any server that is part of the tree
can help you get information from any part of the tree, so users of our
system can get listings from organizations in Europe, Austrailia, and
Japan (as well as North America).
To access the X.500 directory from our servers, log in as "x500" and
follow the instructions, or log in as "guest" and select option 3 and
then option 2.
While there are over 1 million entries in the global DIT, there are many
organizations that do not have X.500 directories. One of our most
frequently asked questions is why someone who works for a well known
company or university cannot be found in X.500. Most often, it is
becuase that organization does not have an X.500 directory that is part
of the DIT.
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.
by Rick Huber <rvh at ds.internic.net>
INTERNIC REGISTRATION SERVICES
I. Significant Events
InterNIC Registration Services assigned over 5,911 network addresses
and registered over 3,681 domains.
II. Current Status
During the month of December 1994, InterNIC Registration Services
Cooper [Page 14]
Internet Monthly Report December 1994
received communications as shown below. The majority of the
correspondence concerned the assignment and re-assignment of network
numbers and the registration or change of domain names.
E-mail 8,671 (hostmaster at internic.net)
Postal/Fax 226 (primarily IP number requests)
Phone 1,859
The Registrations Services host computer supported a large volume of
information retrieval requests during the month of December.
Connections Retrievals
Gopher 66,555 45,449
WAIS 95,286 74,796
FTP 11,935 54,477
Mailserv 5,117
Telnet 60,259
In addition, for WHOIS the number of queries were:
Client Server
270,079 998,238
Debbie Fuller (debbief at internic.net)
ISI
---
NETSTATION
==========
Those of us working on the Netstation project at USC/ISI have been
wrestling with the issues that arise when interfacing devices via a
gigabit network rather than a system bus. Rearchitecting a
workstation around a network raises many interesting research
issues and an abundance of implementation choices. These monthly
reports are intended to keep the research community informed of
current project directions and implementation/design choices.
Recent efforts have focused on clarifying and documenting the
fundamental architectural choices, e.g. the concepts of network
devices, service and device interfaces, and the required naming and
binding schemes.
Network Devices and Service Interfaces
We call a "device" that is controlled via network protocols a
network virtual device (NVD) to emphasize that the interface that
Cooper [Page 15]
Internet Monthly Report December 1994
is exported by the NVD may be a synthetic one. The process that
controls an NVD, its Owner, uses the exported interface to control
it.
The exported interface is generically a "service interface", which
may provide access to an actual physical device or to a higher-
level abstraction; the more specific term "device interface" is
used to refer to lower-level "raw" abstractions. However, details
specific to the control of a particular hardware device inside an
NVD can be hidden when that does not interfere with the functional
use of the NVD. Many of these, such as register addresses, control
bit assignments, and timing restrictions can often be completely
managed internally by the NVD.
At one extreme an NVD may be entirely virtual, consisting of a
disembodied process that is not physically associated with any
peripheral devices. For example, a large wall-size display device
may export a "raw" full-screen interface. This interface, in turn,
may be "owned" by some process (on another machine) which will
subdivide the display surface to provide several workstation-size
display devices. Such an NVD may be thought of as exporting a
network service rather than a device interface, but since the
access mechanisms for NVDs in all cases are based upon network
protocols, that distinction is a fine one.
Tentatively, the line that is drawn between a Netstation device and
a network server process is the means of communication.
Interactions with Netstation devices are via a reliable RPC
mechanism that mimics the reliability and functionality of intra-
workstation bus-based communication. Hence, an X-Window server
would not itself be an NVD (as connections are made via TCP), but
the X-window server process may control an NVD display (e.g. the
virtual workstation-size portion of the wall-size display described
above).
This use of a lightweight RPC transaction protocol for device
access implies that direct device control will be practically
limited to a local area network. For applications such as cross-
country video, the transport functionality required over long delay
paths will better served using an application process (local to the
display device) to receive TCP (or RTP) streams and generate device
control messages.
Amidst this generality, it is easy to loose sight of the original
mission of an NVD, which is a device that is controlled via
commands sent across a network instead of a system bus. A simple
NVD will function much like its bus-interfaced counterpart. A
process should be able to open an NVD and become its exclusive
Cooper [Page 16]
Internet Monthly Report December 1994
controlling Owner. In particular, a kernel process should be able
at boot time to open its NVDs and gain exclusive controlling access
to them.
Device/Service Access and Naming
A simple NVD will export a single device interface to be used by
some single Owner process on another host. This could be a
primitive interface that closely models the functions of the
underlying physical device. The network would carry the Owner's
device commands and the responses from the NVD that they generate
via our reliable RPC protocol.
However, access to NVDs may be complicated by the fact that a
single local area network interface may provide network access for
multiple NVDs. Several physical resources may be available within
a particular Netstation chassis, and various capabilities and
virtual capabilities may be exported simultaneously with individual
interfaces and/or a combined interface.
For example, a Display NVD chassis might contain several distinct
devices: frame buffer, audio output, and JPEG decompression units.
Each of those can accept independent streams of input data and
commands. These could be individually exported as a single complex
Display NVD interface or each as a distinct NVD interface. This
could be dynamically determined under the NVD Owner's control or by
the code loaded when the chassis is booted.
We propose to use a method which allows similar access for any type
of NVD. This approach should be straight-forward in the common
case of a simple NVD, and extensible as NVDs become more complex.
All NVDs will export an RPC-based "access" interface that is
presented via a well-known port. RPC calls will be made available
via that interface for OPENing, CLOSEing, and obtaining additional
NVD-specific information and status.
The basic operation performed by any process wanting to access any
device will be an RPCopen(device_name) call made to the well known
port at Netstation chassis interface. The Netstation device can
demultiplex the initial request based on device name (if needed),
and a separate communication channel can be allocated for a
particular device session. In the degenerate case of a single
device on an interface, a default device name referring to "self"
could be used.
This approach provides a well-defined rendezvous point for device
access, and allows devices to have varying degrees of
sophistication. For example, simple devices with insufficient
Cooper [Page 17]
Internet Monthly Report December 1994
resources to implement an access control database and other complex
management functionality can be configured to forward RPCopen()
calls to a surrogate managerial process.
The basic information needed to open and gain control over an NVD
is the NVD's Internet address and the appropriate device name to be
used as a demultiplexor. The NVD network address is similar in
function to the device address that is needed at boot time to
access and control a bus-interfaced device. It is assumed that the
underlying network- and link-layer protocols deal with packet
delivery functions.
Naming, Device Location, and NetStation Configuration
An NVD's address can be determined directly or it could be
determined from its "name". We assume NVD names will correspond to
the domain-name hierarchy. The most basic NVD management functions
will use the DNS to map device names to their access address.
The device's domain-name can also be used directly to demultiplex
within multi-device NVD interfaces, or the DNS can return an
internal NVD number (along with internet address) to be used for
this purpose. Similarly, the DNS could return a port number
specific to a particular NVD as an alternative to the well-known
port rendezvous approach. These additional mappings could be
supported currently using DNS "TXT" resource records. Recently
proposed DNS extensions for dynamic update could support
dynamically-instantiated virtual devices.
The functionality provided by these DNS mappings serve as the
lowest-level NVD management service. Using domain names as an
intermediate layer, additional services such as configuration (i.e.
determination of associations among Netstation devices) and
resource location (i.e. determination of which devices are
available to meet certain requirements) will be layered on top of
these basic mapping services. We expect to exploit current IETF
work in Dynamic Host Configuration and Service Location to provide
some of these Netstation management functionality.
Greg Finn <finn at isi.edu, Steve Hotz, <hotz at isi.edu, Bruce Parham,
<Bparham at isi.edu>, S.K. Reddy Monnangi, <Monnangi at isi.edu>, Vivek
Goyal
Cooper [Page 18]
Internet Monthly Report December 1994
PC-ATOMIC
---------
ATOMIC PERFORMANCE TESTS
We have measured the performance of NFS and FTP over ATOMIC, and
found (as expected) that the disk bandwidth is the bottleneck.
Ethernet performance is network-limited to 7-8 Mbps, but the ATOMIC
LAN provides disk-limited 18 Mbps FTP and 19 Mbps NFS.
FTP performance is relatively independent of file size, but NFS
exhibits a long "ramp" where 200K byte files are 8 Mbps, 700K byte
files are 13 Mbps, and the bandwidth tops out for 2M byte files. We
used 16K byte packets for these measurements.
Prior measurements indicate that native packet memory-memory
bandwidth over ATOMIC is 300 Mbps, TCP is 48 Mbps, and UDP is 54
Mbps.
NFS and FTP bandwidths in the ATOMIC LAN are limited by the
read/write bandwidths of the SPARCs. We found that (on a SPARC
20/50 or 10/512) the disk write bandwidth was 20 Mbps, and the read
bandwidth was 275 Mbps. (A Sparc 2 has a lower read bandwidth, near
60 Mbps).
We are also measuring the performance the ATOMIC LAN when two
sources contend for a shared link. We used a configuration as shown
below:
S1 -----> switch -----> R
^
|
|
|
S2
In our experiment, S1 emits 512-byte packets, and we vary the size
of the packets from S2 (over multiples of 512). Myricom's switches
apparently perform round-robin arbitration on a per-packet level,
so the bandwidth per source at the multiplexing switch is a ratio
of the packet sizes.
We hope to use this information, along with interval gaps in packet
emission, to provide a source-level mechanism that emulates the
configurable router queuing disciplines. These disciplines are
assumed by QoS and policy mechanisms, but do not exist in the
ATOMIC LAN.
Cooper [Page 19]
Internet Monthly Report December 1994
ATOMIC LAN INSTALLATION AND CONFIGURATION
We have developed automated procedures for configuring a machine to
use only the ATOMIC interface for network communication from
power-up for all SPARC 2, 10, and 20 machines running SunOS 4.1.3.
This required adding the Myricom driver to the kernel. We are
developing a plan for migrating all ISI HPCC Division Sun SPARCs to
the ATOMIC LAN, while allowing machines to individually revert to
the Ethernet backup after rebooting.
ATOMIC GATEWAY PROGRESS
We have a version of VINCE installed that is modified to use the
FORE SBA-200 S-BUS host interface card to communicate with the NRL
PTAI S-BUS host interface card. We are currently evaluating the two
cards for use in an ATM gateway, first using a SPARC S-BUS, and
later as a stand-alone system.
Work is continuing on our evaluation of the x-Kernel (Peterson,
Arizona) as a possible vehicle for protocol experiments that bypass
the current BSD implementations of TCP/IP. We are currently
porting the ISI "blast" program, which measures TCP and UDP
performance in memory-to-memory data transfers, to run as part of
the x-Kernel. Preliminary results indicate that other tuning will
be required in order to achieve good performance results. If this
phase of the project is successful, we plan to use the x-Kernel to
investigate experimental protocol implementations and direct
coupling of the lowest level of the x-Kernel and the drivers for
various high-speed networks including ATOMIC and ATM.
HIGH PERFORMANCE SECURITY ISSUES
This month we issued an Internet Draft of our report on MD5
authentication (IMR Nov. 1994). It is available at the usual
places, including: ftp://ftp.isi.edu/internet-drafts/draft-touch-
md5-performance-00.txt
Joe Touch <touch at isi.edu>, Annette DeSchon <deschon at isi.edu> Hong
Xu <xu at isi.edu>, Ted Faber <faber at isi.edu>
Cooper [Page 20]
Internet Monthly Report December 1994
INFRASTRUCTURE
Jon Postel, Joyce Reynolds, S. Herzog, B. Tung, B. Manning, Paul
Mockapetris, Deborah Estrin, Steve Casner, Bob Braden, Steve Berson
to attend the 31st IETF meetings in San Jose, 4-9 December. Paul
Mockapetris and J. Postel to attend the ISOC Board of Trustees
Meetings, 14-16 December 1994.
25 RFCS WERE PUBLISHED THIS MONTH.
1719 A Direction for IPng. P. Gross. December 1994.
1726 Technical Criteria for Choosing IP The Next Generation
(IPng). C. Partridge & F. Kastenholz. December 1994.
1727 A Vision of an Integrated Internet Information Service.
C. Weider & P. Deutsch. December 1994.
1728 Resource Transponders. C. Weider. December 1994.
1729 Using the Z39.50 Information Retrieval Protocol. C. Lynch.
December 1994.
1730 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4. M. Crispin.
December 1994.
1731 IMAP4 Authentication Mechanisms. J. Myers. December 1994.
1732 IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS. M. Crispin.
December 1994.
1733 DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4. M. Crispin.
December 1994.
1734 POP3 AUTHentication command. J. Myers. December 1994.
1735 NBMA Address Resolution Protocol (NARP). J. Heinanen & R.
Govindan. December 1994.
1737 Functional Requirements for Uniform Resource Names.
K Sollins & L. Masinter. December 1994.
1738 Uniform Resource Locators (URL). T. Berners-Lee,
L. Masinter & M. McCahill. December 1994.
1739 A Primer On Internet and TCP/IP Tools. G. Kessler &
S. Shepard. December 1994.
Cooper [Page 21]
Internet Monthly Report December 1994
1740 MIME Encapsulation of Macintosh Files - MacMIME.
P. Faltstrom, D. Crocker & E. Fair. December 1994.
1741 MIME Content Type for BinHex Encoded Files. P. Faltstrom,
D. Crocker & E. Fair. December 1994.
1743 IEEE 802.5 MIB using SMIv2. K. McCloghrie, E. Decker.
December 1994. (Obsoletes RFC1231) (Obsoleted by RFC1748)
1744 Observations on the Management of the Internet Address
Space. G. Huston. December 1994.
1745 BGP4/IDRP for IP---OSPF Interaction. K. Varadhan,
S. Hares, Y. Rekhter. December 1994.
1746 Ways to Define User Expectations. B. Manning & D. Perkins.
December 1994.
1748 IEEE 802.5 MIB using SMIv2. K. McCloghrie & E. Decker.
December 1994. (Obsoletes RFC1743, RFC1231)
1749 IEEE 802.5 Station Source Routing MIB using SMIv.
K. McCloghrie, F. Baker & E. Decker. December 1994.
(Updates RFC1748)
1750 Randomness Recommendations for Security. D. Eastlake,
3rd, S. Crocker & J. Schiller. December 1994.
1751 A Convention for Human-Readable 128-bit Keys. D. McDonald.
December 1994.
1753 IPng Technical Requirements Of the Nimrod Routing and
Addressing Architecture. N. Chiappa. December 1994.
THE US DOMAIN
=============
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 628
PHONE 95
----------------------------
Total Contacts 723
Cooper [Page 22]
Internet Monthly Report December 1994
DELEGATIONS 57
DIRECT REGISTRATIONS: 23
OTHER US DOMAIN MSGS: 643
---------------------------
Total 723
OTHER US DOMAIN MESSAGES INCLUDE: modifications, application
requests, discussion and clarification of the requests, questions
about names, referrals to other subdomains or to/from the InterNic,
resolving technical problems with zone files and name servers, and
whois listings.
The list of delegations below does not reflect the entire number of
registrations and delegations in the whole US Domain. Many
subdomains have been delegated and administrators of those
subdomains register applicants in their domains. Below are direct
registrations in the US Domain.
To obtain a copy of the list of other delegated localities and
subdomains you can ftp the file in-notes/us-domain-delegated.txt
from venera.isi.edu, via anonymous ftp.
Third Level US Domain Delegations this month
--------------------------------------------
CC.ME.US Maine Community Colleges
TEC.ME.US Maine Technical Colleges
LIB.ME.US Maine Libraries
BETHEL.ME.US Bethel, Maine, locality
PORTSMOUTH.OH.US Portsmouth, Ohio, locality
HILLIARD.OH.US Hilliard, Ohio
DOT.FED.US United States Dept. of Transportation
PARKER.CO.US Parker, Colorado
STEAMBOAT.CO.US Steamboat, Colorado
JEFFERSON.CO.US Jefferson, Colorado
STATE.GA.US Georgia Dept. of Administrative Services
MADISON.WI.US Madison, WI, locality
HICKORY.NC.US Hickory, NC, locality
STATE.IA.US Iowa State Government
PORT-NY-NJ.ISA.US Port Authority of New York and New Jersey
Cooper [Page 23]
Internet Monthly Report December 1994
Other Direct US Domain Delegations this month
---------------------------------------------
CO.DAKOTA.MN.US Dakota County of Minnesota
VILLAGE.CHENEQUA.WI.US Village of Chenequa, Wisconsin
CI.SALINAS.CA.US City of Salinas, California
URA.NW.DC.US Universities Research Association
USUSP.NW.DC.US US Universities/Saudi Project
FCDS.PVT.K12.CT.US Fairfield Country Day School
CRYSTAL.HILLSBORO.CA.US Crystal Springs Uplands School
LORETTOHS.LCSD.K12.TN.US Loretto High School
NWACC.CC.AR.US Northwest Arkansas Community College
NMMI.CC.NM.US New Mexico Military Institute
GTC.GEORGETOWN.KY.US Georgetown College, Ky.
MCCALLIE.CHATTANOOGA.TN.US The McCallie School
CAMGRAD.FAY.AR.US Cambridge Graduate School, Inc.
KOMUSIC.SF.CA.US KOMusic, San Francisco
DNR.STATE.WA.US Washington State Dept. of Natural Resources
NYCT.NYC.NY.US New York City Transit
NVHA.LOWELL.MA.US Merrimack Valley Hebrew Academy
PUC.CI.SF.CA.US SF Public Utilities
RGV.LIB.NM.US City if Albuquerque, Regional Library
CAMDEN.LIB.NJ.US Camden County Library
SACRAMENTO.LIB.CA.US Sacramento Public Library
HANDLEY.LIB.VA.US Handley Regional Library
FLP.LIB.PA.US Free Public Library of Philadelphia
SANTA-CRUZ.LIB.CA.US Santa Cruz Library System
SF.LIB.CA.US San Francisco Public Library
CITY-HALL.SF.LIB.CA.US San Francisco City Hall
CITY-WEB.SF.CA.US City of San Francisco Web Project
STEGE.DST.CA.US Stege Sanitary District
APT.FREEMONT.CA.US Atlantic Pacific Technologies, Inc.
TIMES.ST.PETE.FL.US St. Petersburg Times
TRAVELNET.SUNNYVALE.CA.US TravelNet, Inc., Software Develop. Co.
GGBHTD.DST.CA.US Golden Gate Bridge Highway Transit District
ESC.TULSA.OK.US Tulsa Public School District
REDHUCYT.NW.DC.US Dept. Scientific and Technological Affairs
POWELL.FAUQUIER.VA.US Private
FOXFIRE.SF.CA.US Private
KNACK.SF.CA.US Private
MICHAUD.NEWINGTON.CT.US Private
BURTON.FROSTBURG.MD.US Private
MARSDEN.ARLINGTON.TX.US Private
SSSSS.FALLS-CHURCH.VA.US Private
Cooper [Page 24]
Internet Monthly Report December 1994
TABLE OF DELEGATED DOMAINS BY STATE
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
AK X
AL X
AR X X
AZ X X X X X
-----------------------------------------------------------
CA X X X
CO X X X X X X X
CT
DC X
-----------------------------------------------------------
DE X
FL X X X X X X X
GA X X X X
HI X X X X X X X
-----------------------------------------------------------
IA X X X X X
ID X X X X X X X
IL X X X X X
IN X X X X X X X
-----------------------------------------------------------
KS X X X X
KY X X X X X X X
LA X X X X X
MA X X
-----------------------------------------------------------
MD X X X X
ME X X X X
MI X X X X X
MN X X X X X X X
-----------------------------------------------------------
MO X X X X X X
MS X X X X
MT X
NC X X X X X
-----------------------------------------------------------
ND X X X X X X X
NE X X X X
NH X X
NJ X X
-----------------------------------------------------------
NM X X X
NV
NY X X X X X X X
OH X X X X X X X
Cooper [Page 25]
Internet Monthly Report December 1994
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
OK
OR X X X X X X X
PA X X
RI X X X
-----------------------------------------------------------
SC X X X X X X X
SD X X X X X
TN X
TX X X X X X X X
-----------------------------------------------------------
UT X X X X
VA X X X X
VI
VT X
-----------------------------------------------------------
WA X X
WI X X X
WV X X X X X X X
WY X X
===========================================================
For more information about the US Domain please request an
application via the RFC-INFO service. Send a message to RFC-
INFO at ISI.EDU with the contents "Help: us_domain_application". For
example:
To: RFC-INFO at ISI.EDU
Subject: US Domain Application
help: us_domain_application
Ann Westine Cooper (Cooper at ISI.EDU)
MULTIMEDIA CONFERENCING
We have added an automated user directory to MMCC, ISI's session
tool that orchestrates explicit-invitation, multiway calls by
exchanging address and configuration information and spawning
familiar MBONE tools (e.g., vat, nv). Originally, users could set
up their own personal address books using a combination of a
startup file, on-the-fly entry from the graphical user interface
(GUI), and automatic updates as new users called. However, users
have requested an easier method to dynamically find the addresses
of others who are willing/able to "accept" calls, i.e., others who
are running MMCC. To this end, we have augmented MMCC with a
multicast user directory function. On a fixed multicast address,
Cooper [Page 26]
Internet Monthly Report December 1994
MMCC will announce (if enabled) the user's availability at a
particular locale. Each MMCC also listens on that address for
announcements from remote users and adds those users to its
directory. Thus, MMCC acts in part as a user locator service.
This approach was inspired by the control component of the RTP
protocol developed in the IETF Audio/Video Transport working group,
and by LBL's session directory tool, sd. The idea was to apply
these multicast-based techniques to the user directory problem.
Besides the known resiliency of a soft-state multicast approach, we
use multicast announcements to obtain the appropriate TTL for
reaching remote users and also to track mobility. Notably, we make
user directory announcements at different TTL levels so that
announcements may be made more frequently within smaller regions
(lower TTLs). Each remote MMCC also stores the minimum TTL (as
inserted by the sender) at which the announcement was first heard.
When a session is created, MMCC selects the maximum of the minimum
TTL values of all group members and passes this value to the
associated media tools for proper scoping of the multicast real-
time data.
Presently, we are working to solve some of the scaling issues
before wider release of this feature. For example, scaling effects
everything from the network bandwidth consumed by announcement
messages to the GUI's ability to organize and filter lists of
users, and to the internal architecture of data structures for fast
user lookup. Therefore, we are currently experimenting with
parameterizing the tool for efficient operation as the number of
users grows very large.
Eve Schooler (schooler at cs.caltech.edu), Steve Casner
(casner at isi.edu)
MERIT/NSFNET ENGINEERING
------------------------
This report summarizes recent activities of Merit's Internet
Engineering and Network Management groups on behalf of the Routing
Arbiter Project and the NSFNET Backbone Service Project.
The CNMS (Centralized Network Management System), developed by
Merit for the Routing Arbiter project, is now performing
preliminary monitoring of the Route Servers at the PacBell NAP and
the MFS MAE-East facility, and beginning to perform delay
measurements to the Route Servers. The combination of these
figures with packet delay and loss measurements at the NAPs will
help the RA team gauge reliability of the NAP fabric and in-band
connectivity between the RA NOC and the NAPs.
Cooper [Page 27]
Internet Monthly Report December 1994
Work continues on replacement of the Policy Routing Database
(PRDB), used for the NSFNET Backbone Service, with the Routing
Arbiter Database (RADB). The RADB itself forms part of the new
Internet Routing Registry (IRR), which will incorporate registries
maintained by several national and international networking
organizations. Under the RADB, the method for submitting new nets
to be routed over AS690 will change. Instead of submitting NACRs
through e-mail, users will directly register information by sending
in "route templates." Additions and entries to the new registry
will be made by the home AS that creates the route, rather than by
an AS690 peer AS. Merit is working closely with RIPE to ensure
that the RIPE database will have all required routing information
when the PRDB is retired and authoritative routing information for
European routes is maintained by the RIPE NCC. Transition plans
are available on the RADB Web site (http://www.ra.net/rrinfo.html)
and through anonymous FTP to ftp.ra.net in the /pub/radb/
directory. For more information about using the RADB, send e-mail
to rrgroup at merit.edu.
Peering sessions have been established between the ANS/NSFNET
backbone and Network Service Providers at the three priority NAPs
and MFS's MAE- East facility. At the PacBell NAP, ANS/NSFNET is
peering with MCInet, CRL, and the RA Project's Route Server; at the
Sprint NAP, ANS/NSFNET is peering with SprintLink and MCInet; at
the MFS facility, ANS/NSFNET is peering with AlterNet, CERN/DANTE,
PIPEX, PSI, NETCOM, MCInet, and Net99. Physical connections to the
Ameritech NAP have been established by ANS/NSFNET, the RA Route
Server, and MCInet.
The number of regionals that have completed their transition from
the NSFNET backbone service grew substantially this month.
MOREnet, THEnet, NYSERNet, NevadaNet, and MSCnet are now obtaining
interregional Internet service from SprintLink, and SURAnet is
obtaining service from MCInet. CA*net, the Canadian national
network, has cut over from the NSFNET backbone service to MCInet.
The current version of the ANS/NSFNET router software fixes two
long- persistent backbone problems: hangs in the FDDI cards used
in the RS/6000 backbone routers, and spontaneous resets of the T3
interface cards in the ANS Ciscos.
Several staff led sessions at the 31st IETF, held December 5-9 in
San Jose. Jessica Yu (with Vince Fuller of BARRNET) led the
session of the CIDR Deployment Working Group (cidrd). Elise Gerich
gave a presentation about the NSFNET transition at the Network
Management Area open meeting, participated in the IAB open meeting,
and co-chaired the IEPG meeting preceding IETF. The IEPG meeting
was also attended by other Merit staff and many Network Service
Cooper [Page 28]
Internet Monthly Report December 1994
Providers. In addition, Merit staff members participated in the
Second ATM NAP Workshop, which focused on issues related to the
construction and operation of ATM NAPs. The workshop also included
presentations by several Network Service Providers.
Jessica Yu gave a talk about the NSFNET transition and the Routing
Arbiter Project at the CICNet technical board meeting.
Susan R. Harris (srh at merit.edu)
MIDNET
------
MIDnet Announces WWW and Gopher Servers
MIDnet's World Wide Web home page, Gopher, and FTP servers were
officially announced to the membership and to the Internet
community in early December. Incorporated within the Web home page
are links to selected MIDnet member home pages as well as links to
MIDnet-developed resources. These resources provide user-friendly,
transparent interfaces to multiple field searchable databases,
where the user can perform searches by keyword, title, or text
(separately or together) for the retrieval of information contained
in popular gophers, mailing lists, listservs, or news groups.
Here are the URLs for MIDnet's WWW home page, gopher services, and
resources:
MIDnet Home Page:
http://www.mid.net
MIDnet Main Gopher:
gopher://gopher.mid.net
Gopher Jewels:
http://www.mid.net/GJEWEL
Net-Happenings:
http://www.mid.net/NET
gopher://gopher.mid.net:7000
INFO-MAC:
http://www.mid.net/INFO-MAC
Diane Kovac's directory of Scholarly Electronic Conferences:
http://www.mid.net/KOVACS
gopher://gopher.mid.net:7002
Cooper [Page 29]
Internet Monthly Report December 1994
comp.archives.msdos.announce newsgroup:
http://www.mid.net/MSDOS_A
MIDnet's home page also includes links to the InterNIC home page,
the InterNIC InfoGuide, the National Science Foundation home page.
Information on MIDnet's products and services, seminar and
conference announcements (with e-mail and registration input
forms), and access to the MIDnet Newsletter archives is also
provided.
MIDnet Completes Round of Security Seminars
A series of one-day seminars focusing on Internet security, "A
Practical Guide to Secure Internet Connections", was held in St.
Louis, Kansas City, and Chicago in early December. Over 50 people
attended each seminar, confirming the high level of interest in
this topic. The seminar agenda also featured a presentation
entitled "NSF Perspective on the Internet Transition". On behalf of
the NSFNET Backbone Service Project, this presentation was provided
in St. Louis by Elise Gerich of Merit, Inc., and in Kansas City and
Chicago by David Staudt of the NSFNET.
MIDnet Seminar Activities Continue
In early November, a toll-free number was installed to support
MIDnet's ongoing seminar and conference activities, and to support
the Network Information Center in efforts to function as a
clearinghouse for information and answer Internet-related
questions. The number was announced to the MIDnet membership as
part of the NIC's weekly e-mail to members.
Information on MIDnet services can be requested by calling 1-800-
682-5550, or via e-mail to: info at mid.net
NORTHWESTNET
------------
The Internet Passport: In Press and OnLine
===========================================
The newest book edition of this respected Internet reference and
resource guide hit the presses in December and will be shipping in
mid-January. Ordering information for the book is available
directly from the publishers, Prentice Hall, at 1-800-382-3419.
The Internet Passport: NorthWestNet's Guide to Our
World Online (5th ed.) By NorthWestNet. 1995.
ISBN 0-13-194200-X. 700pp. $29.95.
Cooper [Page 30]
Internet Monthly Report December 1994
And, for organizations who have or plan to bring the Internet to
each desktop in their organization, NorthWestNet announces its
upcoming release of "The Internet Passport-HTML." Take advantage of
your computer network to deliver this online interactive
application to your staff. It is not only a guide to the
applications and services of the Internet, but it also offers
direct access to some of the most highly-valued resources online
today. For details and licensing information, please contact Jan
Eveleth, NorthWestNet, Director of User Services: (206) 562-3000 or
eveleth at nwnet.net.
NorthWestNet's Internet Training Series
=======================================
The fall series of classes held at the NorthWestNet training
facility came to a successful close shortly before the holidays.
NorthWestNet instructors were also busy on the road as they
conducted hands-on classes for the Washington State Department of
Information Services and the Washington State Department of Labor
and Industries at their facilities in Lacey, WA and Tumwater, WA
respectively.
NorthWestNet is pleased to continue the expansion of its training
program with its winter/spring 1995 schedule and the inclusion of
two new classes: "The Internet Walkabout" and "Internet Search
Strategies." Continue below for more information.
CLASSES - Winter/Spring 1995
Internet Walkabout: An Introduction to the Internet - NEW CLASS
---------------------------------------------------------------
A non-technical introduction to the Internet, this 2 hour class
examines the Internet from various perspectives. Learn about the
Internet's growth, structure and content and the various ways of
connecting to the Internet. Internet applications, such as e-mail,
FTP, Gopher, Usenet and World Wide Web will be described and
illustrated, with the help of on-line demonstrations. An excellent
introduction to our other classes. Prerequisite: None. This class
is offered from 9:00 a.m. to 11:00 a.m. on March 15 * April 20 *
May 12.
Introduction to the Internet and Electronic Mail
------------------------------------------------
A non-technical overview of the Internet sets the stage for this
introduction to an essential Internet tool--electronic mail. You
will learn about the advantages of e-mail, how to recognize and use
Cooper [Page 31]
Internet Monthly Report December 1994
Internet addresses, and about a variety of useful e-mail functions,
such as reply, forward, save, and carbon copy. Demonstrations and
hands-on exercises use the popular PINE e-mail program.
Prerequisite: understanding of basic personal computer operations.
This class is offered from 9:00 a.m. to 12:00 p.m. on: Jan.23 *
Feb. 7
Internet Discussion Groups
--------------------------
The Internet provides a number of forums for discussion of a wide
range of topics. This class introduces Usenet and its newsgroups,
as well as Internet mailing lists and LISTSERV lists which anybody
with access to Internet e-mail can join. These discussion forums
demonstrate the nature of the global community the Internet makes
possible. Prerequisite: understanding of electronic mail. This
class is offered from 9:00 a.m. to 12:00 p.m. on: Jan.24 * Feb. 8
* March 16 * April 21 * May 15.
Internet Fundamentals: Telnet and FTP
-------------------------------------
Along with e-mail, File Transfer Protocol (FTP) and Telnet
constitute the basic set of Internet tools. Learn to use FTP to
move files from one Internet computer to another. Using Telnet,
you will access services on Internet computers around the world,
including library catalogs, specialized databases, weather
forecasts, and community services. Prerequisite: understanding of
basic personal computer operations. This class is offered from
9:00 a.m. to 12:00 p.m. on: Jan. 25 * Feb. 9 * March 17 * April 24
* May 16.
Navigating the Internet with Gopher and Veronica
------------------------------------------------
Gopher is a popular menu-oriented, easy to use interface to the
Internet. It allows for seamless access to resources on host
computers all over the world. You will learn to use Gopher and its
companion utility veronica, which lets you locate specific
resources in the global expanse of "gopherspace." Prerequisites:
understanding of basic Internet concepts and personal computer
operations. This class is offered from 9:00 a.m. to 12:00 p.m. on:
Jan. 26 * Feb. 10 * March 20 * April 25 * May 17.
Cooper [Page 32]
Internet Monthly Report December 1994
Traveling the World Wide Web
----------------------------
The fastest growing service on the Internet, the dynamic World Wide
Web (WWW) "hyperlink" environment, lets you easily access text,
graphics, video, and sounds from around the world. You will learn
to use both Lynx, a plain text browser, and a graphical browser
with multimedia capabilities. Prerequisites: understanding of
basic Internet concepts and personal computer operations. This
class is offered from 9:00 a.m. to 12:00 p.m. on: Jan. 27 * Feb.
13 * March 21 * April 26 * May 18.
Internet Search Strategies - NEW CLASS
--------------------------------------
Ever feel overwhelmed when trying to find specific information on
the Internet? Attend this class to learn strategies for locating
the key information you need. We'll discuss using various Internet
tools such as veronica, archie, and Web spiders to track down
information, as well as identifying and using subject based
Internet guides on-line, such as Gopher Jewels and Yahoo. To make
this seminar even more practical, you will practice searching for
items covering your particular area of interest. Prerequisite:
Basic understanding of electronic mail, Usenet, Gopher, and World
Wide Web. This class is offered from 9:00 a.m. to 12:00 p.m. on
March 22 * April 27 * May 19.
Special Training Services
-------------------------
In addition to the regularly scheduled classes, NorthWestNet also
offers training sessions with the same or with customized content
for groups of eight to twelve persons at NorthWestNet's offices or
up to twelve persons at clients' sites. Please call for rates and
scheduling.
For information regarding class registration, refunds &
cancellations, and overnight accommodations, connect to
NorthWestNet's Gopher server:
Host: gopher.nwnet.net port 3333
Menu items: NorthWestNet Information and Resources
/NorthWestNet Internet Training Series
URL:gopher://gopher.nwnet.net:3333/11/nwnet-info.resources/
internet.training
Or, contact NorthWestNet: (206) 562-3000 or training at nwnet.net.
Cooper [Page 33]
Internet Monthly Report December 1994
------------------------
NorthWestNet E-mail: info at nwnet.net
15400 SE 30th Place, Suite 202 Phone: (206) 562-3000
Bellevue, WA 98007 Fax: (206) 562-4822
NorthWestNet serves the six state region of Alaska, Idaho, Montana,
North Dakota, Oregon, and Washington.
PREPnet
-------
New PREPnet Members
- The Networks, York, PA
- Penn Communications, Uniontown, PA
- LaRoche College, Pittsburgh, PA
- Apollo Trust Company, Apollo, PA
- Forbes Health System, Pittsburgh, PA
- LebaNet, Lebanon, PA
With this addition, PREPnet now totals 213 members.
PREPnet News
------------
Meetings & Conferences
Date Attendee(s) Event
12/5-9 Marsha Perrott IETF
12/9-10 Tom Bajzek Mid-Atlantic Eisenhower Consortium
Felicia Ferlin Mathematics and Science Education:
Internet Conference
For information regarding connectivity options in the Commonwealth
of Pennsylvania, contact the PREPnet NIC:
305 S. Craig St. E-Mail: nic at prep.net
2nd Floor Telephone: (412) 268-7870
Pittsburgh, PA 15213
PREPnet NIC (nic at prep.net)
Cooper [Page 34]
Internet Monthly Report December 1994
SPRINT NAP PI
-------------
The Sprint NAP, located in Pennsauken, NJ, is currently based on
FDDI. An FDDI ring (Two Cisco concentrators) was operational on
August 31. A DEC GigaSwitch, which will provide substantially more
aggregate bandwidth, has been prooposed as an upgrade to the NAP to
address expected traffic growth in early 1995. The Gigaswitch is
currently at the NAP and discussions between Sprint and the NSF are
underway. The NAP team is currently investigating possible
alternatives beyond the Gigaswitch that will address continued
increases in NAP traffic. The stated migration path for the Sprint
NAP will lead to an ATM-based strategy. Among other advantages this
is the only known way to achieve NSP to NSP connections over the
NAP at rates of 150Mbps, 622Mbps and beyond. As stated at the IETF
the continued emphasis at the Sprint NAP will be reliable
operation.
ANS and MCI have DS-3 circuits connecting to routers at the Sprint
NAP. They are peering with each other and are exchanging
production traffic with each other. The ANS link and T3-ENSS
router were operational September 13; the MCI link and Cisco 7010
router were operational September 15. ANS and MCI began peering
with each other on October 21.
SprintLink began peering sessions with ANS and MCI, but did not
begin exchanging traffic across the NAP pending the implementation
of DS3 level connections. SprintLink completed installation of dual
DS-3 circuits to the Sprint NAP in early Dec. (the links provide
diverse connectivity to the SprintLink Chicago and Wash. D.C.
nodes) and is expected to be exchanging traffic with other NAP NSPs
by at least early Jan.
CERFnet has an ATM DS3 connection to the Sprint NAP. This
connection terminates at a Digital Link DL-3200 ATM DSU and a Cisco
7010 at the NAP. The CERFnet connection to the NAP was operational
November 8. CERFnet and Sprint are currently testing this
connection.
The Routing Arbiter workstation is at the Sprint NAP also and is
expected to begin production service pending implementation of the
Gisgaswitch (which will allow MAC level filtering for the RA
workstation.)
Five additional organizations have expressed interest in
connectivity to the Sprint NAP, discussions are underway.
Cooper [Page 35]
Internet Monthly Report December 1994
The Sprint NAP team has published a Sprint NAP Handbook which
provides information needed to connect to the NAP (e.g., fees,
contact phone numbers, access requirements) A copy can be obtained
from the MERIT WWW server or from Tim Clifford (tcliff at sprint.net;
703-904-2723), the NAP PI.
Tim Clifford (tcliff at sprint.net)
UCL
----
Jon Crowcroft attended and co-chaired with Christian Huitema, the
HIPPARCH workshop at INRIA, on High Performance Protocols and
Architectures. Some 20 papers were presented and lively debate on
Integrated Layer Processing and Application Layer Framing, as well
as protocol specification and compilation to full systems.
The current WWW source for information about the project is:
http://www.cs.ucl.ac.uk/people/jon/hipparch/hipparch.html
A followup workshiop will be held at UTS in association with the
IFIP ULPAA Conference in December 1995.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
Cooper [Page 36]
Internet Monthly Report December 1994
USER SERVICES REPORT
--------------------
Trip Report
19th RIPE Meeting - Lisbon, Portugal
September 1994
Joyce K. Reynolds
USC/Information Sciences Institute
The 19th RIPE Meeting
The 19th RIPE Meeting was held in September 1994 in Lisbon, Portugal.
Rob Blokzijl lead the review and approval of the agenda and minutes
of the last meeting. Parallel working group sessions started after
the general plenaries. Approximately 75 people attended.
General Plenary
1. RIPE NCC Report - Daniel Karrenberg
There have been changes in personnel and workload developments
since the last RIPE meeting. This has lead to a temporary
curtailing of RIPE NCC services. Prioritizing of tasks has not
solved the workload and personnel problems. If the problems are
not resolved, there will have to be a permanent curtailment of NCC
activities. Additional discussion of this topic is contained
below in section 3.
Daniel reported that the RIPE DNS host count has almost doubled in
one year. It is projected to hit one million by the end of this
year. The growth of the number of local IRs (Internet Registries)
has been a real surprise. The increasing numbers of local IRs has
been good and bad. The growth is much more than expected. The
growth curve of local IRs seems parallel to the growth of the host
curve. The new provider registries need more support and guidance
from the NCC than those having a long Internet history. It is
close to getting out of hand, but new registries should provide
more income for the NCC.
Registry workload growth is close to becoming out of control. The
hostmaster alone now logs at least 30+ electronic mail messages a
day, not counting phone calls and fax requests. A tendency to
"rubber stamp" incoming requests is growing. This is resulting in
a quality control problem. The NCC doesn't want to continue to
rubber stamp requests, as mistakes tend to be made in the process.
Yet, there is not enough time to support local IRs, nor is there
time to adapt and produce documentation. There is NCC staff burn
Cooper [Page 37]
Internet Monthly Report December 1994
out, as there is much more than 100% routine duties to be
performed each day. This has turned into a vicious circle.
Currently, personnel concerns are of utmost importance. Geza
Turchanyi's trainee period with the NCC ended July 15th, and he
has returned to Hungary. Mirjam Kuhne joined 1 July 1994 as a
junior administrative staff member. The current staffing level is
3.5 FTE (Full Time Equivalent). The NCC needs 5 FTEs now. The
real need is somewhat higher. The core staffing situation of the
NCC has not changed since the first of this year. The Routing
Registry needs 1 FTE when PRIDE (Policy Based Routing
Implementation and Deployment in Europe) ends. Tony Bates is
leaving when the PRIDE project is completed.
Unfortunately, the NCC's personnel problems have lead to a
curtailment of services. This includes writing and publication of
documents, and database and registry support and maintenance.
Database curtailment of services include the maintenance of RIPE
handles, exchanges with other regional registries, making the
database classless (This work is performed by PRIDE.), and
maintenance/checking of database contents. The registry services
have cutdown support for local registries and coordination with
other regional registries. Other services that have been
curtailed include Quarterly Reports (the last one was published
January 1994), technical development activities, and special
projects.
What to do? Daniel explained that the core budget will need to
double. Currently, there is 250,000 ECUs available. The need is
500,000 ECUs. There needs to be action as soon as possible. The
RIPE NCC will not be able to hire additional personnel unless they
obtain funding. Setting up a charging scheme has not been an easy
task.
The RIPE NCC needs at least one more engineer as soon as possible.
Otherwise, they will definately curtail services. A decision on
this is needed quickly. Funding and RARE payroll exposure is a
problem. Also, there needs to be one additional engineer to
maintain the Routing Registry. The PRIDE project will end in
October 1994. There is a need to continue to maintain the
registry content, database, and tool maintenance. So far, there
have been no new developments and a decision on this is needed.
Another engineer will be need to be hired in 1995 because of
continued growth. Daniel's conclusions are that the RIPE NCC core
services need additional staff immediately. Additional funding
for the needed staff resources must be secured. Service providers
need to decide whether they want the Routing Registry maintained.
Quality staff needs to be found.
Cooper [Page 38]
Internet Monthly Report December 1994
2. Policy Based Routing Implementation and Deployment in Europe
(PRIDE) - Tony Bates
The PRIDE project is ending in October 1994. There have been
several minor releases since the last meeting. PRIDE-TOOLS-1.0.7
is the current release which includes:
"prpath"
AS-MACRO support
a "mazpand" tool which will expand macros for you
lots of bug fixes
For more information see:
ftp://ftp.ripe.net/pride/tools/pride.tools.ps.tar.Z
The PRIDE guide has been completed. It is at
ftp.ripe.net/pride/docs/guide-1.0.ps.tar.Z
PRIDE's second guide will depend upon RIPE-81++ developments.
There has been a large amount of effort put into the development
of RIPE-81++. The new plan incorporates many database issues,
authorizations and a transition plan. RIPE is working with other
registry providers, also.
PRIDE's first course was given in Amsterdam last May and was
considered useful. A report is available on
ftp.ripe.net/pride/report/pride-report4.ps
More courses are planned in October in Vienna, London, and Pisa.
PRIDE has been reasonably busy. Database maintenance is the most
work.
3. RIPE Reorganization - Rob Blokzijl
Rob announced the intent of RIPE separating from RARE*. He has
been researching this subject since the beginning of summer.
Currently, RARE underwrites the RIPE NCC based on a 1984 funding
level. A more formal management should be created. RARE should
take the initiative to establish a lightweight management
structure, partners, etc. A RARE meeting will be held on 21
September in Amsterdam. Those organizations that are interested
in providing/taking part in funding issues should attend, or send
a letter of intent to fund the RIPE NCC to RARE.
Rob feels at this point in time that the RIPE NCC should be on its
own feet. The creation of a European company called the RIPE NCC
is being seriously investigated. He looked into this over the
summer. It will cost money to do accomplish this endeavor. A
Cooper [Page 39]
Internet Monthly Report December 1994
legal structure needs to be created. EUnet has supplied some
legal assistance, including providing funding to help with the
legal transition procedures. There has also been help from the
EBONE folks, who have already gone through this excercise. Rob
encouraged all attendees to go to their local legal
representatives for advice as each RIPE member nation has its own
set of laws. Rob pointed out that the EEG (European Economic
Group) is a lightweight management group. This group is an
example of what RIPE should be looking at during the restructuring
process.
This separation from RARE will result in RIPE becoming an
impartial and independent entity. It will enable the RIPE NCC to
do more of its own management, business plan, etc. The current
situation is different then the proposed end result.
What about the legal implications and the RIPE NCC? Rob stated
that as a company, the RIPE NCC cannot be based on one national
law, as RIPE members come from different countries. What is the
impact on the RIPE budget? This kind of proposed financial
network can provide for a set of members to assist in the funding,
not just a subset of RARE funding. RIPE itself as an organization
will be in for a change as well.
The RIPE restructuring and reorganization will need to find out
how this will reflect legally in various countries first. A major
concern is that RIPE and the RIPE NCC have been operating on a low
overhead. Members of RIPE have been sending money to RARE to fund
RIPE. This is not working any more. The problem is not whether
this is bad or not, it is one of a formal relationship with
someone. Need to set up the following:
1) Find out legal implications of RIPE restructuring and
reorganization.
2) set up a company and a charging scheme
A question and answer session followed.
1) What is the best way to do this?
2) Are there any other possibilities?
3) Are thre any other formal ways without forming a company?
4) There are concerns about creating something new that may be
a waste of resources.
Cooper [Page 40]
Internet Monthly Report December 1994
Rob stated that commercial service providers are making noises
that they cannot justify putting money into the RIPE NCC unless a
more formal structure is developed. An effort needs to be made to
investigate this. Additional research needs to be completed by
the next RIPE meeting, if RIPE attendees want to do this.
*NOTE: As of October 1994, RARE and EARN have merged to form
TERENA (Trans-European Research and Education Network
Association).
4. RIPE Meeting Structure
Daniel expressed his likes/dislikes about the current RIPE meeting
agenda. He feels that there are too many meetings (three times a
year) and that they are too long in duration. There are also too
many overlaps with the working groups that meet. What exactly do
we have the RIPE meetings for? What do the RIPE attendees want?
The response from the group is that they would like formal
presentation plenaries, reports on current RIPE documentation, and
information disemmination. All felt that the working groups are
actually doing some work and accomplishing goals.
An idea was presented to shorten the agenda to two days.
Day 1 - start in the afternoon, with presentations and reports
from working groups.
Day 2 - technical decisions (not managerial) from previous day or
between meetings
"Day 0" extension is working group meeting time. It is proposed
that this be an outside agenda of the RIPE meetings, either before
or after meetings in conjunction with RIPE meetings and in between
meetings of RIPE. It would be up to the working groups to create
their meetings, work via an agenda, then report. What about going
to just two meetings a year? It was voiced that RIPE should try
the new agenda structure first.
5. European Operators Forum (EOF)
Rob stated that RIPE's Network Operations working group was
discontinued after EBONE came to life. The EBONE Action Team did
not survive the latest EBONE restructuring. The European IEPG
(Internet Engingeerig Planning Group) did not take off earlier
this year as planned. A new forum was created for network
operations, which focussed on common engineering and operations.
The acting chair is Peter Lothberg. What do they do? What are
they planning? This group is not a Pan-European organization. It
Cooper [Page 41]
Internet Monthly Report December 1994
has agreed to work with RIPE.
Peter gave a presentation on EOF. EOF is to be a forum focussed
on the daily operation and coordination running of IP networks in
Europe. If all goes well, it can expand on a global scope. The
first EOF meeting was in Amsterdam. The second meeting was in
Paris. The third meeting was held before the RIPE meeting in
Lisbon, with 32 attendees. EOF has started discussing
interconnection agreements, defining strawman proposals on how new
people can connect, change points, routing problems, CIDR issues,
and mae-east++ (or upgrade). The primary focus of this group is
to keep IP Europe communicating with each other. Their mailing
list is eware-list at ripe.net. The Lisbon EOF meeting agenda
included traffic and routing exchange arrangements between network
service providers, CIDR routes, how to do routing over exchange
points without causing global problems, and development of an EOF
charter as a RIPE oriented working group. The next EOF meeting
will be in November in the UK.
Routing Working Group Session
RIPE-81++ document overview
Read the following draft document:
URL ftp://ftp.ripe.net/ripe/drafts/ripe-81++.{txt,ps}
- only changes not a tutorial of RIPE-81++
- basic agreed changes
- major changes - the component attribute
The component attribute idea is drawn around CIDR. Comments are it
is too difficult to understand and too difficult to maintain. A
"withdrawn" attribute is an aid in CIDR when a more specific route is
withdrawn. "Hole" attribute indicates parts of address space where
there is no connectivity.
Clarification of evaluation of operations. Clarifies the association
and semantics of operators. The "as-name" attribute is a new cloud.
It needs to be optimal for transition. "interas-in and interas-out"
are the outstanding issues.
The above are the major changes to the RIPE-81++ document since the
last draft. Closure needs to be made at this meeting on the RIPE-
81++ working paper.
Cooper [Page 42]
Internet Monthly Report December 1994
"intras-in" and "intras-out"
Link 1
/ \
/ \
/ \
193.0.1.1 193.0.1.2
+-------+ +-------+
| AS2 | | AS3 |
+-------+ +-------+
193.0.1.9 193.0.1.10
\ /
\ /
\ /
Link 2
RIPE-81++ changes are used to distinguish local from global AS-AS
policy. The basic idea being syntax fist. Need to identify the link
of peer session somehow.
There are three issues:
- "localas"
- "ifaddr"
- "masks"
Should <local-id> and <remote-id> be "mandatory" or "optional"? The
reasons for "mandatory" is that one should know both ends of the peer
session useful for tools. The reasons for "optional" is that people
don't know remote-id or won't update.
interas-in (praf=cost) or (praf-med)
interas-out (metric-out=metric-value) =
If interas-in and interas-out attributes are used, then it is
mandatory to have "as-in" and "as-out" attributes registered.
Reasons for: the global policy on this is that it should always be
registers. Only ASs are concerned about his local information and
should be seen purely as local and not general policy. There is a
need to be able to specify more than just a cost as in "as-in" and
"as-out". Reasons against: duplication (possible discrepancies). It
is not clear if as-in, as-out represents policy.
The route object question still has not been resolved. An "inet-ir"
object is a simple object to describe an "internet" router. The
Cooper [Page 43]
Internet Monthly Report December 1994
motivation is that it aids in building configuration and added
information.
- "localas" - describes where an AS router resides in
- "ifaddr" - list of all interface addresses
- adding "masks"
- "peer" - details all (interior [optional] and exterior
peerings), format
- Routing protocol - EGP, BGP, BGP4, IBGP4, IDRP, IGP or other
BGP4 distinctions for CIDR
- "localas" for "faking" AS announcements
A suggestion was made to publish this document as a RIPE document
first, and obtain feedback. Also submit the document to the RFC
Editor requesting it be published as an Informational RFC in order to
obtain further comments.
Database Working Group Session - Marten Tempstra
This working group focussed on a discussion of the RIPE Database
Transition Plan. The RIPE database is no longer one big file. Now,
every object type has its own file. The database index is in place.
Authorization access is in place including additional options on
template mode, type selections, fastnraw, non-recursive, no RIPE-81++
syntacial sugar, etc. A short review followed on the Database
Working Group's current set of documents.
1. RIPE Database Authorization Aspects Report - Daniel Karrenberg
Daniel reported that notification and authorization is fully
operational. All current objects in the RIPE Database are valid.
The first item for objects is to put attributes in them that point
to maintainer object. Notifications are easier with this
maintainer object. The name must be unique, with the usual set of
contact persons. The object itself will be maintained by the RIPE
NCC, also. Notification will also happen if the object itself is
changed from time to time. Stronger authentication is in place.
Any update of this object must now be preceded by a line of the
form. Multiple authentication methods can be used in the same
maintainer object. The Routing Registry is the guardian of the
communities and therefore ASs are notified of any creation, update
or deletions of any "route" referencing them. The maintainer of
":all routes" notified of another instance of exactly the same
Cooper [Page 44]
Internet Monthly Report December 1994
(prefix/length) route has been added.
Connectivity Working Group Session - Milan Sterba
1. CEENET
A CEENET (Central East European Net) update was presented by Jan
Gunograd. CEENET started in 1991 in four countries: Czech
Republic/Solvakia, Poland, Hungary, and Romania. Its membership
now includes twelve countries. There will be a meeting in October
1994 for CEENET to talk about future financing. The key issue is
the financial support from the EC (European Community) and a call
for management of the project.
2. DFN/EUNET/DANTE Report - No technical activity has started up
yet.
Milan asked if there was an attendee who could provide the group a
DANTE report regarding their efforts in the Central European area.
There was not a representative available at this session.
However, there seems to be some evidence that DANTE is working on
an extension of a higher speed background for Central Europe and
also, for all of Europe.
3. Regional Updates Report
Milan asked the working group attendees if there were any major
changes or events since the last RIPE meeting in their respective
countries. He stated that he would especially like to know about
newly connected countries.
Bulgaria
No representative present to report.
Czech Republic
Jan reported that the link that was established for the INET
Conference in Prague last June is still in place. He hopes it
will stay until the CEENET October meeting in Budapest. No
more contract or details have been made. There is also a
128kps line in Vienna-Prague on the EBONE. The Czech Republic
connection has significantly improved sine the last RIPE
meeting.
Hungary
Some new cities have connected to IPnet internally in Hungary.
Other major cities will be connected in the next two months.
Four 64kps lines from Vienna's EBONE are connected to
interfaces on Europanet Bone. Hungary has asked for an upgrade
Cooper [Page 45]
Internet Monthly Report December 1994
to 256kps lines from the Vienna EBONE. It has been agreed that
two lines of the current four 64kps lines will be upgraded to
256kps. DANTE Europanet has also approved of this upgrade. It
has been confirmed that EBONE connectivity will be included in
the upgrade.
Baltic States
Estonia - 128kps line to Helsinki, 128kps line to Stockholm
Latvia - 65kps lines going to Helsinki and Germany
Lithuania - 64kps line to Oslo
The Baltnet program was established by the Scandinavians.
Capacity will double by this time next year.
Slovakia
Last April/May two lines were upgraded to 64kps from Prague.
One of the lines is covered by a new budget.
Russia
There are two lines available, one in Prague (64kps) and one in
Vienna. There is a Russia connection via a "radio-msu"
satellite/microwave based at Moscow State University. There
are other plans to connect additional sites in Moscow. These
are still under discussion, so there will not be just one line.
There was a question if any of the other Russian states will be
included, and the answer was yes, but it has not been fully
confirmed.
+------+ +---------+
| DESY | 256kps line | NPI/MSU |
| (GR) |----------------------| |
+------+ +---------+
|
|
| 64kps satellite
| (in operation since last
| Thursday)
|
|
|
| Armenia
|
Yerphl
Cooper [Page 46]
Internet Monthly Report December 1994
Rob presented the above diagram and led a discussion about the
currrent connectivity in Russia. He mentioned that initally,
there was was a problem with the power supply in Yerphl. The
power was 43 Hertz! Since its initial setup, Yerphl's power
has been upgraded. The Armenia Foundation funded the upgrade
and the line.
Rob reported on the new developments in the Moscow area. A new
proposal has just been announced that describes a Moscow
metropolitan network with a 2Mb line, with a 28kps line to
downtown Moscow. The idea is to connect the Science Institute
all together and to have external links. The termination point
will be Moscow State University, using the same satellite NSK.
Funding is being provided by the International Science
Foundation (ISF), the Soros Foundation and the Department of
Energy of the United States. A NASA/ESNET link will also be
included. These agreements are verbally in place, but it's
hard to write them down. Rob stressed that the point is as
long as the agreements work between all parties concerned, they
are okay. The last time around, there was a deadlock with
fiber optic connectivity. It is still deadlocked. There are
plans to install a 64kps line between Kiev and Potsdam.
Poland, Romania, and Slovania Reports
No representatives were present to report.
4. CDS Update - the Connectivity Document - Milan Sterba
Milan requested that the attendees send a CDS sheet describing
their network to <cds-editor at ripe.net>. He felt that they should
make their information known since they are information providers.
Milan said that up until now, there are very few entries. Entries
include Bulgaria, the Czech Repulbic, DANTE, France, Poland, and
Slovakia. Milan would like to see it more populated. There is a
need for additional submissions.
5. CEE Discussion
Discussion of the stagnation of CEE (Central East European)
networking.
Milan stated that he might be mistaken, but checked some figures.
Currently, he sees three groups of countries/classes:
1) Stable growth - most countries fit into this
(Ukraine, Russia, Slovenia, Romania, Lativa, Hungary)
Cooper [Page 47]
Internet Monthly Report December 1994
2) Astronomical growth - new countries with rapid growth
(Bulgaria, Lithuania)
3) Plateau growth - some networks reaching a plateau, not
"stagnation", per se
(Czech Republic, Poland, Slovakia)
The Future of the RIPE Connectivity Working Group
Milan requested feedback on the mission and future of this working
group. General consensus is that this group is still extremely
useful, even with the new RIPE program.
General Plenary
During the last day of the RIPE meetings, there was an announcement
of a new NCC Activity - Routing Registry Maintenance. Its intent is
to:
- encourage and support service provides to use the routing
registry
- actively find gaps in covers, courses, reports, etc.
- maintain PRIDE tools
- coordinate with other routing registries
- identify and propose needed extensions
Cooper [Page 48]
Internet Monthly Report December 1994
CALENDAR
--------
Last update 1/9/95
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 cnri.reston.va.us>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
FYI - New Dates for U.S. APPC/APPN (AATC) Technical Conf. moved from
July to May 1995.
- New Dates for ULPAA 1995, was Dec. 4-8, 1995 NOW Dec. 11-15, 1995
************************************************************************
1995
---------
Jan. 8-11 BROADBAND '95 Workshop Tucson, AZ
Jan. 16-20 USENIX New Orleans, LA
Feb. 5-10 ATM Forum San Francisco, CA
Feb. 5-11 IS&T/SPIE Symposium on
Electronic Imaging San Jose, CA
Feb. 6-10 ANSI X3T11 St. Petersburg Bch, FL
Feb. 16-17 ISOC Symposium on Ntwk &
Distribruted System Security San Diego, CA
Feb. 20 Int'l Internet OGs Meetings San Diego
Feb. 20-24 UniForum Dallas CC, Dallas, TX
Feb. 21-22 Int'l Internet Ops Conference San Diego
Feb. 22-24 ICODP '95 Brisbane
Feb. 26-Mar. 3 SHARE (IBM) Los Angeles, CA
Mar. 6-10 IEEE 802 Plenary (Firm) West Palm Beach, FL
Mar. 6-10 SNMP Test Summit III
Mar. 13-17 OIW (Firm)
Mar. 13-24 ISO/IEC JTC1/SC6 Tokyo, JP
Mar. 16-19 3rd Intntl Telecom. Systems
Modelling & Analysis Nashville, TN
Mar. 27-31 NetWorld+Interop Las Vegas, NV
Mar. 28-31 Seybold Seminars Boston, MA
Apr. 2-6 IEEE Infocom '95 Boston, MA
Apr. 3-7 ANSI X3T11 Monterey, CA
Apr. 3-7 32nd IETF (Definite) Danvers, MA
Apr. 4-5 Federal Networking Council
Cooper [Page 49]
Internet Monthly Report December 1994
Advisory Committee Arlington, VA
Apr. 9-14 ATM Forum Denver, CO
Apr. 17-21 Email World (Firm) Santa Clara, CA
Apr. 19-21 5th Network & Operating System
Support (NOSSADV) Workshop Boston, MA
Apr. 24-25 IFIP TC6 Wkshp Personal
Wireless Commun. Prague, Czech Republic
May 1-5 Fourth IFIP/IEEE Intl Symp.
on Integrated Ntwk Mgt ISINM95 Santa Barbara, CA
May 15-19 Joint European Ntwkg Conf. Tel Aviv, Israel
May 18-19 RARE Council of Admin. Tel Aviv, Israel
May 22-25 APPC/APPN Tech. Conf. (AATC) Chicago, IL
May 28-Jun. 2 NetWorld+Interop '95 Frankfurt, Germany
Jun. ATM Forum Europe
Jun. 5-7 Digital World Los Angeles, CA
Jun. 5-9 ANSI X3T11 Rochester, MN
Jun. 12-16 OIW (Firm)
Jun. 13-16 IFIP WG6.1 PSTV-XV Warsaw
Jun. 16-17 CCIRN Singapore
Jun. 18-22 ICC '95 Seattle, WA
Jun. 18-24 ISOC Developing Country Wkshp Hawaii
Jun. 25-27 ISOC K-12 Workshop Hawaii
Jun. 26-27 ISOC Trustees & Council Hawaii
Jun. 28-30 INET '95 Hawaii
Jul. 4 Independence Day
Jul. 10-13 IEEE 802 Plenary (Firm) Maui, HI
JULY 14 BASTILLE DAY
Jul. 17-21 33rd IETF Stockholm, Sweden
Jul. 17-21 NetWorld+Interop Tokyo, Japan
Jul. 17-Aug. 3 ISO/IEC JTC 1/SC 21 Ottawa, Ontario
Aug. 6-11 ATM Forum Toronto, CA
Aug. 7-11 ANSI X3T11 (Tentative) Denver area
Aug. 14-18 ANSI X3T11 (Tentative) Denver area
Aug. 29-Sep. 1 Windows Solutions San Fran. San Francisco, CA
Aug. 30-Sep. 1 ACM SIGCOMM '95 Cambridge, MA
SEPTEMBER Windows Solutions Paris Paris, France
Sep. 25-29 7th SDL Forum Oslo, Sweden
FALL 1995 Seybold Europe
Sep. 4-6 8th IFIP WG6.1 Intntl Wkshp on
Protocol Test Systems Every, France
Sep. 4-7 APPC/APPN Tech. Conf. (AATC) London, England
Sep. 11-15 6th IFIP High Performance Palma de Mallorco,
Networking, HPN'95 SPAIN
Sep. 11-15 OIW (Firm)
Sep. 25-29 NetWorld+Interop Atlanta, GA
Sep. 26-29 Seybold San Francisco San Francisco, CA
Oct. 1-6 ATM Forum Honolulu, HI
Oct. 2-6 ANSI X3T11 Toronto, Ontario, CA
Cooper [Page 50]
Internet Monthly Report December 1994
Oct. 3-11 Telecom '95 Geneva, Switzerland
Oct. 10-11 ANSI X3T11
Oct. 16-19 APPC/APPN Tech. Conf. (AATC) Sydney, Australia
Oct. 17-20 IFIP WG6.1 FORTE '95 Montreal, Quebec
Nov. 6-9 IEEE 802 Plenary (Firm) Montreal, Quebec
Nov. 6-10 NetWorld+Interop Paris, France
Nov. 7-10 ICNP '95 Tokyo, Japan
Nov. 13-17 GLOBECOM '95 Singapore
Nov. 27-Dec. 1 Email World (Definite) Boston, MA
Nov. 27-Dec. 1 Windows Solutions Germany Frankfurt, Germany
Dec. 3-6 ACM SIGOPS
Dec. 4-8 OIW (Firm)
Dec. 4-8 34th IETF Dallas, TX
Dec. 4-8 ANSI X3T11 (Possible) San Diego, CA
Dec. 4-8 Supercomputing '95 (Firm) San Diego, CA
Dec. 4-8 Windows Solutions Tokyo Tokyo, Japan
Dec. 4-8 X/Open Security
Dec. 10-15 ATM Forum Orlando, FL
Dec. 11-15 11th Comp. Sec. Applications New Orleans, LO
Dec. 11-15 ULPAA (upper layers) Sydney, AU
1996
-----------
Feb. 5-9 ANSI X3T11
Mar. 11-14 UniForum San Francisco, CA
Mar. 11-15 35th IETF (Under Consideration)
Mar. 18-22 35th IETF (Under Consideration)
Mar. 18-22 OIW (Firm)
Apr. 8-13 ANSI X3T11 (Tentative) Irvine, CA
Apr. 15-19 ANSI X3T11 (Tentative) Irvine, CA
May. 13-29 ISO/IEC JTC 1/SC 21
WGs and Plenary (Firm) Kansas City, MO
Jun. 10-14 OIW (Firm)
Jun. 10-14 ANSI X3T11
Jun. 24-27 ICC '96 Dallas, TX
Jul. 8-12 36th IETF (Under Consideration)
Jul. 22-26 36th IETF (Under Consideration)
Jul. 29-Aug. 2 36th IETF (Under Consideration)
Aug. 5-9 ANSI X3T11
Sep. 2-6 14th IFIP Conf. Canberra, AU
Sep. 9-13 OIW (Firm)
Sep. 24-27 IFIP WG6.1 w/FORTE/PSTV (Under Consideration)
Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL
Nov. 11-15 37th IETF (Under Consideration)
Nov. 18-22 37th IETF (Under Consideration)
Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA
Dec. 2-6 ANSI X3T11
Cooper [Page 51]
Internet Monthly Report December 1994
Dec. 9-13 OIW (Firm)
1997
-----------
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Jun. 8-12 ICC '97 Montreal
Jun. 9-13 OIW (Firm)
Sep. 8-12 OIW (Firm)
Dec. 8-12 OIW (Firm)
1998
-----------
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
---------
Via ftp: /ietf/1events.calendar.imr.txt on ietf shadow directories
Via gopher: "Internet Engineering Task Force (IETF) / IETF Meetings /
Scheduling Calendar" on ietf.cnri.reston.va.us
**********************************************************************
Cooper [Page 52]
Internet Monthly Report December 1994
TERENA CALENDAR
Ref. TSec(95)001 January 1995
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 Executive Committee
--------------------------
TERENA General Assembly
-----------------------
GA3
18/19 May Tel Aviv
TERENA Working Groups
---------------------
STAMPEDE Meeting
11 January London
JENC6 Programme Committee
-------------------------
12-13 January Tel Aviv
European Commission
Workshop
-------------------
16 February Brussels
RIPE
----
25-27 January Amsterdam (NIKHEF, WCW)
12-14 April Berlin
PRIDE COURSES
-------------
Cooper [Page 53]
Internet Monthly Report December 1994
VARIOUS
-------
DANTE BoD
---------
9 January Munich
EUROPEAN OPERATORS FORUM
25 January Amsterdam
EBONE
Consortium of Contributing Organisations
26 April TBD
EBONE Management Committee
26 January Amsterdam
EOT (Ebone Operations Team)
28 March TBD
CCIRN
16/17 June Singapore
IETF
3-7 April Danvers, Massachusetts
17-21 July Stockholm, Sweden
4-8 December Dallas Texas, USA
EWOS
----
Technical Assembly
28/2-1/3 Brussels
16/17 May Brussels
19/20 September Brussels
12/13 December Brussels
Steering Committee
14 March Brussels
6 June Brussels
26 September Brussels
19 December Brussels
Cooper [Page 54]
Internet Monthly Report December 1994
ETSI
----
General Assembly
30/31 March Nice, France
5/6 December Nice, France
Technical Assembly
27-29 March Nice, France
7-9 November Nice, France
CONFERENCES
*******************************************************************
JENC6 - 6th Joint European Networking Conference
15-18 May 1995 in Tel Aviv, Israel
To be added to the conference email distribution list, send a message
to <jenc6-request at rare.nl>.
For information, email <jenc6-sec at rare.nl>.
To submit a paper, email <jenc6-submit at rare.nl>
NETWORK SERVICES CONFERENCE 95
Autumn 1995 (tbc)
JENC7 - 7th Joint European Networking Conference
13-16 May 1996 in Budapest, Hungary
*******************************************************************
OTHER CONFERENCES
nb. For some of the following events, full text information is
available from the TERENA Document Store under the directory calendar,
in which case the file name is specified under the information
presented below. The files may be retrieved via:
anonymous FTP: ftp.terena.nl
Email: server at terena.nl
Gopher: gopher.terena.nl
Cooper [Page 55]
Internet Monthly Report December 1994
MASCOT95 Advance Program
International Workshop on:
Modeling, Analysis and Simulation of Computer
and Telecommunications Systems
---------------------------------------------
18-20 January
Omni Durham Hotel & Durham Civic Center
Durham, North Carloina, USA
for registration and info., <mak at ee.duke.edu>
IS&T/SPIE SYMPOSIUM ON ELECTRONIC IMAGING
-----------------------------------------
from 5-11 February
San Jose Convention Center, San Jose, California USA
-> Multimedia Computing and Networking 1995
-> Digital Video Compression: Algorithms & Technologies 1995
Tel.(206)676 3290 - Fax.(206)647 1445
MULTIMEDIA COMPUTING & NETWORKING
---------------------------------
from 6-8 February
San Jose Convention Center, San Jose, California USA
for registration and info, email <spie at spie.org>
DIGITAL VIDEO COMPRESSION: ALGORITHMS & TECHNOLOGIES
----------------------------------------------------
from 7-10 February
San Jose Convention Center, San Jose, California USA
for registration and info, email <spie at spie.org>
TEDIS - EDITT / EDI TRUSTED THIRD PARTIES WORKSHOP
--------------------------------------------------
from 8-10 February
(tutorials on 7 February)
University Polytechnics Catalunya, Barcelona, Spain
Subjects: certification and registration, legal and audit
aspects of EDI.
Sponsor: the Commission of the European Union
(TEDIS Programme)
Programme Committee Chairman: Manuel Medina
email <medina at ac.upc.es>
Cooper [Page 56]
Internet Monthly Report December 1994
EEMA
Integrating the Air Transport Industry through Messaging
--------------------------------------------------------
14-16 February
Cavalieri Hilton, Rome, Italy
registration and info., <eemaoffice at attmail.com>
tel: +44 386 793 028. fax: +44 386 793 268
INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED
SYSTEM SECURITY
-----------------------------------------------------
16-17 February
Catamaran Hotel, San Diego, California USA
Deadline for submission of papers is 15 August 1994.
For further information, email David Balenson
<balenson at tis.com>
JANET WORKSHOP 23
-----------------
from 28-30 March
at the University of Leicester in England
Deadline for proposals 13 January
Deadline for abstracts + authors' biography 17 February.
Email <N.Shield at ukerna.ac.uk>
FIRST AUSTRALIAN WWW CONFERENCE / AusWeb95
------------------------------------------
from 29 April - 2 May
Ballina Beach Resort, Ballina, Far North Coast of
New South Wales, Australia
Abstracts for full papers due on 23 January
Registration http://www.scu.edu.au/ausweb95/
For further information, email <AusWeb95 at scu.edu.au>
THIRD ANNUAL RURAL DATAFICATION CONFERENCE
------------------------------------------
22-24 May
Indianapolis, Indiana, USA
(supported by a grant from the National Science
Foundation)
Deadline for submission of papers is 15 January .
Submit to <ruraldata-submit at cic.net>
Cooper [Page 57]
Internet Monthly Report December 1994
INET 95
-------
28-30 June
in Honolulu, Hawaii
Extended abstracts for papers to be submitted by
13 January to <inet-submission at interop.com>
Programme Committee <inet-program at interop.com>
Internet Society Secretariat <inet95 at isoc.org>
1995 INTERNET SOCIETY WORKSHOP ON NETWORK
TECHNOLOGY FOR DEVELOPING COUNTRIES
-----------------------------------------
18-24 June
Manoa Campus, University of Hawaii, Honolulu
Apply preferably before 15 January .
Further information from <workshop-info at isoc.org>
or contact George Sadowksy <George.Sadowsky at nyu.edu>
Tel.+1 212 998 3040, fax.+1 212 995 4120.
95 FIRST Conference/Workshop
----------------------------
The Forum of Incident Handling and Security Teams (FIRST)
will hold its annual conference from:
18-22 September
University of Karlsruhe, Karlsruhe, Germany
Abstracts due by 1 April
For info. contact Christoph Fischer <fischer at rz.uni-karlsruhe.de>
tel: +49 721 37 64 22 fax: +49 721 32 550
1995 IFIP International Working Conference
on User Layer Protocols, Architectures and Applications (ULPAA)
---------------------------------------------------------------
11-15 December
in Sydney, Australia
Deadline for submission of papers by 15 May
For further info-> http:/www.ee.uts.edu.au/ifip/ULPAA95.html
INTERNATIONAL ZURICH SEMINAR ON DIGITAL COMMUNICATIONS 1996
-----------------------------------------------------------
Broadband Communiations: Networks, Services, Applications,
Future Directions
19-23 February 1996
Swiss Institute of Technology (ETH), Zurich, Switzerland
Deadline for submission of papers is 15 May 1995
For further information, email Prof. Dr. Bernhard Plattner
Cooper [Page 58]
Internet Monthly Report December 1994
<izs96-pc-chair at tik.ethz.ch>, fax.+41 1 632 1035
Call for Papers on TERENA Document Server under
rare/information/calendar. The file is called izs96-cfp.txt.
==================
updated
06.01.1995
==================
Madeleine Oberholzer
TERENA Secretary
Trans-European Research and Education Networking Association
TERENA - Established by merger of RARE and EARN
TERENA Secretariat
Singel 466 - 468
NL - 1017 AW AMSTERDAM
Voice : + 31 20 639 11 31
Fax : + 31 20 639 32 89
Email : secretariat at terena.nl - for general matters
bookkeeping at terena.nl - for financial matters
Cooper [Page 59]
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa06189;
12 Jan 95 15:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13445;
12 Jan 95 15:06 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06109;
12 Jan 95 15:06 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa05881;
12 Jan 95 14:56 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa13156;
12 Jan 95 14:56 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA13433>; Thu, 12 Jan 1995 11:56:47 -0800
Message-Id: <199501121956.AA13433 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: IETF-Announce: ;, cooper at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: Internet Monthly Report Availability via FTP and Email
Reply-To: cooper at isi.edu
Date: Thu, 12 Jan 95 11:56:47 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
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.
IMR Retrieval using WWW
-----------------------
The URL below may be used in MOSAIC or other WWW browsers to access
the IMRs. You will see a list of names in the form IMR9407.TXT. For
example, IMR9407.TXT is the report for July 1994.
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 VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at cnri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the IMRs.
--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: imr9412
--OtherAccess
Content-Type: Message/External-body;
name="imr9412.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10303;
12 Jan 95 20:09 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa10297;
12 Jan 95 20:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19682;
12 Jan 95 20:09 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10269;
12 Jan 95 20:09 EST
Received: from [132.151.1.1] by IETF.CNRI.Reston.VA.US id aa10222;
12 Jan 95 20:06 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa19637;
12 Jan 95 20:06 EST
Received: from relay4.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA07603>; Thu, 12 Jan 1995 17:06:21 -0800
Received: from InterServ.Com by relay4.UU.NET with SMTP
id QQxyky23954; Thu, 12 Jan 1995 20:06:19 -0500
Received: from geordi.interserv.net by InterServ.Com (4.1/SMI-4.1)
id AA07989; Thu, 12 Jan 95 17:03:14 PST
Received: from data.interserv.net by geordi.interserv.net (4.1/SMI-4.1)
id AA00464; Thu, 12 Jan 95 17:04:34 PST
Received: by data.interserv.net (4.1/SMI-4.1)
id AA15117; Thu, 12 Jan 95 17:05:03 PST
To: info-ietf at relay1.uu.net
Path: news.interserv.net!not-for-mail
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: news at data.interserv.net
Newsgroups: info.ietf
Subject: <subject>
Date: 12 Jan 1995 17:05:02 -0800
Organization: NovX InterServ News Service
Lines: 45
X-Orig-Sender: root at data.interserv.net
Distribution: local
Message-Id: <3f4jju$eo9 at data.interserv.net>
Reply-To: noc at interserv.com
To: All users of this server.
From: The InterServ Staff
Subj: NEWS SERVER CHANGES!
NOTE: THIS POSTING IS BEING SENT TO USERS OF THIS NEWS SERVER. IT WILL
NOT BE PROPOGATED TO OTHER SERVERS IN THE USENET COMMUNITY. PLEASE DO NOT
POST REFERENCE MESSAGES OR "FOLLOWUPS" TO THIS MESSAGE. INSTEAD, EMAIL
YOUR RESPONSES TO THE ADDRESS LISTED BELOW. THANK YOU.
If you are a member of InterServ or have purchased SPRY's Air Series
software, you might spend considerable time on this news server. Because
of that, we at InterServ have made every effort to bring you the finest
NNTP news service possible. For 18 months, InterServ and Spry have
provided you access to over 6000 english-language news groups, 24 hours a
day, every day of the year.
Until recently, we have made news feeds from Clarinet Communications
available to InterServ members and registered Spry customers. In
addition, we have made almost all other news groups available to the
Internet community at large, as a public service. Unfortunately, times
change and so must we.
Because we have not yet been able to negotiate reasonable bulk pricing
terms with Clarinet Communications, we have been forced to cancel these
feeds until further notice. Effective immediately, you will no longer
find articles in the CLARI hierarchy on this server.
Also, because our public access policy has begun to impact the performance
perceived by InterServ members and Spry customers, we must begin
restricting access to most groups on this server in mid-January.
We hope to bring the AP, UPI and Reuters news feeds back to this server as
soon as possible. And of course, we'll continue to provide our members
and customers with every english-language distributed USENet news feed we
can find, in an uncensored and timely fashion.
If you would like to become a NovX/InterServ member, please telephone us
at 800-FOR-NOVX. Spry customers have access as well. To purchase Spry's
Internet In A Box, Mosaic In A Box, or Air Series software, phone
800-SPRY-NET. To contact our Network Operations Center (NOC), email us
at noc at interserv.net.
Thank you.
-The InterServ Staff
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01511;
13 Jan 95 7:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01505;
13 Jan 95 7:47 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03794;
13 Jan 95 7:47 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01492;
13 Jan 95 7:47 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01389;
13 Jan 95 7:32 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa03596; 13 Jan 95 7:32 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-18.dialip.mich.net [141.211.7.154]) by merit.edu (8.6.9/merit-2.0) with SMTP id HAA10131 for <ietf at cnri.reston.va.us>; Fri, 13 Jan 1995 07:32:50 -0500
Date: Fri, 13 Jan 95 11:57:34 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3703.bill.simpson at um.cc.umich.edu>
To: cooper at isi.edu
Cc: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: Internet Monthly Report
I enjoyed the IMR this month. Lots of interesting news from Europe.
Since the IEPG didn't "take off", and seems to be replaced by the "EOF",
it's time for the IAB to re-consider an IOTF for us all.
Next time, could you get rid of the duplicate RFC information?
In the ISI report, something like, "53 RFCs were published. The
complete list is in the Internet Engineering report above" would be
appropriate.
I note that the self-serving NSFnet statistics are gone this month.
I was looking forward to the explanation of the link to DC that was
repeatedly down for hours at a time.
And the NSFnet traffic was down 12%. Never saw that happen before! No
wonder throughput has noticably improved the past few weeks!
I didn't see any announcement about the AN_S purchase by AOL/Time-Warner.
(And exactly how does one purchase a non-profit???)
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01697;
13 Jan 95 8:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01691;
13 Jan 95 8:13 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04183;
13 Jan 95 8:13 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01680;
13 Jan 95 8:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01637;
13 Jan 95 8:10 EST
Received: from ecrc.de by CNRI.Reston.VA.US id aa04146; 13 Jan 95 8:10 EST
Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA08785
( for <ietf at cnri.reston.va.us>); Fri, 13 Jan 1995 14:10:25 +0100
Received: from acrab25.ecrc.de by scorpio.ecrc.de (4.1/SMI-3.2)
id AA09032; Fri, 13 Jan 95 14:10:24 +0100
Date: Fri, 13 Jan 95 14:10:24 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Morton <Dave.Morton at ecrc.de>
Message-Id: <9501131310.AA09032 at scorpio.ecrc.de>
To: cooper at isi.edu, jkrey at isi.edu
Subject: Re: Internet Monthly Report - December 1994
Cc: ecco-l at ebone.net, emc-l at ebone.net, eot at ebone.net, ietf at CNRI.Reston.VA.US
> 5. European Operators Forum (EOF)
>
> Rob stated that RIPE's Network Operations working group was
> discontinued after EBONE came to life. The EBONE Action Team did
> not survive the latest EBONE restructuring. The European IEPG
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Joyce et. al.
There must be some major misunderstanding here. Let me try to explain.
Originally within EBONE there used to be both an EAT (EBONE Action Team)
and an EOT (EBONE Operations Team).
After some EBONE members left to join Europanet/EMBP, EBONE continued to
operate as usual and still does. Other members have also since joined.
The members of both teams met jointly and decided that there was no longer
any real need to have two teams as in the early hectic establishment days
of EBONE and thus both groups joined to become the EOT.
The EOT and it's members are alive and kicking all over Europe and, in fact,
recently held a meeting here at ECRC in Munich, at which circa 25 of the
member networks of EBONE were present, to coordinate the further activities
within EBONE.
The EOF exists because it was recognised that we now have many providers
within Europe besides simply EBONE and that a forum to discuss relevant
issues at that operator level was needed. Note: EUnet and Dante also were
EBONE contributors previously. This is no longer the case. Naturally,
individual members of EBONE also participate in the EOF but this of course
is not directly within the scope of operational matters within EBONE as such.
EBONE also participates in the EOF.
Just thought I'd clarify this for all. Yes - some things are complicated -
sigh.
Best regards,
Dave Morton,
Leader, Network Engineering,
European Computer Research Centre, Tel. + (49) 89-92699-139
Arabellastr 17, 81925 Munich, Fax. + (49) 89-92699-170
Germany. GSM. + (49) 171 22 68 202
E-mail: Dave.Morton at ecrc.de
> (Internet Engingeerig Planning Group) did not take off earlier
> this year as planned. A new forum was created for network
> operations, which focussed on common engineering and operations.
> The acting chair is Peter Lothberg. What do they do? What are
> they planning? This group is not a Pan-European organization. It
>
>
>
>Cooper [Page 41]
>
>Internet Monthly Report December 1994
>
>
> has agreed to work with RIPE.
>
> Peter gave a presentation on EOF. EOF is to be a forum focussed
> on the daily operation and coordination running of IP networks in
> Europe. If all goes well, it can expand on a global scope. The
> first EOF meeting was in Amsterdam. The second meeting was in
> Paris. The third meeting was held before the RIPE meeting in
> Lisbon, with 32 attendees. EOF has started discussing
> interconnection agreements, defining strawman proposals on how new
> people can connect, change points, routing problems, CIDR issues,
> and mae-east++ (or upgrade). The primary focus of this group is
> to keep IP Europe communicating with each other. Their mailing
> list is eware-list at ripe.net. The Lisbon EOF meeting agenda
> included traffic and routing exchange arrangements between network
> service providers, CIDR routes, how to do routing over exchange
> points without causing global problems, and development of an EOF
> charter as a RIPE oriented working group. The next EOF meeting
> will be in November in the UK.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02145;
13 Jan 95 9:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02139;
13 Jan 95 9:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05454;
13 Jan 95 9:19 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02128;
13 Jan 95 9:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02101;
13 Jan 95 9:17 EST
Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa05409; 13 Jan 95 9:17 EST
Received: by rodan.UU.NET
id QQxymz13884; Fri, 13 Jan 1995 09:17:15 -0500
Date: Fri, 13 Jan 1995 09:17:15 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike O'Dell <mo at uunet.uu.net>
Message-Id: <QQxymz13884.199501131417 at rodan.UU.NET>
To: ietf at CNRI.Reston.VA.US
Subject: IEPG.......
Methinks Mr. Simpson's pronouncement that the IEPG "didn't take off"
is both a touch presumptuous and very wrong.
The IEPG meets regularly in person and exchanges considerable email.
A lot of coordination and important discussion *does* happen.
While Mr. Simpson may be a respected member of the protocol development
community, I fear his experience with daily network operations is
possibly inadequate for judging the value and efficacy of organizations
like the IPEG, NANOG, and the EOF, all of which have a place and provide
distinct value to the participants.
While everyone involved in large-scale Internet Operations wishes
things worked better and more smoothly, it is not at all obvious that
"more cooks" "helping the operators" is the right solution. That is
why the participants in groups like the IEPG, NANOG, EOF, and others
are using these venues to improve coordination and problem resolution.
Yours for better packets,
-Mike O'Dell
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02804;
13 Jan 95 10:04 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02800;
13 Jan 95 10:04 EST
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa06662;
13 Jan 95 10:04 EST
Received: from sdiv.cray.com (daemon at ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id IAA23231; Fri, 13 Jan 1995 08:13:38 -0600
Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA18179; Fri, 13 Jan 1995 08:13:32 -0600
Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA18147; Fri, 13 Jan 1995 08:13:24 -0600
Received: from mail.unigate1.unisys.com (mail.UniGate1.Unisys.COM [192.63.100.18]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id IAA23214 for <telnet-ietf at cray.com>; Fri, 13 Jan 1995 08:13:21 -0600
Received: from rsvl.unisys.com ([192.61.220.100]) by mail.unigate1.unisys.com (4.1/SMI-4.1-1.1)
id AA01741; Fri, 13 Jan 95 14:10:43 GMT
Received: from unirsvl.rsvl.unisys.com by rsvl.unisys.com (4.1/SMI-4.1)
id AA26281; Fri, 13 Jan 95 08:08:11 CST
Received: by unirsvl.rsvl.unisys.com (4.1/SMI-4.1)
id AA11903; Fri, 13 Jan 95 08:19:39 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Connie Ahrens <cha at unirsvl.rsvl.unisys.com>
Message-Id: <9501131419.AA11903 at unirsvl.rsvl.unisys.com>
Subject: auth v5
To: telnet-ietf at cray.com
Date: Fri, 13 Jan 95 8:19:39 CST
Cc: stevea at lachman.com
X-Mailer: ELM [version 2.3 PL8]
Content-Length: 257
What is the current status of draft-ietf-authker-v5? Is this
version still being worked? Are there implementations that use
version 4 in RFC 1411? Do most venders use only RFC 1416?
Thanks for any info.
Connie Ahrens
cha at unirsvl.rsvl.unisys.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04770;
13 Jan 95 12:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09553;
13 Jan 95 12:10 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04739;
13 Jan 95 12:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04556;
13 Jan 95 11:58 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09289;
13 Jan 95 11:58 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04550;
13 Jan 95 11:58 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: rmonmib at cs.hmc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Remote Network Monitoring Management Information
Base to Draft Standard
Date: Fri, 13 Jan 95 11:58:24 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501131158.aa04550 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Remote Network Monitoring
Management Information Base" <draft-ietf-rmonmib-rmonmib-03.txt> as a
Draft Standard. This document is the product of the Remote Network
Monitoring Working Group. The IESG contact person is Marshall Rose.
Technical Summary
This memo is an update to RFC 1271, the Remote Network Monitoring
MIB.
Working Group Summary
After much discussion, the WG reached consensus on all issues.
Protocol Quality
RFC 1271 is widely-implemented. The MIB module has been reviwed by
the NM-D.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05407;
13 Jan 95 12:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10280;
13 Jan 95 12:36 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05390;
13 Jan 95 12:36 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05286;
13 Jan 95 12:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10179;
13 Jan 95 12:33 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05280;
13 Jan 95 12:33 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ip-atm at hpl.hp.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: ATM Signaling Support for IP over ATM to Proposed
Standard
Date: Fri, 13 Jan 95 12:33:22 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501131233.aa05280 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "ATM Signaling Support for IP
over ATM" <draft-ietf-ipatm-sig-02.txt> as a Proposed Standard. This
document is the product of the IP Over Asynchronous Transfer Mode
Working Group. The IESG contact persons are Stev Knowles and Claudio
Topolcic.
Technical Summary
This specification provides for a standard way to provide the
signaling support necessary to run IP, as defined in RFC 1577
("Classical IP over ATM"), over a diverse ATM network.
Working Group Summary
This document has existed in the WG for a considerable time waiting
for the ATM Forum to publish the required base signaling
specification. There is an older version of this draft being
published as Informational concerning running RFC 1577 IP over an
older version of the signaling standard.
Protocol Quality
This document was reviewed by Stev Knowles, one of the Internet Area
Directors, for the IESG.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06043;
13 Jan 95 13:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11431;
13 Jan 95 13:40 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06017;
13 Jan 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05961;
13 Jan 95 13:36 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11327;
13 Jan 95 13:36 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05955;
13 Jan 95 13:36 EST
To: IETF-Announce: ;
Subject: WG ACTION:
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG <iesg-secretary at CNRI.Reston.VA.US>
Date: Fri, 13 Jan 95 13:36:29 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501131336.aa05955 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Applications Area of the
IETF. For more information, please contact the working group chairs of
the Area Directors.
Standard Generalized Markup Language (mimesgml)
-----------------------------------------------
Charter
Current status: active working group
Chair(s):
Ed Levinson <elevinson at fv.com>
Paul Grosso <paul at arbortext.com>
Applications Area Director(s):
John Klensin <Klensin at mail1.reston.mci.net>
Erik Huizer <Erik.Huizer at SURFnet.nl>
Area Advisor
John Klensin <Klensin at mail1.reston.mci.net>
Mailing lists:
General Discussion:sgml-internet at ebt.com
To Subscribe: majordomo at ebt.com
In Body: body: subscribe sgml-internet your-name
Archive: ftp://ftp.naggum.no:/pub/sgml-internet
Description of Working Group:
The Standard Generalized Markup Language (SGML) community is actively
addressing certain issues that relate to interoperability but not those
directly related to electronic mail.
This working group will address email issues and concerns to directly
support the exchange of SGML in MIME email. These issues include the
structure of MIME document that will contain both SGML document markup
and the various definitions, including handling of public and private
identifiers.
The WG's effort is NOT intended to address the syntax and structure of
SGML. Previous work in this area, ISO 9069, SGML Document Interchange
Format (SDIF) and SGML Open Technical Resolution 9401 will be addressed
as interface requirements that may be supported through email.
Goals and Milestones:
Dec 94 Establish IETF Working Group
Feb 95 Internet Draft available
Mar 95 Review draft in SGML Open Technical Committee meetings
Apr 95 Issue second draft following IETF meeting. Conduct WG review for
submitting to IESG.
May 95 Submit Internet Draft to IESG for consideration as a Proposed
Standard.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07561;
13 Jan 95 15:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13762;
13 Jan 95 15:15 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07521;
13 Jan 95 15:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07399;
13 Jan 95 15:11 EST
Received: from [128.9.160.160] by CNRI.Reston.VA.US id aa13474;
13 Jan 95 15:07 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA27864>; Fri, 13 Jan 1995 12:07:03 -0800
Message-Id: <199501132007.AA27864 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1752 on Recommendation for IPng
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 13 Jan 95 12:08:05 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1752:
Title: The Recommendation for the IP Next Generation
Protocol
Author: S. Bradner & A. Mankin
Date: January 1995
Mailbox: sob at harvard.edu, mankin at isi.edu
Pages: 52
Characters: 127,784
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1752.txt
This document presents the recommendation of the IPng Area Directors
on what should be used to replace the current version of the Internet
Protocol. This recommendation was accepted by the Internet
Engineering Steering Group (IESG). This RFC is the product of the
IPng Area 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-REQUEST at NIC.DDN.MIL.
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: <950113120223.RFC at ISI.EDU>
SEND /rfc/rfc1752.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1752.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950113120223.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05082;
13 Jan 95 12:23 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09885;
13 Jan 95 12:23 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05063;
13 Jan 95 12:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04947;
13 Jan 95 12:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09757;
13 Jan 95 12:19 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04940;
13 Jan 95 12:19 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: pmi at hpbs907.boi.hp.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Printer MIB to Proposed Standard
Date: Fri, 13 Jan 95 12:17:28 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501131219.aa04940 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Printer MIB"
<draft-ietf-printmib-printer-mib-04.txt> as a Proposed Standard. This
document is the product of the Printer MIB Working Group. The IESG
contact person is Marshall T. Rose.
Technical Summary
This memo defines managed objects for printing devices.
Working Group Summary
All issues of contention were resolved in the working group.
Protocol Quality
The NM-D and NM-AD have reviewed the memo.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14066;
16 Jan 95 0:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14059;
16 Jan 95 0:30 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16152;
16 Jan 95 0:30 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14044;
16 Jan 95 0:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13971;
16 Jan 95 0:22 EST
Received: from nic.near.net by CNRI.Reston.VA.US id aa15998; 16 Jan 95 0:22 EST
Received: from jcurran-ppp.near.net by nic.near.net id aa01568;
16 Jan 95 0:22 EST
X-Sender: jcurran at nic.near.net
Message-Id: <v0211011cab3fb19ce64e at [192.52.71.147]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 16 Jan 1995 00:22:45 -0500
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Curran <jcurran at nic.near.net>
Subject: 1995 Request for IAB/IESG Candidates
Cc: nomcom at nic.near.net
Hello Folks,
The 1995 Nominations Committee, while off to a slow start, is now up
and ready to work on all of your nominations for IAB and IESG positions.
As always, half of the current positions have become available, and we
now require your assistance in determine the best candidates for these
positions.
The following positions are up for consideration at the present time:
o IESG Operations AD (Area Director)
o IESG Transport AD
o IESG Applications AD (Both AD's open)
o IESG Network Management AD
o IESG Internet AD
o IAB Member
o IAB Member
o IAB Member
o IAB Member
o IAB Member
o IAB Member
If you know someone who would serve well in one of the above positions,
or if you yourself would like to be considered for such a position, please
send a email message indicating such to the nominating committee indicating
the specific candidate and position.
Thanks!
/John
p.s. Anyone who is currently up for renewal who would like to be considered
for another term should drop us a message unless you've already received
email confirmation that we're aware of your interest...
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01940;
16 Jan 95 9:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01934;
16 Jan 95 9:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17263;
16 Jan 95 9:31 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01900;
16 Jan 95 9:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01756;
16 Jan 95 9:16 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa12457; 16 Jan 95 9:16 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm012-27.dialip.mich.net [141.211.7.195]) by merit.edu (8.6.9/merit-2.0) with SMTP id JAA07267 for <ietf at cnri.reston.va.us>; Mon, 16 Jan 1995 09:16:16 -0500
Date: Fri, 13 Jan 95 18:46:33 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3746.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: IEPG.......
> Methinks Mr. Simpson's pronouncement that the IEPG "didn't take off"
> is both a touch presumptuous and very wrong.
>
Hey, Mike, I'm just quoting the December IMR (please read before you
criticize):
5. European Operators Forum (EOF)
Rob stated that RIPE's Network Operations working group was
discontinued after EBONE came to life. The EBONE Action Team did
not survive the latest EBONE restructuring. The European IEPG
(Internet Engingeerig Planning Group) did not take off earlier
this year as planned. A new forum was created for network
operations, which focussed on common engineering and operations.
The acting chair is Peter Lothberg. What do they do? What are
they planning? This group is not a Pan-European organization. It
Cooper [Page 41]
> While Mr. Simpson may be a respected member of the protocol development
> community, I fear his experience with daily network operations is
> possibly inadequate for judging the value and efficacy of organizations
> like the IPEG, NANOG, and the EOF, all of which have a place and provide
> distinct value to the participants.
>
You are absolutely correct. I'm merely responding to information that
the IEPG (which was the selected choice for a non-ISoc affiliated
global operator's forum after much debate last year) had devolved into a
European-only group.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04399;
16 Jan 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04393;
16 Jan 95 13:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02109;
16 Jan 95 13:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04360;
16 Jan 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03662;
16 Jan 95 12:30 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa00468;
16 Jan 95 12:30 EST
Received: by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA00506>; Mon, 16 Jan 1995 09:30:17 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Manning <bmanning at isi.edu>
Message-Id: <199501161730.AA00506 at zephyr.isi.edu>
Subject: Re: IEPG.......
To: bsimpson at morningstar.com
Date: Mon, 16 Jan 1995 09:30:16 -0800 (PST)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <3746.bill.simpson at um.cc.umich.edu> from "William Allen Simpson" at Jan 13, 95 06:46:33 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 879
A more careful reading indicates the following:
> not survive the latest EBONE restructuring. The European IEPG
> (Internet Engingeerig Planning Group) did not take off earlier
> this year as planned. A new forum was created for network
> operations, which focussed on common engineering and operations.
>
> You are absolutely correct. I'm merely responding to information that
> the IEPG (which was the selected choice for a non-ISoc affiliated
> global operator's forum after much debate last year) had devolved into a
> European-only group.
>
> Bill.Simpson at um.cc.umich.edu
>
There is the IEPG and there was going to be a European IEPG. When the Euro
"chapter" of the IEPG did not form, the European Operators Fourm (EOF) was
created. This gives Europe and North America specific Operations groups and
the IEPG covers the globe.
--
--bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05854;
16 Jan 95 15:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05850;
16 Jan 95 15:52 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa04661;
16 Jan 95 15:52 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA19789 at pad-thai.cam.ov.com>; Mon, 16 Jan 1995 15:02:57 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA19651; Mon, 16 Jan 95 15:00:07 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA19781 at pad-thai.cam.ov.com>; Mon, 16 Jan 1995 15:02:43 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA11071; Mon, 16 Jan 95 15:02:42 EST
Message-Id: <9501162002.AA11071 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Re-iterating call for comment: revised charter and milestones
Date: Mon, 16 Jan 1995 15:02:41 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
CAT fanciers:
Seeing no discussion last week on this text, I'll reiterate a solicitation
for comment and discussion this week, with a target of submitting this
to Jeff Schiller as Security Area Director next Monday, 23 January
or soon thereafter as a proposed revision to the CAT WG description.
Review and comment therefore solicited by this Friday, 20 January.
Thanks, regards, ...
--jl
------- Forwarded Message
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <NAA05737 at pad-thai.cam.ov.com>; Mon, 9 Jan 1995 13:19:18 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA08904; Mon, 9 Jan 95 13:19:16 EST
Message-Id: <9501091819.AA08904 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Updating charter and milestones
Date: Mon, 09 Jan 1995 13:19:16 -0500
From: John Linn <linn at cam.ov.com>
CAT fanciers:
We have a large number of activities underway and under discussion
within the WG, and it's a strategic point to revisit and update the
WG's charter and milestones to replace the now-dated version resident
in the IETF directories and to assess where we stand and how we should
proceed. Here's a proposed draft revision for "Description of Working
Group" and "Goals and Milestones". Discussion solicited.
- --jl
Common Authentication Technology (cat)
- --------------------------------------
Description of Working Group:
The goal of the Common Authentication Technology Working Group is to
provide strong authentication, integrity, and confidentiality services
to a variety of protocol callers in a manner which insulates those
callers from the specifics of underlying security mechanisms. We
anticipate future work in extensions to support authorization
services.
By separating security implementation tasks from the tasks of
integrating security data elements into caller protocols, those tasks
can be partitioned and performed separately by implementors with
different areas of expertise. This provides leverage for the IETF
community's security-oriented resources, and allows protocol
implementors to focus on the functions their protocols are designed to
provide rather than on characteristics of security mechanisms. CAT
seeks to encourage uniformity and modularity in security approaches,
supporting the use of common techniques and accommodating evolution of
underlying technologies.
In support of these goals, the working group pursues several
interrelated tasks. We have defined a common service interface
allowing callers to invoke security services, and a common security
token format, incorporating means to identify the mechanism type in
conjunction with which security data elements should be interpreted.
We are currently working on a revision to these documents ("GSS-V2")
in response to implementation experience.
In addition to interface and token framing issues, the CAT Working
Group also works towards agreements on suitable underlying mechanisms
to implement security functions; Kerberos V5 and Simple Public-Key
Mechanism (SPKM) proposals are discussed in currently active Proposed
Standards and Internet-Drafts, with a prior public-key proposal
(Distributed Authentication Security Services (DASS)) documented in an
Informational RFC.
The CAT Working Group also consults with other IETF working groups
responsible for candidate caller protocols, pursuing and supporting
design refinements as appropriate. FTP Security is a particular
integration example; preparation of this specification has proceeded
within the CAT WG.
Goals and Milestones (as of January 1995):
Done: Standards-track RFCs 1508 and 1509, Internet-Drafts on GSS-V2,
Kerberos V5 GSS-API Mechanism, SPKM, IOP, Kerberos One-Time
Password integration, and FTP Security.
Jan 95: Agree on revision to WG charter and on scope of GSS-V2
changes vs. issues to be deferred for later consideration.
Jan 95: Issue Internet-Draft proposal re GSS-API Windows bindings.
Mar 95: Finalize FTP Security Internet-Draft for advancement to
Proposed Standard.
Mar 95: Finalize Kerberos V5 GSS-API Mechanism Internet-Draft for
advancement to Proposed Standard.
Apr 95: Finalize GSS-V2 Internet-Draft as basis for advancement of
GSS-API to Draft Standard or for submission to become new Proposed
Standard. [NOTE: This date assumes that GSS-V2 scope does not grow
significantly beyond the issues identified in the December 1994
meeting minutes, and that no major impacts are identified as results
of parallel work on the GSS-API negotiation mechanism.]
Apr 95: Revision of RFC-1509 for GSS-V2.
Apr 95: Initial Internet-Draft for GSS-API negotiation mechanism,
exchanging tokens to identify a common security mechanism shared
between peers and then proceeding to establish a security context
using that mechanism.
Apr 95: Revised IOP Internet-Draft.
Apr 95: Submit SPKM as Proposed Standard, assuming sufficient and
suitable implementation experience.
Jul 95: Initial Internet-Draft for GSS-API multi-mechanism
registration (SPI) facilities.
Jul 95: Plan next phase of activities to follow GSS-V2.
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06212;
16 Jan 95 16:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06206;
16 Jan 95 16:13 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05138;
16 Jan 95 16:13 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06185;
16 Jan 95 16:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06035;
16 Jan 95 16:09 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa05036; 16 Jan 95 16:09 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm038-03.dialip.mich.net [141.211.7.107]) by merit.edu (8.6.9/merit-2.0) with SMTP id QAA12734 for <ietf at CNRI.Reston.VA.US>; Mon, 16 Jan 1995 16:09:22 -0500
Date: Mon, 16 Jan 95 21:00:43 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-ID: <3760.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-to: bsimpson at morningstar.com
Subject: Re: IEPG.......
Thanks, Bill, that makes sense.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08153;
16 Jan 95 18:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08147;
16 Jan 95 18:22 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07698;
16 Jan 95 18:22 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08135;
16 Jan 95 18:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08095;
16 Jan 95 18:18 EST
Received: from [192.41.217.2] by CNRI.Reston.VA.US id aa07601;
16 Jan 95 18:18 EST
Received: by pluto.dss.com (4.1/SMI-4.0)
id AA26941; Mon, 16 Jan 95 18:17:51 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joachim Martillo <martillo at pluto.dss.com>
Message-Id: <9501162317.AA26941 at pluto.dss.com>
Subject: Re: Testbeds
To: RPlatt at ptxecrc.com, Mario Savvides <mario at pluto.dss.com>,
Tony Bono <wizard at pluto.dss.com>, bsimpson at morningstar.com,
tkalil at arpa.mil, czbb001 at access.texas.gov, ietf at CNRI.Reston.VA.US
Date: Mon, 16 Jan 1995 18:17:50 -0500 (EST)
In-Reply-To: <2051122F01800370 at -SMF-> from "RPlatt at ptxecrc.com" at Jan 10, 95 08:02:00 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 4045
Hi,
Just a note about testbeds. I noticed in Communications Week January
2, 1995, p. 23, that Strategic Networks Consulting Inc. and Scott
Bradner are setting up an Ethernet Switching and ATM testbed. In
Communications Week January 9, p. 1, I noticed that Tel Aviv
University is setting up an ATM testbed.
The establishment of these internetworking testbeds and other testbeds
outside the government sector suggests that the computer networking
market has evolved to the point where even the newer internetworking
technologies like ATM cannot be considered to be fundamentally
untried.
These technologies hardly require government seed money or testbeds
for proof of concept or capability. There already are lots of persons
or corporations, skilled in the art and expert in the technology, who
are funding development or creating testbeds.
Joachim Martillo
Manager of Internetworking Research
Penril Datability Networks
Penril Datability Advanced Communications Research Center
190 N. Main St.
Natick, MA 01760
VOICE 508-653-5313
FAX 508-653-6415
EMAIL martillo at dss.com
martillo at penril.com
This note does not reflect an official Penril Datability Networks, Inc.
position with respect to internetworking or related issues.
> As one who supports electronic commerce efforts, and requires the widespread
> use of these technologies, I fully support Bill Simpson's concepts that the
> testbeds should support multiple technologies and disparate geographic
> locations. In addition to distance between testbeds, however, I would
> recommend that one or more testbeds be located in a rural location to
> establish a Virtual Industrial Park. The Virtual Industrial Park would
> provide the testbed, leverage testbed connectivity for demonstrating
> business case models of IP networks to local telephone companies, and serve
> as an additional educational forum for training small business in electronic
> commerce.
>
> Bob Platt 800.209.2772
> Electronic Commerce Resource Center 903.729.4610 fax
> 2000 S. Loop 256, #11 rplatt at ptxecrc.com
> Palestine, TX 75801
> -------------
> Original Text
> >From ietf-request at IETF.CNRI.Reston.VA.US, on 1/9/95 6:29 PM:
> > The G-7 governments (U.S., Japan, Germany, Italy, France, U.K., Canada +
> > the European Commission) are considering promoting int'l "interoperability
> > testbeds" -- possibly building on existing national efforts.
> >
> As may be inferred from my recent comments to the ietf list, I support
> and encourage such testbeds, which have historically been of great
> benefit for progress of the technology.
>
> However, in addition to the proposal used by the US NSF of a single
> vendor demonstrating a high speed link between only a few sites, I would
> recommend a more DARTnet style approach which connects larger
> geographically dispersed sites for hands-on research.
>
>
> > One idea under consideration is a testbed that would promote multi-vendor
> > interoperability for ATM signalling, traffic management, and IP over ATM.
> >
> > Since there is some concern that the governments not mandate ATM -- I'd
> > be interested to know what other technologies the governments should
> > consider sponsoring for research/testbed activities to advance
> > high-speed, wide-area networking.
> >
> I would like to support Craig Partridge in that the Synchronous Digital
> Heirarchy (SDH) be used as the testbed basis, rather than ATM.
>
> SDH is particularly beneficial, in that it is designed to harmonize
> the conflicts in the various national digital telephony networks.
> That would be more appropriate to an international effort.
>
> Also, SONET/SDH has code points for other packetization techniques
> other than ATM, such as FDDI and PPP [RFC-1619].
>
> These can flow interspersed together over the same links, as each
> Synchronous Payload Envelope (SPE) has an indication of its contents.
> That would allow testing of different techologies side by side, without
> significant additional expense.
>
> Bill.Simpson at um.cc.umich.edu
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08733;
16 Jan 95 19:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08727;
16 Jan 95 19:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08531;
16 Jan 95 19:12 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08714;
16 Jan 95 19:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08652;
16 Jan 95 19:09 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08474;
16 Jan 95 19:09 EST
Received: from hplms26.hpl.hp.com by venera.isi.edu (5.65c/5.61+local-20)
id <AA26995>; Mon, 16 Jan 1995 16:09:53 -0800
Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with SMTP
(1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA23478; Mon, 16 Jan 1995 16:10:41 -0800
Received: by hplabsz.hpl.hp.com
(1.37.109.14/15.5+ECS 3.3+HPL1.1) id AA244721389; Mon, 16 Jan 1995 16:09:49 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ted Laliotis <laliotis at hplabsz.hpl.hp.com>
Message-Id: <199501170009.AA244721389 at hplabsz.hpl.hp.com>
Subject: Superhighway Technologies Conference
To: tcc at cs.umass.edu, ietf at isi.edu
Date: Mon, 16 Jan 95 16:09:49 PST
Mailer: Elm [revision: 70.85.2.1]
*******Please post to other groups that may be interested******
TECHNOLOGIES for the SUPERHIGHWAY
IEEE COMPCON 95
To be held in San Francisco, March 5-9 at the Stanford Court Hotel.
COMPCON '95 is the premier professional conference on
Information Superhighway Technologies and applications.
It is sponsored by the IEEE Computer Society. There
are no exhibits. This is a no-nonsense technical
conference for computer science and engineering
professionals who are interested to share and learn
more about the rapidly growing Information Superhighway
business. Besides three days of 90 technical sessions,
there are 9 tutorials in relevant subjects.
------------------------------
For Advanced Program (printed copy after Jan 20)
e-mail: egrimes at aol.com
FAX: 408 973 1325
URL for World Wide Web access: http://www.hal.com/compcon
To Register for the conference:
e-mail: COMPCON95 at lbl.gov
FAX: 510 422 2495, Tel: 510 422 2199
Mail: Compcon 95
c/o Dave Hunt, L-130
LLNL, PO Box 808,
Livermore, CA 94550
Conference Fees (3 days):
Early* On-site
IEEE Member $ 325 $ 375
Non-Member $ 425 $ 475
Student $ 50 $ 50
*Early registration cut off: Feb. 21
One-day $175 (Members), $250 (non-members),
Tutorials (these cost extra)
Full day tutorials same as conference fees
1/2 day tutorials (half above fee)
Speakers, committee members, session chairs can all use the lower member prices,
whether an IEEE member or not.
.pa
============
Master Compcon 1995 plan with papers, sessions and Tutorials
============
Theme: TECHNOLOGIES for the SUPERHIGHWAY
MONDAY March 6, 1995
Plenary speakers:
Professor Dave Farber,
Moore Professor of Telecommunications, University of Pensylvania
"Glass Tunnels Connecting Broadband Islands - The GII"
Jim Clark, Chairman and CEO, Netscape Communications Corp.
"Internet = Electronic Commerce, Now!"
Monday, Track 1
World Wide Web Topics, W. W. Wilcke, HAL
1. The WWW as a Platform Independent Interface to High Performance
Computing, David Robertson and Bill Johnston, Lawrence Berkeley
Laboratory
2. WWW Network Traffic Patterns, Jeffrey Sedayao, Intel
3. A Powerful Wide-Area Client, Tak W. Yan, Stanford Univ,
and Juergen Annevelink, HP
Electronic Commerce on the Internet, D. Gifford, Open Market Inc, and MIT
1. Netbill: An Electronic Commerce System Optimized for Network
Delivered Information and Services, Marvin Sirbu and
J. Doug Tygar, Carnegie Mellon University
2. Payment Switches for Open Networks, by D. Gifford, A. Payne,
L. Stewart, and W. Treese, Open Market, Inc.
3. Payment services for open networks, B. Clifford Neuman,
University of Southern California
Business on Networks, Fred Strange, LLNL and FSTC
1. Doing Business of the Information Highway: The nine steps to
conduct business on the info. highway. F, Strange, LLNL
2. CommerceNet: Spontaneous Electronic Commerce on the Internet
Allan M. Schiffman and Jay M. Tenenbaum, EIT
3. Ordering, Distributing and Receipt: Order Processing &
Management at IBM, Don Willenborg, IBM
4. Billing, Payment/Settlement, Accounting & Ancillary Services:
Netaccount, Deepak Gupte, Nations Bank
.pa
Monday, Track 2
Is it time to pay attention?
Information Highway Trials in the Bay Area, W. J. Lennon, LLNL
1. Wavelength Division Multiplexing Wide Area Network trial:
The National Transparent Optical Network Consortium, W. J. Lennon,
Lawrence Livermore National Lab
2. Wavelength Division Multiplexing in Local Area Network:
Stanford's Starnet, Leonid Kazovsky, Stanford University
3. ATM services Trial: BAGnet and other CalREN supported projects
William Johnston, Lawrence Berkeley Lab
Distance Learning Technologies, Tom Wilkins, HP
1. Distance Learning on the Desk Top, Pat Portway,
Applied Business Telecommunications
2. Distance Learning in Higher Education, Dr. Carla Lane
3. Distance learning the community/corporate connection, Tom Wilkins, HP
Satellite Superhighways, Ted Laliotis, HP
1. Superhighway to the home via DBS delivery, Peter Hampton,
Primestar Partners
2. Low Earth Orbit (LEO) applications on the horizon, James Stuart,
Teledesic
3. Role of satellites in NII and GII, Lawrence P. Seidman, Hughes
4. Gigabit Satellites in Distributed Supercomputing for Global Research,
Larry Bergman, JPL
.pa
Monday, Track 3
Alpha 21164 Microprocessor and Systems, Dileep Bhandarkar, DEC
1. The Organization of the Alpha 21164 Microprocessor
Pete Bannon and Jim Keller, Digital Equipment Corporation
2. World's Fastest Workstation, John Zurawski, John Murray, Paul Lemmon.
Digital Equipment Corp
3. 21164 based High Performance Multiprocessor Server
D.M.Fenwick, D.J.Foley, S.R.VanDoren, Digital Equipment Corporation
First generation PowerPC SMP systems, Kimming So, IBM
1. IBM RS/6000 Commercial SMP Systems, James O. Nicholson, IBM
2. AIX Operating System Support for Symmetric Multiprocessing
Jack C. O'Quin, Ronald S. Clark and Thomas V. Weaver, IBM
3. The performance and performance methodology for a PowerPC SMP system
Bret R. Olszewski, IBM, Jean-Jacques Guillemaud, Groupe Bull Inc
PA-RISC: Application-Driven Innovation, Ruby Lee, HP
1. Advanced Performance Features of the 64-bit PA-8000
Doug Hunt, et al , HP, Fort Collins
2. New MP Hardware Architecture for Commercial and Technical Environments,
Loren Staley, et al , HP Roseville
3. A Highly Scalable System Utilizing up to 128 PA-RISC Processors
Tony Brewer, et al, Convex Computer
.pa
TUESDAY, March 7, 1995
Plenary speakers:
Steve Schramm, VP Engineering, General Magic,
"Agents that Travel"
Andy Lippman, Associate director, MIT Media Lab,
"Distributed Media Bank"
Tuesday, Track 4
Information Hosting Services, G. Lidor, Bell Labs, AT&T
1. PersonaLink Agent-based Messaging and Information Services
Paul S. R. Chisholm, AT&T
2. InfoSleuth: Networked Exploitation of Information using Semantic
Agents, Darrell Woelk and Christine Tomlinson, MCC
3. Enhancing Lotus Notes for Carrier Grade Hosting,
Paul Cummings, Lotus Development Corp.
Mobile Internet Applications (based on PDAs), Joel Bartlett, DEC
1. Experience with a Wireless World Wide Web Client, Joel F. Bartlett, DEC
2. Enabling PDA's with Wireless Communications, Rick Lane, Motorola
3. Video on Demand in Wireless Communication, E. Tsern, Stanford Univ
Infopad, A. Baum, Apple
1. The Infopad Project: Providing Portable Multimedia Access
to the Information Highway, Bob Brodersen or Jan Rabaey UC Berkeley
2. Infopad: A Low Power, Wireless Multimedia Terminal, Sam Sheng, UC Berkeley
3. Infonet: Network Infrastructure and Software for Mobile Information Access,
My Le, UC Berkeley
4. User Interface and Applications in the Infopad Environment,
Andy Burstein or Eric Brewer, UC Berkeley
.pa
Tuesday, Track 5
Advanced Media Enhancement Technologies. R. Lee, HP
1. An Object-Based Architecture for a Digital Compression Camera,
John Beck, et al, HP Chelmsford
2. Realtime MPEG Video via Software Decompression on PA-RISC Processors,
Ruby Lee, et al, HP Cupertino
3. Color Recovery: Millions of Colors from an 8-bit Graphics Device,
Anthony Barkans, HP Fort Collins
Interactive TV, R. Williams, IBM
1. Set-top boxes and applications, Lee Colby, HP
2. Oracle media server and its applications, Andy Laursen, Mark Porter and
Jeffrey Olkin, Oracle
3. Video on Demand: Hong Kong trial, R. Haskin and F. Stein, IBM
Storage Hierarchy in Multimedia Systems, M. Kienzle, IBM
1. Buffering and Caching in Large-Scale Video Servers,
Asit Dan, Dan Dias, Rajat Mukherjee, Christos Polyzois, Dinkar
Sitaram, Renu Tewari, IBM
2. Using Tertiary Storage in Video-on-Demand Servers
Martin Kienzle, Asit Dan, Dinkar Sitaram, and William Tetzlaff, IBM
3. Server Preroll RPC for Client/Server Multimedia
M.Baugher, G.Flurry, J.Wilkinson, IBM
4. Elements of scalable video servers, W. Tetzlaff, IBM and
R. Flynn, Polytechnic University.
.pa
Tuesday, Track 6
HAL Computer Systems, Wen Li, HAL
1. Architectural Overview of HAL Systems, Winfried W. Wilcke, HAL
2. The CPU Microarchitecture, Niteen Patkar, HAL
3. Cache and Memory Management Microarchitecture, Chien Chen and
Dave Lyon and David Chang, HAL
PowerPC Processors, S. Peter Song, IBM and Nasr Ullah, Motorola
1. A PowerPC Microprocessor for the Low Power Computing Market,
Deene Ogden, Belli Kuttanna, Albert J. Loper, Soummya Mallick
and Michael Putrino, IBM
2. The PowerPC 620 Microprocessor: A High Performance Superscalar
RISC Microprocessor, David Levitan, Thomas L. Thomas, Motorola and
Paul Tu, IBM
3. A Pipelined, Weakly-Ordered Bus for Multi-Processing Systems
Michael Allen and Kurt Lewchuk, Motorola
Power PC software and Systems, N. Ullah, Motorola, M. NguyenPhu, IBM
1. The PowerPC Architecture: 64-bit Power with 32-bit Compatibility
C. Ray Peng, Motorola, Tom Petersen and Ron Clark, IBM
2. The PowerPC 620 in Distributed Computing,
Michael P. Taborn, John K. Yuan, David C. Lee, and Albert Tsay, IBM
3. Developing Windows NT Applications for the PowerPC,
Howard C. Thamm, Motorola
4. Using the PowerPC Microprocessor for Power-Managed Systems (by IBM),
Keith Braithwaite, IBM
.pa
Social Hour: TOP OF THE MARK, MARK HOPKINS HOTEL, 5:30 - 7:30
Note: The TOP OF THE MARK is a restaurant on top of a hotel tower
next to the conference hotel. Since both hotels are on top
of Nob Hill, the view from the TOP OF THE MARK is absolutely
spectacular.
.pa
WEDNESDAY, March 8, 1995
Plenary speakers:
Professor Dave Patterson, UC Berkeley
"A Case for Networks of Workstations: NOW"
John Warnock, CEO of Adobe Systems
"The New Information Frontier"
Wednesday, Track 7
NOW: Networks of Workstations, D. Patterson, UC Berkeley
1. The IBM SP-2, Tilak Agerwala, IBM
2. The Berkeley NOW Project, Thomas E. Anderson, David E. Culler, and
David A. Patterson, U.C. Berkeley
3. Tempest: User-level Shared Memory", Mark D. Hill, James R. Larus, and
David A. Wood, University of Wisconsin
High speed network protocols, W. Lennon, LLNL
1. 1394 --It's Everywhere, Dan Moore and Gary Hoffman, Skipstone Inc.
2. Fibrechannel 1995, Ed Frymoyer, HP
3. Local Area MultiProcessor: surpassing clusters,
David B. Gustavson, SCIzzL, and Prof. Qiang Li, Santa Clara University
ATM panel, S. Bell, Bell Consulting
1. The WAN Perspective, Larry Roberts, CEO ATM Systems
2. The LAN Perspective, Robert Newman, Dir. ATM, Synoptics
3. The Silicon Perspective, Akber Kazmi, Philips Semiconductor
.pa
Wednesday, Track 8
Taligent Object Services, J. Grimes, Taligent
1. Runtime Services for Persistent Objects, Russell Nakano, et al,
Taligent
2. An Object-Oriented Device Driver Model, Steve Lemon, et al, Taligent
3. Object-Oriented Wrappers for the Mach Microkernel, Stephen Kurtzman
and Kayshav Dattatri, Taligent
Multimedia Authoring and Acrobat, J. King, Adobe and M. Harrison, UC Berkeley
1. Technical Issues in Hypermedia Scripting Languages,
Brian F. Dennis and Prof. Michael A. Harrison, UC Berkeley
2. Acrobat 2.0, Andrew Shore, Adobe Systems
3. Choosing the Right Tool for the Job: Authoring vs. Programming Tools,
Michael McGrath, Grafica Multimedia, Inc.
Post-Production (Hollywood), A. Fetzer, consultant
1. Digital Editing Technology in Broadcast Video Production
Leon Siverman, Laser Pacific
2. Digital Technology and the Convergence in Film, Video and Multimedia
Bruce Pfander, 20th Century Fox
3. Digital Editing Technology - A Film Maker's Perspective
Andrew Silver, Silver Productions
.pa
Wednesday, Track 9
Advanced CD systems, W. Lenth
1. CD technology for the future,
Hoss Bozorgzad, Philips
2. CD and Competing Mass Storage Technologies in an Application Driven
Environment, Paul Wehrenberg, Apple
3. CD or not to CD, A. Bell, IBM
High Performance Storage Systems, R. Morris, IBM
1. Scalable Network Storage, E. K. Lee, Digital Equipment Corporation
2. The Parallel Scotch Storage Server, G. Gibson, CMU
3. Future Directions in RAID, J. Menon, IBM
New Trends in Storage Management, J. Menon, IBM
1. ADSM: A multi-platform, scalable, backup and archive mass storage system.
L-F Cabrera, B. Rees, S. Steiner, et al. IBM
2. An Object Oriented Model for Distributed Storage Management,
David Low, EMC
3. Step by Step, Hierarchical Storage Management, Jim Gast, Palindrome
4. Data Striping for Heterogeneous Environments, Jim McNiel, Cheyenne
.pa
Wednesday, Track 10
The UltraSPARC Microprocessor with Multimedia Support, Robert Garner, SUN
1. UltraSPARC: The Next Generation Superscalar 64b SPARC
Dale Greenley, et al, SUN
2. Verification of the UltraSPARC Microprocessor
Shrenik Mehta, et al, SUN
3. The Visual Instruction Set (VIS) in UltraSPARC, Marc Tremblay, SUN
4. Video processing with UltraSparc, Chang Zhou, et al, SUN
Can Digital Technology Reinvent the Newspaper? Panel, Paul Freiberger,
Interval Research
1. Publishing today is like an electronic pinata, Paul Saffo,
Institute for the Future.
2. An optimistic view that says hardware is key, John Markoff,
New York Times
3. Bill Mitchell, Director of Mercury Center, Knight-Ridder Inc.
Internet Access to Environmental Data, P. Mantey, UC Santa Cruz
1. SEQUOIA 2000, Joseph Pasquale, UC San Diego
2. BADGER: Bay Area Digital GeoResource, David Milgram
Lockheed Research Laboratory
3. REINAS: Real-Time Environmental Information Network and Analysis
System, Darrell Long, UC Santa Cruz
==============
TUTORIALS
Sunday, March 5
Yale N. Patt, Computer Architecture Choices
Steve W. Bell, ATM Overview
Lawrence Rowe, Digital Audio and Video Compression, Multimedia Systems and
Applications
Henry A. Sowizral, Understanding and Developing Virtual Reality Systems
Thursday, March 9
Robert Orfali, Dan Harkey and Jim Gray, Client/Server Overview and Update
Dave Grubb and Jerry Owens, Exploring INTERNET on your PC
Borko Furht, Distributed Multimedia Systems and Applications
Jim King, Color on the Desktop, (1/2 day)
M. Ketabchi, Is DBMS Technology in Chaos, Modern DBMS approaches Products and
Standards and Trends (1/2 day)
Updated 1/6/95
Robin Williams (Program Chair) rwilliams at almaden.ibm.com
Winfried W. Wilcke (General Chair) wilcke at hal.com
Ted Laliotis (Steering Committee Chair) laliotis at hpl.hp.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02969;
17 Jan 95 10:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02965;
17 Jan 95 10:19 EST
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa06559;
17 Jan 95 10:19 EST
Received: by interlock.ans.net id AA34894
(InterLock SMTP Gateway 1.1 for iwg-out at ans.net);
Tue, 17 Jan 1995 10:06:42 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
Tue, 17 Jan 1995 10:06:42 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Tue, 17 Jan 1995 10:06:42 -0500
To: IETF-Announce: ;
Cc: bgp at ans.net
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: A Border Gateway Protocol 4 (BGP-4) to Draft Standard
Date: Tue, 17 Jan 95 10:02:22 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-Id: <9501171002.aa02541 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Inter-Domain Routing Working
Group to consider the following documents for the status of Draft
Standard:
1. Experience with the BGP-4 protocol
<draft-ietf-idr-bgp4-experience-00.txt>
2. BGP-4 Protocol Analysis
<draft-ietf-idr-bgp4-analysis-00.txt>
3. A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-00.txt>
4. Application of the Border Gateway Protocol in the Internet
<draft-ietf-bgp-app-00.txt>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
January 31, 1995.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09013;
17 Jan 95 16:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09009;
17 Jan 95 16:25 EST
Received: from [192.231.148.11] by CNRI.Reston.VA.US id aa14112;
17 Jan 95 16:25 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <PAA14941 at pad-thai.cam.ov.com>; Tue, 17 Jan 1995 15:47:44 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA03532; Tue, 17 Jan 95 15:44:59 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA06003; Tue, 17 Jan 95 12:44:55 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA05567; Tue, 17 Jan 95 12:44:44 PST
Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id MAA05125; Tue, 17 Jan 1995 12:44:58 -0800
Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4)
id MAA04156; Tue, 17 Jan 1995 12:44:43 -0800
Date: Tue, 17 Jan 1995 12:44:43 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199501172044.MAA04156 at elrond.ss-eng.eng.sun.com>
To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Clarification on certain details of KerbV5 GSSAPI I-D
X-Sun-Charset: US-ASCII
Folks,
I have briefly read the current I-D, "The Kerberos Version 5 GSS-API Mechanism,"
and have two questions. First, section 3.2 defines Quality of Protection values
for the integrity algorithms, but not for the privacy algorithms. While I
realize that there is only one choice at the moment (i.e., per section 1.2.2
only DES is supported), shouldn't there be a defined constant in the document
that corresponds to this choice?
Secondly, it appears from the document that the actual value associated with
the QOP defined constants is implementation specific (i.e., I see no place
where the strings corresponding to the QOP are given numerical values). If
so, I believe this is a mistake. It is very likely that applications will
want to communicate one or more QOP values out-of-band in order to agree
on the strength of protection they should afford their communications. By
leaving these values unspecified, each application must come up with a
standard set of values for intra-negotiation purposes. This will lead to
confusion and unnecessary complexity.
Regards,
Dan Nessett
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11048;
17 Jan 95 17:24 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15207;
17 Jan 95 17:24 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10905;
17 Jan 95 17:23 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10490;
17 Jan 95 17:15 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15005;
17 Jan 95 17:15 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10472;
17 Jan 95 17:15 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: John Curran <jcurran at nic.near.net>
cc: nomcom at nic.near.net
Subject: 1995 Request for IAB/IESG Candidates
Date: Tue, 17 Jan 95 17:15:30 -0500
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9501171715.aa10472 at IETF.CNRI.Reston.VA.US>
Hello Folks,
The 1995 Nominations Committee, while off to a slow start, is now up
and ready to work on all of your nominations for IAB and IESG positions.
As always, half of the current positions have become available, and we
now require your assistance in determining the best candidates for these
positions.
The following positions are up for consideration at the present time:
o IESG Operations AD (Area Director)
o IESG Transport AD
o IESG Applications AD (Both AD's open)
o IESG Network Management AD
o IESG Internet AD
o IAB Member
o IAB Member
o IAB Member
o IAB Member
o IAB Member
o IAB Member
If you know someone who would serve well in one of the above positions,
or if you yourself would like to be considered for such a position, please
send an email message to nomcom at nic.near.net, indicating such to the
nominating committee indicating the specific candidate and position.
Thanks!
/John
p.s. Anyone who is currently up for renewal who would like to be considered
for another term should drop us a message unless you've already
received email confirmation that we're aware of your interest...
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01685;
18 Jan 95 9:00 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01678;
18 Jan 95 9:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04655;
18 Jan 95 9:00 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01643;
18 Jan 95 9:00 EST
Received: from relay1.UU.NET by IETF.CNRI.Reston.VA.US id aa01452;
18 Jan 95 8:46 EST
Received: from gsstation-2.NetMgrs.COM by relay1.UU.NET with SMTP
id QQxzfj03226; Wed, 18 Jan 1995 08:46:12 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: dgh at netmgrs.com
Received: from portable.netmgrs.com ([198.6.64.110])
by gsstation-2.NetMgrs.COM (4.1/NETMGRS-0.9/03-30-94)
id AA17131; Wed, 18 Jan 95 08:40:58 EST
Date: Wed, 18 Jan 95 09:15:26 PST
Subject: Multi-bridge MIB
To: ietf at ietf.nri.reston.va.us
X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc.
Message-Id: <Chameleon.4.00.950118091820.dgh at portable.netmgrs.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Anyone heard of the Multi-bridge MIB? I've come across it
three times in the last 3 days, writing different proposals.
It seems to allow for stackable ethernet switches, by
implementing parts of MIB II, the bridge MIB, and the
ethernet MIB in a non-standard way.
Is this a new RFC I don't know about? If not, anyone know
which company originated this MIB?
The header for the MIB reads:
MULTIPLE-BRIDGE-MIB
All comments appreciated,
David
-------------------------------------
Name: David Hamilton
OEM Technical Manager
E-mail: dgh at netmgrs.com
The opinions expressed are solely my
own, and have no association to my
corporate duties.
-------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02186;
18 Jan 95 9:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02175;
18 Jan 95 9:50 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05892;
18 Jan 95 9:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02148;
18 Jan 95 9:50 EST
Received: from stilton.cisco.com by IETF.CNRI.Reston.VA.US id aa02036;
18 Jan 95 9:47 EST
Received: from [198.92.24.2] (fred-mac-fr.cisco.com [198.92.24.2]) by stilton.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id GAA01634; Wed, 18 Jan 1995 06:47:18 -0800
X-Sender: fred at stilton.cisco.com
Message-Id: <v02110104ab42d8f29859 at [198.92.24.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Jan 1995 06:47:20 -0800
To: dgh at netmgrs.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fred at cisco.com>
Subject: Re: Multi-bridge MIB
Cc: ietf at IETF.CNRI.Reston.VA.US
At 9:15 AM 1/18/95, dgh at netmgrs.com wrote:
>Anyone heard of the Multi-bridge MIB? I've come across it
>three times in the last 3 days, writing different proposals.
>It seems to allow for stackable ethernet switches, by
>implementing parts of MIB II, the bridge MIB, and the
>ethernet MIB in a non-standard way.
Whatever you learn of it would be of interest to me. It is not related to
the IETF's Bridge MIB, though the concept of an array of bridges was
considered by the working group and rejected.
Fred Baker
Charir, Bridge MIB Working Group
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02580;
18 Jan 95 10:04 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06458;
18 Jan 95 10:04 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02519;
18 Jan 95 10:03 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02349;
18 Jan 95 9:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05967;
18 Jan 95 9:54 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02336;
18 Jan 95 9:54 EST
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: The PPP Banyan Vines Control Protocol (BVCP) to
Proposed Standard
Date: Wed, 18 Jan 95 09:54:33 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501180954.aa02336 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "The PPP Banyan Vines Control
Protocol (BVCP)" <draft-ietf-pppext-vines-02.txt> for the status of
Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
January 31, 1995.
IESG Secretary
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02668;
18 Jan 95 10:05 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06509;
18 Jan 95 10:05 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02632;
18 Jan 95 10:05 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02475;
18 Jan 95 10:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06249;
18 Jan 95 10:01 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02469;
18 Jan 95 10:01 EST
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: The PPP XNS IDP Control Protocol (XNSCP) to Proposed
Standard
Date: Wed, 18 Jan 95 10:01:09 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501181001.aa02469 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "The PPP XNS IDP Control Protocol
(XNSCP)" <draft-ietf-pppext-xnscp-00.txt> for the status of Proposed
Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
January 31, 1995.
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02928;
18 Jan 95 10:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06686;
18 Jan 95 10:12 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02907;
18 Jan 95 10:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02794;
18 Jan 95 10:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06565;
18 Jan 95 10:08 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02786;
18 Jan 95 10:08 EST
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: The PPP Encryption Control Protocol (ECP) to Proposed
Standard
Date: Wed, 18 Jan 95 10:08:22 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501181008.aa02786 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "The PPP Encryption Control
Protocol (ECP)" <draft-ietf-pppext-encryption-01.txt> for the status of
Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
January 31, 1995.
IESG Secretary
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04544;
18 Jan 95 11:29 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08187;
18 Jan 95 11:29 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04526;
18 Jan 95 11:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04388;
18 Jan 95 11:24 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08106;
18 Jan 95 11:24 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04380;
18 Jan 95 11:24 EST
To: IETF-Announce: ;
cc: tftpexts at hpindsh.cup.hp.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: TFTP Option Extension to Proposed Standard
Date: Wed, 18 Jan 95 11:24:34 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501181124.aa04380 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the TFTP Extensions Working Group
to consider the following three Internet-Drafts for the status of
Proposed Standard:
o TFTP Option Extension <draft-ietf-tftpexts-option-ext-02.txt>
o TFTP Blocksize Option (draft-ietf-tftpexts-blksize-opt-01.txt)
o TFTP Timeout Interval and Transfer Size Options
(draft-ietf-tftpexts-options-00.txt)
The IESG will also be considering the publication of the following
Internet-Draft as an Informational Document:
o TFTP Option Negotiation Analysis (draft-ietf-tftpexts-analysis-00.txt)
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
February 1, 1995.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06949;
18 Jan 95 12:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06945;
18 Jan 95 12:54 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10161;
18 Jan 95 12:54 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA05655 at pad-thai.cam.ov.com>; Wed, 18 Jan 1995 12:10:42 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA29130; Wed, 18 Jan 95 12:07:55 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA05639 at pad-thai.cam.ov.com>; Wed, 18 Jan 1995 12:10:35 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA11860; Wed, 18 Jan 95 12:10:33 EST
Message-Id: <9501181710.AA11860 at winkl.cam.ov.com>
To: Dan Nessett <Danny.Nessett at eng.sun.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com, linn at cam.ov.com
Subject: Re: Clarification on certain details of KerbV5 GSSAPI I-D
In-Reply-To: Your message of "Tue, 17 Jan 1995 12:44:43 PST."
<199501172044.MAA04156 at elrond.ss-eng.eng.sun.com>
Date: Wed, 18 Jan 1995 12:10:33 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Dan,
I agree that there should be a designated and suitably-named
value for the (currently singular) confidentiality QOP, and that
a concrete value rather than just a symbolic name should be defined.
Consider these items hereby placed on the to-do list for the next
rev of the Kerberos V5 mechanism I-D.
There's been some discussion on the list about whether QOP values
should be represented by bitfields or instead evolve to OID sets.
This discussion needs to be revisited and converged.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07086;
18 Jan 95 13:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07080;
18 Jan 95 13:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10318;
18 Jan 95 13:01 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07067;
18 Jan 95 13:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07014;
18 Jan 95 12:57 EST
Received: from bodhi.nrl.navy.mil by CNRI.Reston.VA.US id aa10261;
18 Jan 95 12:57 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ran Atkinson <rja at bodhi.nrl.navy.mil>
Message-Id: <9501181250.ZM1596 at bodhi.nrl.navy.mil>
Date: Wed, 18 Jan 1995 12:50:39 -0500
Reply-To: atkinson at itd.nrl.navy.mil
X-Mailer: Z-Mail (3.0.0 15dec93)
To: ietf at CNRI.Reston.VA.US
Subject: FYI: WWW site with Internet stuff
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
X-Orig-Sender: rja at bodhi.itd.nrl.navy.mil
Steve Batsell (NRL, upstairs from me) happens to have setup a
networking WWW site at http://netlab.itd.nrl.navy.mil that might
be of interest to some folks.
In particular, he has a bunch of IETF/IAB pointers organised
nicely at http://netlab.itd.nrl.navy.mil/Internet.html. I have
found his page useful both for myself and also as a place that
I can point random people with inquiries towards. I thought
this might be worth mentioning to the folks on this list.
I should note that the WWW site is not any sort of "official"
or "blessed" site and Steve has never made any claims that
it was such.
I know Steve is usually looking for ways to improve his site with
additional links or pointers to other web servers so if you have
a site that might relate, it might be useful to mention it to him.
I hope this was useful rather than an interruption. I won't repeat
this announcement.
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07570;
18 Jan 95 13:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07566;
18 Jan 95 13:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10941;
18 Jan 95 13:33 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07533;
18 Jan 95 13:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07529;
18 Jan 95 13:30 EST
Received: from ceres.fokus.gmd.de by CNRI.Reston.VA.US id aa10907;
18 Jan 95 13:30 EST
Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5);
Wed, 18 Jan 1995 19:09:36 +0100
X-Mailer: exmh version 1.5.3 12/28/94
To: cellular at dfv.rwth-aachen.de, tccc at cs.umass.edu, perform at tay1.dec.com,
end2end-interest at isi.edu, ietf at isi.edu, rem-conf at es.net,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com, cip at bbn.com,
cnom at maestro.bellcore.com, ccrc at dworkin.wustl.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, iplpdn at CNRI.Reston.VA.US,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
Subject: Infocom'95 Conference Program and Registration
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Jan 95 19:09:30 +0100
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Henning Schulzrinne <schulzrinne at fokus.gmd.de>
Message-ID: <9501181330.aa10907 at CNRI.Reston.VA.US>
Infocom'95 --- Bringing Information to People
Information about Infocom'95, the Fourteenth Annual Joint Conference
of the IEEE Computer and Communications Societies is available through
the World Wide Web at
http://www.research.att.com/~hgs/infocom95/program.html
Infocom'95 takes place in Boston, April 2 - 6, 1995. Roughly 160
papers selected from 450 submissions will be presented, as well as
panels on satellite communication and resource reservations. The
keynote speaker will be Sandy Fraser, AT&T, with a historical
perspective on the information revolution. The conference opens with
tutorials on integrated service high speed networks (Robert Gallager),
broadband networks and ATM (Anthony Acampora), protocol design (Dave
Clark), wireless personal communications (David Goodman), and the
World Wide Web (David Tennenhouse and others).
----
Henning Schulzrinne email: hgs at fokus.gmd.de
GMD-Fokus phone: +49 30 25499 182
Hardenbergplatz 2 fax: +49 30 25499 202
D-10623 Berlin WWW: http://www.fokus.gmd.de/htbin/info/minos/hgs
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07659;
18 Jan 95 13:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07655;
18 Jan 95 13:37 EST
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa11068;
18 Jan 95 13:37 EST
Received: from sdiv.cray.com (daemon at ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id MAA29775; Wed, 18 Jan 1995 12:32:04 -0600
Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA19705; Wed, 18 Jan 1995 12:32:02 -0600
Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA19676; Wed, 18 Jan 1995 12:31:45 -0600
Received: from ceres.fokus.gmd.de (ceres.fokus.gmd.de [192.35.149.15]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id MAA29739 for <tcplw at cray.com>; Wed, 18 Jan 1995 12:31:43 -0600
Message-Id: <199501181831.MAA29739 at timbuk.cray.com>
Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5);
Wed, 18 Jan 1995 19:09:36 +0100
X-Mailer: exmh version 1.5.3 12/28/94
To: cellular at dfv.rwth-aachen.de, tccc at cs.umass.edu, perform at tay1.dec.com,
end2end-interest at isi.edu, ietf at isi.edu, rem-conf at es.net,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com, cip at bbn.com,
cnom at maestro.bellcore.com, ccrc at dworkin.wustl.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, iplpdn at CNRI.Reston.VA.US,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
Subject: Infocom'95 Conference Program and Registration
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Jan 95 19:09:30 +0100
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Henning Schulzrinne <schulzrinne at fokus.gmd.de>
Content-Length: 1074
Infocom'95 --- Bringing Information to People
Information about Infocom'95, the Fourteenth Annual Joint Conference
of the IEEE Computer and Communications Societies is available through
the World Wide Web at
http://www.research.att.com/~hgs/infocom95/program.html
Infocom'95 takes place in Boston, April 2 - 6, 1995. Roughly 160
papers selected from 450 submissions will be presented, as well as
panels on satellite communication and resource reservations. The
keynote speaker will be Sandy Fraser, AT&T, with a historical
perspective on the information revolution. The conference opens with
tutorials on integrated service high speed networks (Robert Gallager),
broadband networks and ATM (Anthony Acampora), protocol design (Dave
Clark), wireless personal communications (David Goodman), and the
World Wide Web (David Tennenhouse and others).
----
Henning Schulzrinne email: hgs at fokus.gmd.de
GMD-Fokus phone: +49 30 25499 182
Hardenbergplatz 2 fax: +49 30 25499 202
D-10623 Berlin WWW: http://www.fokus.gmd.de/htbin/info/minos/hgs
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09562;
18 Jan 95 15:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13474;
18 Jan 95 15:11 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09530;
18 Jan 95 15:11 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09446;
18 Jan 95 15:06 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idmr-pim-arch-01.txt, .ps
Date: Wed, 18 Jan 95 15:06:25 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501181506.aa09446 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Protocol Independent Multicast (PIM):
Motivation and Architecture
Author(s) : S. Deering, D. Estrin, D. Farinacci,
V. Jacobson, C. Liu, L. Wei
Filename : draft-ietf-idmr-pim-arch-01.txt, .ps
Pages : 32
Date : 01/17/1995
Existing multicast routing mechanisms were intended for use within regions
where a group is widely represented or bandwidth is universally plentiful.
When group members, and senders to those group members, are distributed
sparsely across a wide area, these schemes are not efficient; data packets
or membership report information are periodically sent over many links that
do not lead to receivers or senders, respectively. This characteristic lead
us to develop a multicast routing architecture that efficiently establishes
distribution trees across wide-area internets, where many groups will be
sparsely represented and where bandwidth is not uniformly plentiful due to
the distances and multiple administrations traversed. Efficiency is
evaluated in terms of the state, control message processing, and data
packet processing required across the entire network in order to deliver
data packets to the members of the group. The architecture also includes a
more traditional, dense mode of operation for use within campus networks
or other regions characterized by plentiful bandwidth.
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-idmr-pim-arch-01.txt".
Or
"get draft-ietf-idmr-pim-arch-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-arch-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-idmr-pim-arch-01.txt".
Or
"FILE /internet-drafts/draft-ietf-idmr-pim-arch-01.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 cnri.reston.va.us.
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: <19950117140305.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-pim-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-pim-arch-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950117140305.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09577;
18 Jan 95 15:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13488;
18 Jan 95 15:11 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09531;
18 Jan 95 15:11 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09432;
18 Jan 95 15:06 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: idmr at cs.ucl.ac.uk
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idmr-pim-spec-01.txt, .ps
Date: Wed, 18 Jan 95 15:06:22 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501181506.aa09432 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Multicast
Routing Working Group of the IETF.
Title : Protocol Independent Multicast (PIM): Protocol
Specification
Author(s) : S. Deering, D. Estrin, D. Farinacci,
V. Jacobson, C. Liu, L. Wei
Filename : draft-ietf-idmr-pim-spec-01.txt, .ps
Pages : 53
Date : 01/17/1995
This document describes protocols for efficiently routing to multicast
groups that may span wide-area (and inter-domain) internets. We refer to
the approach as Protocol Independent Multicast (PIM) because it is not
dependent on any particular unicast routing protocol.
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-idmr-pim-spec-01.txt".
Or
"get draft-ietf-idmr-pim-spec-01.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-pim-spec-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-idmr-pim-spec-01.txt".
Or
"FILE /internet-drafts/draft-ietf-idmr-pim-spec-01.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 cnri.reston.va.us.
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: <19950117141007.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idmr-pim-spec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idmr-pim-spec-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950117141007.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10803;
18 Jan 95 16:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14889;
18 Jan 95 16:09 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10776;
18 Jan 95 16:09 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10572;
18 Jan 95 16:02 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-newtelex-01.txt
Date: Wed, 18 Jan 95 16:02:04 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501181602.aa10572 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Relationship of Telex Answerback Codes to
Internet Domains (2nd Revision)
Author(s) : P. Robinson
Filename : draft-robinson-newtelex-01.txt
Pages : 63
Date : 01/17/1995
This memo provides a major revision to my Internet RFC 1394 by: including
new information which was not available to me when the original document
was released; changes to old information due to the destruction of the
Soviet Union, East Germany and Yugoslavia, and the Balkanization of
Czechslovakia; corrects minor format errors; corrects some
misunderstandings which occurred from some people's misreading of the
original RFC document; and removes some omissions which occurred in the
original RFC. As the corrections (including a whole new set of information
which is added to the original document) are substantial, if accepted for
publication as an Internet RFC, it will obsolete RFC 1394.
This draft revises the first draft to insert minor corrections.
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-robinson-newtelex-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-robinson-newtelex-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-robinson-newtelex-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 cnri.reston.va.us.
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: <19950117160651.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-newtelex-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-newtelex-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950117160651.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11170;
18 Jan 95 16:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15123;
18 Jan 95 16:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11159;
18 Jan 95 16:18 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10912;
18 Jan 95 16:13 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-armitage-ipatm-ipmc-03.txt
Date: Wed, 18 Jan 95 16:13:00 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501181613.aa10912 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Support for Multicast over UNI 3.1 based ATM Networks.
Author(s) : G. Armitage
Filename : draft-armitage-ipatm-ipmc-03.txt
Pages : 28
Date : 01/17/1995
This memo describes a Multicast Address Resolution Server (MARS)
architecture that allows ATM based IP hosts to support RFC 1112 style IP
multicast using the ATM Forum's UNI 3.1 point to multipoint connection
service. It also describes how this architecture can be generalized to
support other protocols wishing to multicast over UN 3.1 based ATM service.
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-ipatm-ipmc-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-armitage-ipatm-ipmc-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-ipatm-ipmc-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950117175009.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-armitage-ipatm-ipmc-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-armitage-ipatm-ipmc-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950117175009.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11209;
18 Jan 95 16:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15137;
18 Jan 95 16:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11175;
18 Jan 95 16:18 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10946;
18 Jan 95 16:13 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sdrp at catarina.usc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-sdr-erp-01.txt
Date: Wed, 18 Jan 95 16:13:36 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501181613.aa10946 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Source Demand Routing Working
Group of the IETF.
Title : Explicit Routing Protocol (ERP) for IPv6
Author(s) : P. Ford, Y. Rekhter
Filename : draft-ietf-sdr-erp-01.txt
Pages : 15
Date : 01/17/1995
This document specifies the format and processing of the IPv6 Explicit
Routing Protocol (ERP) Header. The purpose of this header is to provide
IPv6 forwarding functionality comparable to SDRP [SDRP]. The reader should
be familiar with [IPv6]. This document extensively uses the concept of
"packs", as described in [PACK].
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-sdr-erp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-sdr-erp-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-sdr-erp-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 cnri.reston.va.us.
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: <19950117170145.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-sdr-erp-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sdr-erp-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950117170145.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12114;
18 Jan 95 16:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15506;
18 Jan 95 16:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12100;
18 Jan 95 16:41 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10561;
18 Jan 95 16:02 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ipngwg-icmp-00.txt
Date: Wed, 18 Jan 95 16:01:55 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501181602.aa10561 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IPNG Working Group of the
IETF.
Title : ICMP for the Internet Protocol Version 6 (IPv6)
Author(s) : A. Conta, S. Deering
Filename : draft-ietf-ipngwg-icmp-00.txt
Pages : 18
Date : 01/17/1995
This document specifies a set of Internet Control Message Protocol
(ICMP) messages for use with version 6 of the Internet Protocol
(IPv6). The Internet Group Management Protocol (IGMP) messages
specified in RFC-1112 have been merged into ICMP, for IPv6, and are
included in this document.
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-ipngwg-icmp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-icmp-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-ipngwg-icmp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950117173853.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-icmp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-icmp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950117173853.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00453;
19 Jan 95 3:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00449;
19 Jan 95 3:49 EST
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa01170;
19 Jan 95 3:48 EST
Received: from sdiv.cray.com (daemon at ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id CAA01749; Thu, 19 Jan 1995 02:46:34 -0600
Received: by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA07698; Thu, 19 Jan 1995 02:46:31 -0600
Received: from timbuk.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv)
id AA07603; Thu, 19 Jan 1995 02:46:12 -0600
Received: from ceres.fokus.gmd.de (ceres.fokus.gmd.de [192.35.149.15]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id CAA01722 for <tcplw at cray.com>; Thu, 19 Jan 1995 02:46:11 -0600
Message-Id: <199501190846.CAA01722 at timbuk.cray.com>
Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5);
Thu, 19 Jan 1995 09:34:17 +0100
X-Mailer: exmh version 1.5.3 12/28/94
To: cellular at dfv.rwth-aachen.de, tccc at cs.umass.edu, perform at tay1.dec.com,
end2end-interest at isi.edu, ietf at isi.edu, rem-conf at es.net,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com, cip at bbn.com,
cnom at maestro.bellcore.com, ccrc at dworkin.wustl.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, iplpdn at CNRI.Reston.VA.US,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Henning Schulzrinne <schulzrinne at fokus.gmd.de>
Subject: Infocom'95
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Jan 95 09:34:33 +0100
X-Orig-Sender: schulzrinne at fokus.gmd.de
Content-Length: 6
help
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00477;
19 Jan 95 3:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00473;
19 Jan 95 3:50 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01197;
19 Jan 95 3:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00421;
19 Jan 95 3:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00417;
19 Jan 95 3:45 EST
Received: from ceres.fokus.gmd.de by CNRI.Reston.VA.US id aa01143;
19 Jan 95 3:45 EST
Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5);
Thu, 19 Jan 1995 09:34:17 +0100
X-Mailer: exmh version 1.5.3 12/28/94
To: cellular at dfv.rwth-aachen.de, tccc at cs.umass.edu, perform at tay1.dec.com,
end2end-interest at isi.edu, ietf at isi.edu, rem-conf at es.net,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com, cip at bbn.com,
cnom at maestro.bellcore.com, ccrc at dworkin.wustl.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, iplpdn at CNRI.Reston.VA.US,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Henning Schulzrinne <schulzrinne at fokus.gmd.de>
Subject: Infocom'95
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Jan 95 09:34:33 +0100
X-Orig-Sender: schulzrinne at fokus.gmd.de
Message-ID: <9501190345.aa01143 at CNRI.Reston.VA.US>
help
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04486;
19 Jan 95 12:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04481;
19 Jan 95 12:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09340;
19 Jan 95 12:12 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04458;
19 Jan 95 12:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04454;
19 Jan 95 12:10 EST
Received: from uswat.advtech.uswest.com by CNRI.Reston.VA.US id aa09311;
19 Jan 95 12:10 EST
Received: from atqm.advtech.uswest.com (atqm.advtech.uswest.com [130.13.28.1]) by uswat.advtech.uswest.com (8.6.9/8.6.9) with SMTP id JAA10735; Thu, 19 Jan 1995 09:21:51 -0700
Message-ID: <n1421615039.50783 at atqm.advtech.uswest.com>
Date: 19 Jan 1995 09:11:26 U
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Sandy McCrady <smccrady at atqm.advtech.uswest.com>
Subject: RE- client/server image sof
To: announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com,
ccrc at dworkin.wustl.edu, cellular at dfv.rwth-aachen.de, cip at bbn.com,
cnom at maestro.bellcore.com, end2end-interest at isi.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, Henning Schulzrinne <schulzrinne at fokus.gmd.de>,
hipparch at sophia.inria.fr, icad-request at santafe.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, perform at tay1.dec.com, rem-conf at es.net,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tccc at cs.umass.edu, tcplw at cray.com,
"tf-mm at i4serv.informatik.rwth-aa" <tf-mm at i4serv.informatik.rwth-aachen.de>,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
X-Mailer: Mail*Link SMTP-QM 3.0.1
Reply to: RE: client/server image software
Anyone know any good client/server (UNIX) existing software or something that
could easily be modified that does image/rastor/TIF manipulation (view/zoom,
pan, move around on the screen, print). Need some sort of button/menu control
so it can talk on the back end to a pgm that talks to an ORACLE data base.
(Windows should be MOTIF and maybe use DCE/Encina.)
Any good ideas?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04788;
19 Jan 95 12:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04784;
19 Jan 95 12:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09858;
19 Jan 95 12:33 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04778;
19 Jan 95 12:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04774;
19 Jan 95 12:32 EST
Received: from hplms26.hpl.hp.com by CNRI.Reston.VA.US id aa09845;
19 Jan 95 12:32 EST
Received: from opera.hpl.hp.com by hplms26.hpl.hp.com with SMTP
(1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA04561; Thu, 19 Jan 1995 09:31:00 -0800
Received: from localhost by opera.hpl.hp.com with SMTP
(1.37.109.8/15.5+ECS 3.3+HPL1.1) id AA17451; Thu, 19 Jan 1995 09:30:00 -0800
Message-Id: <9501191730.AA17451 at opera.hpl.hp.com>
To: cellular at dfv.rwth-aachen.de, tccc at cs.umass.edu, perform at tay1.dec.com,
end2end-interest at isi.edu, ietf at isi.edu, rem-conf at es.net,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com, cip at bbn.com,
cnom at maestro.bellcore.com, ccrc at dworkin.wustl.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, iplpdn at CNRI.Reston.VA.US,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
Cc: pitt at hplms26.hpl.hp.com, burak at fokus.gmd.de, ofek at watson.ibm.com
Subject: 7th IEEE LAN/MAN Workshop
Date: Thu, 19 Jan 95 09:29:59 -0800
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Daniel Pitt <pitt at opera.hpl.hp.com>
The deadline is approaching for registration for the 7th IEEE Workshop on
Local and Metropolitan Area Networks, to be held in the Florida Keys March
26-29. Highlights include:
- a rapid-fire technical program of short, pointed talks
- a great keynote speaker, whose wit and insight leave a lasting impression
- an intimate setting conducive to lots of discussion
- unprecedented worldwide participation
- a fabulous location.
Found below are the Workshop announcement, the program, and the registration
materials. You are urged to act immediately; attendance is limited.
============================================================================
Seventh IEEE Workshop on Local and Metropolitan Area Networks
March 26-29, 1995
Hawk's Cay Resort and Marina
Marathon, Florida
Sponsored by the IEEE Communications Society
Local and metropolitan area networks are currently the forging
place for new network technologies, broadband services, and
multimedia applications. The purpose of the present workshop
is to examine the new local ATM technologies, cable and other
public multimedia delivery systems, various networking
architectures, and the provisioning of networks for the support
of broadband multimedia services for businesses and homes.
A main theme of this year's Workshop is public and private ATM
networks: differences and seams.
A prominent feature of this Workshop is its emphasis on short,
pointed presentations with ample opportunities for debate and
discussion. Controversy is encouraged.
Attendance is very limited, so early registration is strongly advised.
The Workshop will be held a week before IEEE INFOCOM'95
which will be in Boston from April 2 to 6, 1995.
The Workshop will begin with an evening reception on March 26.
Technical sessions will begin Monday morning March 27 and conclude
around lunchtime on March 29. The program and registration forms
follow below.
Workshop Committee
------------------
Chair: Yoram Ofek (IBM Watson Research)
e-mail: ofek at watson.ibm.com
phone: 1-914-784-7085 fax: 1-914-784-6205
Program co-chairs: Daniel Pitt (Hewlett-Packard Laboratories)
Markus Burak (GMD FOKUS)
Committee: Anthony Acampora (Columbia University)
Andres Albanese (ICSI)
Joseph Bannister (The Aerospace Corporation)
James Field (University of Waterloo)
Luigi Fratta (Politecnico di Milano)
Mario Gerla (UCLA)
Wolfram Lemppenau (IBM Zurich Research)
Luciano Lenzini (CNR-CNUCE)
Gottfried Luderer (Arizona State University)
Fabio Neri (Politecnico di Torino)
Allyn Romanow (Sun Microsystems)
Izhak Rubin (UCLA)
David Skellern (Macquarie University, Sydney)
Tatsuya Suda (University of California, Irvine)
Csaba Szabo (Technical University of Budapest)
Yutaka Takahashi (Kyoto University)
Nguyen Tat (MATRA)
Fouad Tobagi (Stanford University)
Terry Todd (McMaster University)
Pitro Zafiropulo (IBM Zurich Research)
==============================================================================
-------------------------------------------------------------------------
7th IEEE LAN/MAN Workshop Program
Keynote Speaker
---------------
Howard Salwen, Chairman, Proteon, on how we ended up here and what comes next
----------
Session 1: Medium Access Controls
-"A Full-duplex Ring with a Fairness Cycle Window," T.-J. Kim, ETRI,
Korea; B.-C. Shin, Korea Advanced Institute of Science and Technology,
Korea
-"Pros and Cons of the Global Fairness Algorithms of CRMA-II," M.
Ajmone-Marsan, C. Casetti, F. Neri, Politecnico di Torino, Italy
-"The MetaRing MAC Protocol: Performance Evaluations in an
Interconnected Environment," G. Anastasi, L. Lenzini, Universita di
Pisa, Italy
-"A Distributed Cycle Reset Protocol for High-Speed LAN/MAN," H.-B.
Jeon, S.-H. Lee, S.-Y. Song, TNRL, Korea Telecom, Korea
-"Prototype of an ATM-Based MAN for Multimedia Services," S.-M. Jiang,
G. Pujolle, Universite de Versailles, France
-"DQCA: A New Medium Access Control Protocol for Broadband Networks,"
W. Lu, Universiti Teknologi Malaysia, Malaysia
----------
Session 2: New Legacy LANs, Traffic Characterization, and
Connectionless ATM
-"Message Waiting Times in a LAN Using the Demand-Priority Access
Method," W. Seah, Y. Takahashi, T. Hasegawa, Kyoto University, Japan
-"Interactive Real-Time Communication in Shared-Medium High-Speed
LANs," P. Martini, J. Ottensmeyer, Universitaet Paderborn, Germany
-"Testing Bursty Traffic in an ATM Testbed," L. Cheng, H. D. Hughes,
Michigan State University, USA
-"On the Self-Similar Nature of the Traffic Offered to a MAN," M.
Cinotti, S. Giordano, F. Romani, F. Russo, Universita di Pisa, Italy
-"On Long-Range Dependence in NSFNET Traffic," S. Klivansky, A.
Mukherjee, Georgia Institute of Technology, USA; C. Song, Advantis,
USA
-"Connectionless Traffic Service in ATM Networks," S. Subramaniam, A.
Somani, University of Washington, USA
-"Partial Connections Method for the Support of Ethernet Emulation
over ATM," R. Brown, J. Pihlaja, Nokia, Finland; N. Kavak, Telia
Research, Sweden; A. Meier, IBM, Switzerland
----------
Session 3: Multicasting and Convergence Protocols
-"ACBT: A Scalable Routing Protocol for Receiver-Initiated
Multicasting in ATM Networks," F.-C. Liaw, FORE Systems, USA
-"Providing Protocol Support for Multimedia Broadcasting," S. Beocking,
Siemens AG, Germany; R. Schatzmayr, TU-Berlin, Germany
-"ATM Adaptation Layer and Group Communication Servers for
High-Performance Multipoint Services," G. Carle, Universitaet
Karlsruhe, Germany
-"An Experimental AAL2 Protocol," D. Brooks, S. Srinidhi, Sterling
Software, USA; V. Konangi, Cleveland State University, USA
-"A Cooperative Protocol Stack Supporting High-Priority Traffic in an
ATM Network," E. Klovning, Telenor Research, Norway
-"An Object-Oriented Framework for ATM Interworking and Call Control
Software," A. Scheidegger, University of Washington, USA
----------
Session 4: ATM Experience and Video Transport
-"BATES - BERKOM ATM Technology Evaluation System," D. Elias,
GMD-Fokus, Germany
-"The Art of ATM Testing," F. Schulz, J. Micheel, M. Burak, GMD-Fokus,
Germany
-"Operational Experiences with Fast Packet Technologies in the
Internet Environment," P. Mohta, CERFnet, USA
-"Continuous Media Dissemination over ATM Networks," G. Polyzos,
University of California at San Diego, USA
-"Video Transmission over Lossy Packet Networks," A. Albanese,
International Computer Science Institute, USA
-"Analysis and Modeling of an MPEG-1 Video Source," M. Conti, E.
Gregori, A. Larsson, CNR - Istituto CNUCE, Italy
-"Adaptive Neural Video Compression," C. Cramer, E. Gelenbe, P.
Gelenbe, M. Sungur, Duke University, USA
----------
Session 5: Traffic Management
-"A Bandwidth Allocation Scheme to Support Delay Sensitive Traffic in
a DQDB MAN," J. Vozmediano, Universidad de Sevilla, Spain; E. Vazquez,
J. Berrocal, Universidad Politecnica de Madrid, Spain
-"Scheduling and Admission Control Policies: A Case Study for DQDB and
ATM," K. Steenhaut, K. Degieter, W. Brissinck, Vrije Universiteit
Brussel, Belgium
-"Performance Evaluation of Rate Control in ATM Networks," P. Tse, M.
Zukerman, Telstra Research Laboratories, Australia
-"Best-Effort Statistical Multiplexing of Delay-Tolerant Links in
ATM," M. Mateescu, GMD-Fokus, Germany
-"A Comparison of Per-VC Queueing and Explicit Rate Algorithms for ABR
Traffic," R. Krishnan, Motorola, USA
-"MULTIRING, a Possible Post-ATM Network Architecture," W. Dobosiewicz,
Monmouth College, USA; P. Gburzynski, University of Alberta, Canada
----------
Session 6: Traffic Control and Quality of Service Provision
-"An Adaptive Multi-Service Generic Flow Control Protocol," J.
Macharia, Jomo Kenyata University, Kenya; L.-J. Yao, University of
Adelaide, Australia
-"Packet or Cell Loss Reduction in Networks," V. Srinivasan, E.
Gelenbe, A. Ghanwani, Duke University, USA
-"Provision of Time-Constrained Services in ATM Networks," G.
Mercankosk, Curtin University of Technology, Australia
-"QoS Management for Service Integrated Communication Systems," C. Schmidt,
M. Zitterbart, Universitaet Karlsruhe, Germany
-"QoS Management in a Mobile Multimedia Environment," P. Ray, S. Jha,
A. Seneviratne, University of Technology-Sydney, Australia
-"A Simple Method for Evaluating QoS Parameters," J.-H. Lin, J.-L.
Chen, Industrial Technology Research Institute, Taiwan ROC;
J. Biswas, Institute of Systems Science, Singapore.
-"Architectural Factors in the Provision of Services by Broadband
Customer Premises Equipment," M. Hogan, R. Keaney, E. Wilson, M. Hudson,
M. Bickerstaff, D. Skellern, M. Krischer, Macquarie University, Australia
----------
Session 7: Switching Architecture
-"CellBus: A Flexible Architecture for ATM LANs," D. Upp, P. Goli,
TranSwitch, USA; S. Ghosh, J. Hammond, Clemson University, USA
-"A Fast Algorithm for Scheduling Cells in Input-Queued Switches," N.
McKeown, Stanford University, USA; J. Walrand, Univesity of California
at Berkeley, USA
-"A Multicasting Switch for ATM LAN/MAN," S. Shyamsukha, A. Monster, Temple
University, USA
-"Modular VLSI Implementation Architecture for High-Performance
Communication Support," J. Schiller, M. Zitterbart, Universitaet
Karlsruhe, Germany
-"Performance of Multi-Channel Asymmetric Packet Switch Modules in a
Bursty and Nonuniform Traffic Environment," A. Chatterjee, V. Konangi,
Cleveland State University, USA
-"Analysis of a Class of Telecommunication Models," H. Gail, S.
Hantler, IBM, USA; A. Konheim, University of California at Santa
Barbara, USA; B. Taylor, University of Michigan, USA
----------
Session 8: Network Organization
-"Distributed ATM Switching System for Corporate Communication
Networks," R. Hamidi, J.-P. Quinquis, CNET, France
-"Virtual Networking in ATM LANs and MANs," M. Gerla, S. Fotedar,
University of California at Los Angeles, USA; P. Crocetti, Italtel,
Italy; L. Fratta, Politecnico di Milano, Italy
-"Migrating to ATM in the Local Area," V. Friesen, J. Wong, University
of Waterloo, Canada
-"The Metropolitan Area Community Network," C. Venkatraman, D. Pitt,
Hewlett-Packard Laboratories, USA
-"A MAN Architecture based on a Meshed Network Crossconnect," T.
Kuehnel, G. Luderer, Arizona State University, USA
-"Ring Networks with Random Extra Links," M. Kovacevic, A. Acampora,
Columbia University, USA
-"Virtual Embeddings for Linearization of Arbitrary Topology
Networks," B. Yener, M. Yung, IBM, USA
----------
Session 9: Optical Networking
-"The Use of Wavelength-Selective Couplers in Optical Local Area
Networks," T. Todd, A. Grah, O. Barkovic, McMaster University, Canada
-"Optical Latency Storage - Unifying Data Communication in Space and
Time," T. Pfeifer, Technische Universitaet Berlin, Germany
-"A Scalable Optical Packet Switching Network Architecture," I.
Chlamtac, University of Massachusetts, USA; V. Elek, C. Szabo,
Technical University of Budapest, Hungary; A. Fumagalli, Politecnico
di Torino, Italy
-"An Adaptable Protocol for Processor Interconnection in a WDM-based
Network," P. Dowd, D. Crouse, State University of New York at Buffalo,
USA
-"ISONet: A Dynamically Reconfigurable Integrated Services Optical
Network," T. Bujewski, The Aerospace Corporation, USA; M. Gerla,
University of California at Los Angeles, USA
-"Implementing the DQDB using Wavelength Division Multiplexing," A.
Kamal, H. Hassanein, Kuwait University, Kuwait
-----------
Session 10: Technologies for High Performance, and Wireless ATM
-"Using ATM Networks Effectively for High-Performance Applications,"
A. Guha, W. Franta, Network Systems Corporation, USA
-"Affordable High Performance Computing: Evaluation of Cluster-based
Computing via ATM," P. Dowd, E. Blade, State University of New York at
Buffalo, USA; S. Srinidhi, Sterling Software, USA; R. Claus, NASA
Lewis Research Center, USA
-"Slack-Protocol Design and Performance in Wormhole-Routing Networks,"
J. Bannister, The Aerospace Corporation, USA; M. Gerla, S. Walton,
University of California at Los Angeles, USA
-"Fair Cascades of Fibre Channel Switches," L. Cherkasova, V. Kotov,
T. Rokicki, Hewlett-Packard Laboratories, USA
-"Cut-Through Routing in Intermediate Systems," O. Riebe, Humboldt
Universitaet zu Berlin, Germany
-"ATM Transport and GSM Circuit and Packet Mode Access Networks:
A Platform for Mobile Multimediea of the Immediate Future," S.
Chakraborty, Helsinki University of Technology, Finland
-"Signaling and Mobility Management in a Wireless ATM LAN," M.
Veeraraghavan, M. Karol, AT&T Bell Laboratories, USA
=============================================================================
-------------------------------------------------------------------
7th IEEE Workshop on Local and Metropolitan Area Networks
REGISTRATION FORM
Name: _______________________________
Company/Affiliation: _________________________________
Address: ____________________________________
____________________________________
Tel.: ____________________
Fax.: ___________________
E_Mail: _________________
___ $100 enclosed
in personal check or money order payable to "IEEE WORKSHOP 94"
Mail the check to:
------------------
Yoram Ofek
Workshop Chair
IBM T. J. Watson Research Center
P.O.Box 704
Yorktown Heights, NY 10598
e-mail: ofek at watson.ibm.com
Telephone: (914) 784-7085 FAX: (914) 784-6205
Participants from outside the US,
--------------------------------
can send the 100 Dollar registration via
INTERNATIONAL CABLE (money transfer) directly
---------------------------------------------
to the workshop account:
------------------------
* Routing # 021 000 128
* For Credit to account # 258 500 172 465
* "IEEE 95 WORKSHOP"
* Chemical Bank
* 324 Saw Mill River Rd.
* Elmsford, NY 10523, U.S.A.
=====================================================================
HAWK'S CAY RESORT AND MARINA
REGISTRATION FORM
FOR
7th IEEE WORKSHOP on LOCAL and Metropolitan Area Networks
March 26, 1995 - March 29, 1995
Arrival Date ........... Arrival Time ....... Departure Date ......
(List early arrival/late departure dates, if applicable)
(GROUP RATES MAY NOT BE AVAILABLE TO EARLY ARRIVALS/LATE DEPARTURES)
NAME ....................... SIGNATURE ...........
COMPANY ................... PHONE# ..............
ADDRESS ............................................
CITY ............. STATE ........... ZIP .......
CREDIT CARD TYPE (Circle One) MC VISA DISCOVER DINERS AMEX
CREDIT CARD# ..................... EXPIRATION DATE .............
NAME ON CARD ..................... SIGNATURE ...................
# OF GUESTS IN ROOM (Ages if Children) ...........................
Children 11 and under are free, extra person charge $25.00 per night.
Children ages 4-11 can attend the group dinners
for a non-refundable charge of $50,00 per child.
Will children be attending group dinners? ____ Yes ____ No
Number of Children attending ............. Ages ............
Smoking ................. Non-smoking .........
(Accommodations in each category are limited. We will make every effort
to honor your request, however, it cannot be guaranteed)
ACCOMMODATIONS: Package Rates for 3 nights/4 days
$636,00 per person, based on a single occupancy
$383,00 per person, based on double occupancy
Additional nights are available at $160.00 per room, per night, plus
tax single or double occupancy, including breakfast.
Refunds will not be made on any portion of the IEEE three night package.
Check in time is 3:00 pm/Check out time is 11:00am.
INCLUDED IN RATES:
* Three nights accommodations (March 26-28 nights), inclusive of tax
* Lavish Breakfast Buffet on March 27-29, 1995
* Dinners on March 27 and 28, 1995
* Wine and Cheese Reception, March 26, 1995
* Coffee Breaks during the workshop
* Morning Newspaper
* Transportation to/from Marathon Airport (24 hour notice needed)
* Nightly Turndown Service
* All gratuities, housekeeper, bellman, breakfast and banquet server
* All applicable taxes to the above features
* Dolphin training sessions (three times daily)
___ Please check here if you require vegetarian meals at the group dinners.
Number of people ___
REGISTRATION FORMS MUST BE COMPLETED AND RETURNED TO:
Reservations Department OR FAX TO: Reservations Department
Hawk's Cay Resort and Marina (305) 743-5215
Mile Marker 61, Duck Key
Marathon, FL 33050
1-(800)-432-2242
COMPLETE ONE FORM FOR EACH ROOM NEEDED - A CONFIRMATION WILL BE MAILED
ENTIRE PACKAGE PRICE WILL AUTOMATICALLY BE CHARGED TO YOUR CREDIT CARD
CANCELLATION POLICY IS THIRTY DAYS PRIOR TO ARRIVAL
CANCELLATION WITHIN THIRTY DAYS WILL RESULT IN FORFEITURE OF DEPOSIT.
** RESERVATIONS MUST BE RECEIVED BY FEBRUARY 26, 1995 TO GUARANTEE YOUR ROOM **
** AND TO GUARANTEE THE GROUP RATE FOR YOUR ROOM**
----------------------------------------------------------------------------------
HAWK'S CAY RESORT AND MARINA
Duck Key, Marathon, Florida.
GROUND TRANSPORTATION
---------------------
Rental Cars:
-----------
Budget Rent a Car Avis Rent a Car General Rent a Car
Marathon Airport, FL Marathon Airport, FL Marathon, FL
305-743-3998 305-743-5428 800-327-7607
800-527-0700 305-377-2531 (Miami)
Motor Coach
-----------
A-1 Bus lines Miami Bus & Limo American Meetings and Conventions
Miami, FL Miami, FL Miami Lakes, FL
305-325-1000 305-633-3377 305-621-4181
800-826-6754
Go Tours Grayline Bus Company
Marathon, FL Miami, FL
305-743-9876 305-587-8080
Car Services
------------
Ambassador Limo Service Island Taxi Paradise to Reality & Back
Miami, FL Marathon, FL Miami, FL
305-931-3111 305-743-6004 305-852-4656
800-245-4667
Miami Airport to Hawk's Cay Resort and Marina
---------------------------------------------
Miami International Airport to 836 West until you reach the Florida Turnpike.
Stay South on the Turnpike until it ends at US-1. Continue South
on US-1 to Mile Marker 61 - Hawk's Cay Resort and Marina !!
The drive from Miami International Airport
to Hawks' Cay Resort is an hour and forty five minutes.
It is a beautiful drive, and is described by Rand-McNally as one of the most
scenic drives in the United States, "where the sky and the ocean meet".
HAWK's CAY RESORT PROVIDES COMPLIMENTARY TRANSPORTATION
TO AND FROM THE MARATHON AIRPORT (please give 24 hours notice).
American Airlines 800-433-7300
USAir 800-428-4322
Gulfstream International Airlines 800-992-8532
With expansion of the Marathon Airport (scheduled for
completion November 1994), the capacity
and number of flights will increase.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05705;
19 Jan 95 13:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05699;
19 Jan 95 13:16 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10646;
19 Jan 95 13:16 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05679;
19 Jan 95 13:16 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05096;
19 Jan 95 12:57 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10233;
19 Jan 95 12:56 EST
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-20)
id <AA00308>; Thu, 19 Jan 1995 09:35:58 -0800
Received: from ceres.fokus.gmd.de by quark.isi.edu (5.65c/5.61+local-20)
id <AA15770>; Thu, 19 Jan 1995 09:34:09 -0800
Message-Id: <199501191734.AA15770 at quark.isi.edu>
Received: from ursa.fokus.gmd.de by ceres.fokus.gmd.de with SMTP (PP-ICR1v5);
Wed, 18 Jan 1995 19:09:36 +0100
X-Mailer: exmh version 1.5.3 12/28/94
To: cellular at dfv.rwth-aachen.de, tccc at cs.umass.edu, perform at tay1.dec.com,
end2end-interest at isi.edu, ietf at isi.edu, rem-conf at es.net,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com, cip at bbn.com,
cnom at maestro.bellcore.com, ccrc at dworkin.wustl.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, iplpdn at CNRI.Reston.VA.US,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
Subject: Infocom'95 Conference Program and Registration
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 18 Jan 95 19:09:30 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Henning Schulzrinne <schulzrinne at fokus.gmd.de>
Infocom'95 --- Bringing Information to People
Information about Infocom'95, the Fourteenth Annual Joint Conference
of the IEEE Computer and Communications Societies is available through
the World Wide Web at
http://www.research.att.com/~hgs/infocom95/program.html
Infocom'95 takes place in Boston, April 2 - 6, 1995. Roughly 160
papers selected from 450 submissions will be presented, as well as
panels on satellite communication and resource reservations. The
keynote speaker will be Sandy Fraser, AT&T, with a historical
perspective on the information revolution. The conference opens with
tutorials on integrated service high speed networks (Robert Gallager),
broadband networks and ATM (Anthony Acampora), protocol design (Dave
Clark), wireless personal communications (David Goodman), and the
World Wide Web (David Tennenhouse and others).
----
Henning Schulzrinne email: hgs at fokus.gmd.de
GMD-Fokus phone: +49 30 25499 182
Hardenbergplatz 2 fax: +49 30 25499 202
D-10623 Berlin WWW: http://www.fokus.gmd.de/htbin/info/minos/hgs
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06340;
19 Jan 95 13:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11282;
19 Jan 95 13:49 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06266;
19 Jan 95 13:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06059;
19 Jan 95 13:36 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11063;
19 Jan 95 13:36 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA21443>; Thu, 19 Jan 1995 10:36:35 -0800
Message-Id: <199501191836.AA21443 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1754 on IPATM WG ATM Forum Recommendations V1
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 Jan 95 10:37:38 PST
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1754:
Title: IP over ATM Working Group's
Recommendations for the ATM Forum's Multiprotocol
BOF Version 1
Author: M. Laubach
Date: January 1995
Mailbox: laubach at com21.com
Pages: 7
Characters: 13,483
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1754.txt
This document represents an initial list of requirements submitted to
the ATM Forum's Multiprotocol BOF for the operation of IP over ATM
networks as determined by the IETF IP over ATM Working Group and other
working groups. This RFC is issued for the benefit of community
members. The information contained in this document is accurate as of
the date of publication, but is subject to change. Subsequent RFCs
will reflect such changes. This RFC is a product of the IP over ATM
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-REQUEST at NIC.DDN.MIL.
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: <950119103332.RFC at ISI.EDU>
SEND /rfc/rfc1754.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1754.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950119103332.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06356;
19 Jan 95 13:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06339;
19 Jan 95 13:49 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11283;
19 Jan 95 13:49 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06268;
19 Jan 95 13:49 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06123;
19 Jan 95 13:39 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11117;
19 Jan 95 13:39 EST
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA21599>; Thu, 19 Jan 1995 10:39:27 -0800
Message-Id: <199501191839.AA21599 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1756 on Remote Write Protocol
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 Jan 95 10:40:30 PST
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1756:
Title: REMOTE WRITE PROTOCOL - VERSION 1.0
Author: T. Rinne
Date: January 1995
Mailbox: Timo.Rinne at hut.fi
Pages: 11
Characters: 22,078
Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1756.txt
It is often convenient to use electronic communication somewhat
lighter than electronic mail. Sometimes even the use of the talk(1)
*) program seems like overkill. We like to offer to user something
like UNIX **) command write(1) ***) except that it can also pass
messages through the network instead of the single host. There have
been few programs offering this kind of service, but they have either
based on SUN-RPC protocol or used a strictly undocumented protocol.
This document describes a simple Remote Write Protocol (RWP) that
should have been documented at least 10 years ago. But late is better
than never. Version number of the RWP protocol in this document is
1.0.
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-REQUEST at NIC.DDN.MIL.
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: <950119103754.RFC at ISI.EDU>
SEND /rfc/rfc1756.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1756.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <950119103754.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07230;
19 Jan 95 14:32 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12242;
19 Jan 95 14:32 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07219;
19 Jan 95 14:32 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07105;
19 Jan 95 14:27 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12148;
19 Jan 95 14:27 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07099;
19 Jan 95 14:27 EST
To: IETF-Announce: ;
cc: ietf-asid at umich.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Directory Access Protocols to Draft Standard
Date: Thu, 19 Jan 95 14:27:50 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501191427.aa07099 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Access/Synchronization of the
Internet Directories Working Group to consider the following three
Internet-Drafts for the status of Draft Standard:
1. Lightweight Directory Access Protocol
<draft-ietf-asid-lightdirect-00.txt>
2. The String Representation of Standard Attribute Syntaxes
<draft-ietf-asid-syntaxes-00.txt>
3. A String Representation of Distinguished Names
<draft-ietf-asid-dist-names-00.txt>
The IESG was also requested to consider the following Internet-Draft
for the status of Proposed Standard:
4. Using the OSI Directory to achieve User Friendly Naming
<draft-ietf-asid-user-friendly-dir-00.txt>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
February 2, 1995.
IESG Secretary
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07458;
19 Jan 95 14:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12572;
19 Jan 95 14:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07442;
19 Jan 95 14:41 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07345;
19 Jan 95 14:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: notifications at cs.utk.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-notary-mime-report-01.txt
Date: Thu, 19 Jan 95 14:39:17 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191439.aa07345 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Notifications and
Acknowledgements Requirements Working Group of the IETF.
Title : The Multipart/Report Content Type
for the Reporting of
Mail System Administrative Messages
Author(s) : G. Vaudreuil
Filename : draft-ietf-notary-mime-report-01.txt
Pages : 4
Date : 01/18/1995
This memo defines a generic packaging mechanism for mail system reports.
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-notary-mime-report-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-notary-mime-report-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-notary-mime-report-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 cnri.reston.va.us.
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: <19950118120426.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-notary-mime-report-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-notary-mime-report-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118120426.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07519;
19 Jan 95 14:43 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12609;
19 Jan 95 14:43 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07501;
19 Jan 95 14:43 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07357;
19 Jan 95 14:39 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: notifications at cs.utk.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-notary-status-01.txt
Date: Thu, 19 Jan 95 14:39:23 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191439.aa07357 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Notifications and
Acknowledgements Requirements Working Group of the IETF.
Title : Enhanced Mail System Status Codes
Author(s) : G. Vaudreuil
Filename : draft-ietf-notary-status-01.txt
Pages : 15
Date : 01/18/1995
There currently is not a standard mechanism for the reporting of mail
system errors except for the limited set offered by SMTP and the system
specific text descriptions sent in mail messages.
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-notary-status-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-notary-status-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-notary-status-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 cnri.reston.va.us.
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: <19950118120930.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-notary-status-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-notary-status-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118120930.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07537;
19 Jan 95 14:43 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12617;
19 Jan 95 14:43 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07503;
19 Jan 95 14:43 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07395;
19 Jan 95 14:40 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-robinson-games-overview-00.txt
Date: Thu, 19 Jan 95 14:40:02 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191440.aa07395 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Overview of Game technology
Author(s) : P. Robinson
Filename : draft-robinson-games-overview-00.txt
Pages : 18
Date : 01/18/1995
This document looks at games and their use on computers, where they have
been and where they are going, their relationship to the Internet and its
eventual to communicate for multi-player capability. The document solicits
input on, and proposes creating, a generic standard for game protocols and
other systems that generate real-time and transaction-based traffic.
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-robinson-games-overview-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-robinson-games-overview-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-robinson-games-overview-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950118114627.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-robinson-games-overview-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-robinson-games-overview-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118114627.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07808;
19 Jan 95 14:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07804;
19 Jan 95 14:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12915;
19 Jan 95 14:56 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07787;
19 Jan 95 14:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07783;
19 Jan 95 14:55 EST
Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa12884;
19 Jan 95 14:55 EST
Via: uk.ac.edinburgh.cogsci; Thu, 19 Jan 1995 16:40:32 +0000
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: john at cogsci.edinburgh.ac.uk
Date: Thu, 19 Jan 95 16:40:19 GMT
Message-Id: <28141.9501191640 at ossian.cogsci.ed.ac.uk>
To: cellular at dfv.rwth-aachen.de, tccc at cs.umass.edu, perform at tay1.dec.com,
end2end-interest at isi.edu, ietf at isi.edu, rem-conf at es.net,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com, cip at bbn.com,
cnom at maestro.bellcore.com, ccrc at dworkin.wustl.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, hipparch at sophia.inria.fr,
icad-request at santafe.edu, iplpdn at CNRI.Reston.VA.US,
sig11 at roses.stanford.edu, smds at CNRI.Reston.VA.US, sound at acm.org,
tcplw at cray.com, tf-mm at i4serv.informatik.rwth-aachen.de,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca, schulzrinne at fokus.gmd.de
Subject: Workshop (sorry if you've seen this already)
CALL FOR CONTRIBUTIONS
and Registration Form
This document is also accessible on the Web via the following URL:
http://www.cogsci.ed.ac.uk/~john/IMMI_call/
IMMI-1
First International Workshop on Intelligence and Multimodality in
Multimedia Interfaces: Research and Applications
Human Communication Research Centre
and
EdCAAD, Dept. of Architecture
University of Edinburgh
Edinburgh, Scotland
Thursday 13th - Friday 14th July 1995
Arranged on behalf of:
UK Dept. of Trade and Industry (DTI) Intelligent Systems Integration
Programme: Special Interest Group on Intelligent Interfaces (IISIG)
In cooperation with the AAAI
and in association with The HCI Group (a specialist group of the BCS)
ACL SIGMEDIA
BT
Multimedia is hailed as the next great step forward in interface
technology. But the potential of this technology depends on a
greater understanding of how to exploit it more dynamically and
interactively. Bringing ``intelligence'' into multimedia
interfaces is thus increasingly important. This Workshop seeks
to assess progress and examine pointers for future research and
development directions; it seeks also to highlight issues arising
from experience of real multimedia applications, and hence
encourages industrial participation and reports from practice.
Contributions are invited concerning all kinds of work in the area.
Themes include (but are not restricted to):
* Intelligent guidance for the creation, indexing and presentation
of material stored in multimedia form (as in CD-I).
* The development of techniques to handle presentation and dialogue
involving arbitrary information in different media.
* A focus on the interpretation (semantics) of different channels
of communication, allowing display of the same information in
different ways (often termed ``multimodality'').
* The relationship between multimodal presentation and aspects of
users' tasks (e.g. reasoning, identification, etc.), including
cognitive approaches to multimodal communication.
* Formal methods for specification and reasoning in multimodal
interactive systems.
* A special theme on the integration of natural language and speech
processing technology with interaction using other modalities
such as graphics.
A followup Workshop is proposed, to be held in Cuernavaca, Mexico, in
late 1996, with the intention of further fostering transatlantic links.
Edinburgh, historic capital of Scotland, is one of the most attractive
of European cities. This Workshop will be located in the majestic City
Chambers, less than five minutes' walk from the famous Castle.
University accommodation will be available very close to the venue.
Edinburgh in Summer is invariably host to a wide range of events and
activities, which in 1995 includes for instance the spectacular Tall
Ships Race, due to begin immediately following the Workshop.
Abstracts of approximately 5 pages in length should be submitted
by 14th February 1995 (preferably in electronic form) to:
John Lee
Human Communication Research Centre
University of Edinburgh
2 Buccleuch Place
Edinburgh EH8 9LW
Scotland, UK.
Email: J.Lee at ed.ac.uk
Tel: +44 131 650 4420
Fax: +44 131 650 4587
IMMI-1 URL: http://www.cogsci.ed.ac.uk/~john/IMMI_call/
Requests for further information, registration forms, bookings for
accommodation etc. should be directed to the same address.
A notice of intention to submit an abstract would be appreciated as
early as possible.
Abstracts will be refereed: participation is limited to promote
discussion. Accepted abstracts will be published in the quarterly of
the IISIG ("IIQ": ISSN 1356-3262) and it is intended that selected
authors will be invited to expand their contributions into full-length
papers to be published in book form.
International Programme Committee:
Elisabeth Andre, DFKI, Germany
Noelle Carbonell, CRIN, France
Ernest Edmonds, LUTCHI, UK
Alistair Kilgour, Heriot-Watt University, UK
John Lee, HCRC/EdCAAD, UK
Mark Maybury, Mitre Corp., US
Jon Oberlander, HCRC, UK
Fabio Paterno, CNUCE, Italy
Luis Pineda, IEE, Mexico
Mike Revett, BT, UK
Keith Stenning, HCRC, UK
Michael Wilson, RAL, UK
Kent Wittenburg, Bellcore, US
---------------------------------------------------------------------
REGISTRATION FORM
IMMI-1
1st International Workshop on Intelligence and Multimodality in
Multimedia Interfaces
The Workshop will be held in the Edinburgh City Chambers,
13-14 July 1995
Accommodation is available in Edinburgh University accommodation
buildings at Mylne's Court. This is an excellently converted
tenement building in the heart of the 18th-century Old Town of
Edinburgh, offering a choice of single or twin rooms. It is located
very close to the Castle, and about 3 minutes' walk from the Workshop
venue. Bed and breakfast will cost 19.95 pounds (sterling) per night.
Car parking is unfortunately not easy. Rooms will be available over
the weekend for those who wish to extend their stay.
Early registration is highly advisable for the University accommodation,
due to the limited number of rooms available (especially single rooms).
There is also a range of high-quality hotels in the city centre, within
easy access of the venue (details can be supplied).
The Workshop Fee, which includes preprints etc., lunches and a social
event, but not accommodation, is 100 pounds (sterling). There is a
discount of 20% for students and members of the BCS HCI Group.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please complete the following details for Registration at IMMI-1:
Name:
Address:
Post/Zip code:
Telephone:
FAX:
Email:
Registration fee = 100 pounds sterling (or with 20% discount = 80
pounds, if student or HCI Group member -- please enclose evidence).
Cheques, money orders etc. in sterling to be payable to the University
of Edinburgh.
I wish to reserve University accommodation (Mylne's Court) _____ (yes/no)
If "yes": Number of rooms required: _____ (single) _____ (twin)
Nights required (mark as applicable):
Wed. 13th
Thurs. 14th
Fri. 15th
Sat. 16th
Other (please specify)
Please send completed form and Registration Fee to:
John Lee
Human Communication Research Centre
University of Edinburgh
2 Buccleuch Place
Edinburgh EH8 9LW
Scotland, UK.
Email: J.Lee at ed.ac.uk
Tel: +44 131 650 4420
Fax: +44 131 650 4587
A copy of this registration form is also available via the IMMI-1 URL:
http://www.cogsci.ed.ac.uk/~john/IMMI_call/
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08696;
19 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13932;
19 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08665;
19 Jan 95 15:37 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08341;
19 Jan 95 15:29 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-kastenholz-loki-00.txt
Date: Thu, 19 Jan 95 15:29:38 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191529.aa08341 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A Profile for the Transmission of Video Data over RTP
Author(s) : F. Kastenholz
Filename : draft-kastenholz-loki-00.txt
Pages : 43
Date : 01/18/1995
This document presents the specification for Loki, a profile
to carry video traffic over RTP[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-kastenholz-loki-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kastenholz-loki-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-kastenholz-loki-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950118174713.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-kastenholz-loki-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kastenholz-loki-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118174713.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08714;
19 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13939;
19 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08667;
19 Jan 95 15:37 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08306;
19 Jan 95 15:29 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-relative-url-04.txt
Date: Thu, 19 Jan 95 15:29:24 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191529.aa08306 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Relative Uniform Resource Locators
Author(s) : R. Fielding
Filename : draft-ietf-uri-relative-url-04.txt
Pages : 11
Date : 01/18/1995
A Uniform Resource Locator (URL) is a compact representation of the
location and access method for a resource available via the Internet. When
embedded within a base document, a URL in its absolute form may contain a
great deal of information which is already known from the context of that
base document's retrieval, including the scheme, network location, and
parts of the url-path. In situations where the base URL is well-defined
and known to the parser (human or machine) it is useful to be able to embed
URL references which inherit that context rather than re-specifying it in
every instance. This document defines the syntax and semantics for such
Relative Uniform Resource Locators.
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-uri-relative-url-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-relative-url-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-relative-url-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950118172505.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-relative-url-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-relative-url-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118172505.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08739;
19 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13953;
19 Jan 95 15:37 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08669;
19 Jan 95 15:37 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08322;
19 Jan 95 15:29 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-edi-mime-02.txt, .ps
Date: Thu, 19 Jan 95 15:29:33 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191529.aa08322 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME Encapsulation of EDI Objects
Author(s) : D. Crocker
Filename : draft-ietf-edi-mime-02.txt, .ps
Pages : 9
Date : 01/18/1995
Electronic Data Interchange (EDI) provides a means of conducting structured
transactions between trading partners. The delivery mechanism for these
types of transactions in a paper world has been the postal system, so it is
to be expected that electronic mail would serve as a natural delivery
mechanism for electronic transactions. This specification permits
formatted electronic business interchanges to be encapsulated within MIME
messages [Bore92]. For the specification effort, the basic building block
from EDI is an interchange.
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-edi-mime-02.txt".
Or
"get draft-ietf-edi-mime-02.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-edi-mime-02.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-edi-mime-02.txt".
Or
"FILE /internet-drafts/draft-ietf-edi-mime-02.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 cnri.reston.va.us.
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: <19950118163533.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-edi-mime-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-edi-mime-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118163533.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10910;
19 Jan 95 17:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16174;
19 Jan 95 17:08 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10892;
19 Jan 95 17:08 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10656;
19 Jan 95 17:03 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-metzger-ah-00.txt
Date: Thu, 19 Jan 95 17:03:49 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191703.aa10656 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv4 Authentication Header (4AH)
Author(s) : P. Metzger, W. Simpson
Filename : draft-metzger-ah-00.txt
Pages : 8
Date : 01/18/1995
This document describes an authentication mechanism for IPv4, by inserting
an intervening header between the IPv4 Header and any transport headers.
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-metzger-ah-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-metzger-ah-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-metzger-ah-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950118175959.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-metzger-ah-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-metzger-ah-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118175959.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10957;
19 Jan 95 17:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16197;
19 Jan 95 17:09 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10943;
19 Jan 95 17:09 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10749;
19 Jan 95 17:05 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-metzger-esp-00.txt
Date: Thu, 19 Jan 95 17:05:30 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191705.aa10749 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IPv4 Encapsulating Security Payload (4ESP)
Author(s) : P. Metzger, W. Simpson
Filename : draft-metzger-esp-00.txt
Pages : 9
Date : 01/18/1995
This document describes a privacy mechanism for IPv4, encapsulating
transport headers within an opaque envelope.
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-metzger-esp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-metzger-esp-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-metzger-esp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950118175417.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-metzger-esp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-metzger-esp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118175417.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11001;
19 Jan 95 17:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16244;
19 Jan 95 17:10 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10981;
19 Jan 95 17:10 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10805;
19 Jan 95 17:06 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-metzger-esp-des-cbc-00.txt
Date: Thu, 19 Jan 95 17:06:03 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191706.aa10805 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The ESP DES-CBC Transform
Author(s) : P. Metzger, W. Simpson
Filename : draft-metzger-esp-des-cbc-00.txt
Pages : 6
Date : 01/17/1995
This document describes the DES-CBC security transform for the
Encapsulating Security Payload (ESP).
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-metzger-esp-des-cbc-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-metzger-esp-des-cbc-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-metzger-esp-des-cbc-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950118175102.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-metzger-esp-des-cbc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-metzger-esp-des-cbc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118175102.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11649;
19 Jan 95 17:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16912;
19 Jan 95 17:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11637;
19 Jan 95 17:41 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10703;
19 Jan 95 17:04 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-metzger-ah-md5-00.txt
Date: Thu, 19 Jan 95 17:04:57 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501191704.aa10703 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Authentication with Keyed MD5
Author(s) : P. Metzger, W. Simpson
Filename : draft-metzger-ah-md5-00.txt
Pages : 4
Date : 01/18/1995
This document describes the use of MD5 with the IPv4 Authentication Header.
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-metzger-ah-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-metzger-ah-md5-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-metzger-ah-md5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950118175819.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-metzger-ah-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-metzger-ah-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950118175819.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14469;
19 Jan 95 21:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14465;
19 Jan 95 21:55 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21735;
19 Jan 95 21:55 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14455;
19 Jan 95 21:54 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14451;
19 Jan 95 21:54 EST
Received: from harry.lloyd.com by CNRI.Reston.VA.US id aa21680;
19 Jan 95 21:54 EST
Received: from [158.222.1.3] by lloyd.com with smtp
(Smail3.1.29.1 #4) id m0rV9TA-0006IQC; Thu, 19 Jan 95 18:53 PST
Message-Id: <m0rV9TA-0006IQC at lloyd.com>
X-Sender: brian at harry.lloyd.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Jan 1995 18:53:00 -0800
To: Sandy McCrady <smccrady at atqm.advtech.uswest.com>,
announcements.chi at xerox.com, arl at arl1.wustl.edu, atm at bbn.com,
ccrc at dworkin.wustl.edu, cellular at dfv.rwth-aachen.de, cip at bbn.com,
cnom at maestro.bellcore.com, end2end-interest at isi.edu, enternet-ec at bbn.com,
enternet at bbn.com, f-troup at aurora.cis.upenn.edu, g-troup at dworkin.wustl.edu,
globecom at signet.com.sg, Henning Schulzrinne <schulzrinne at fokus.gmd.de>,
hipparch at sophia.inria.fr, icad-request at santafe.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, perform at tay1.dec.com, rem-conf at es.net,
sig11 at roses.stanford.edu, sigmedia at bellcore.com, smds at CNRI.Reston.VA.US,
sound at acm.org, tccc at cs.umass.edu, tcplw at cray.com,
"tf-mm at i4serv.informatik.rwth-aa" <tf-mm at i4serv.informatik.rwth-aachen.de>,
uist.chi at xerox.com, xtp-relay at cs.concordia.ca
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brian Lloyd <brian at lloyd.com>
Subject: Re: RE- client/server image sof
At 9:11 1/19/95 +0000, Sandy McCrady wrote:
> Reply to: RE: client/server image software
>
>Anyone know any good client/server (UNIX) existing software or something that
>could easily be modified that does image/rastor/TIF manipulation (view/zoom,
>pan, move around on the screen, print). Need some sort of button/menu control
>so it can talk on the back end to a pgm that talks to an ORACLE data base.
>(Windows should be MOTIF and maybe use DCE/Encina.)
>
>Any good ideas?
Try xv. We run it on our Suns under generic X11R5. It can accept a number
of image formats in and it generates a bunch out, including postscript for
driving laser printers. It lets you crop, scale, change aspect ratio
(stretch), modify color maps, modify intensity and chroma transfer
functions, etc. I use it to generate false color images and do image
enhancement. It was especially useful in processing lunar terminator
images from Clementine.
Brian Lloyd, President Lloyd Internetworking
brian at lloyd.com 3031 Alhambra Dr, Suite 102
http://www.lloyd.com Cameron Park, CA 95682
(916) 676-1147 - voice (916) 676-3442 - fax
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03437;
20 Jan 95 11:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03432;
20 Jan 95 11:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07280;
20 Jan 95 11:15 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <KAA23241 at pad-thai.cam.ov.com>; Fri, 20 Jan 1995 10:12:15 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA21709; Fri, 20 Jan 95 10:09:26 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA10916; Fri, 20 Jan 95 06:56:12 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA09681; Fri, 20 Jan 95 09:56:35 -0500
Message-Id: <9501201456.AA09681 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 20 Jan 95 09:56:35 EST
Date: Fri, 20 Jan 95 09:56:35 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 20-Jan-1995 0854" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: GSSAPI out-of-sequence indications
Currently RFC 1509 is a bit vague (and possibly self-contradicting) in its
description of what the various out-of-order delivery indication flags mean, as
returned by gss_unseal and gss_verify (gss_unwrap and gss_verify_mic [or
whatever they're called these days]). I think this needs to be clarified in
the next version, so here's a stab at tying down the semantics of these flags a
bit better.
There are three generic ways I can think of that mechanisms might implement
token sequencing - by attaching a timestamp to each token, by using sequence
numbers, or by using crypto-chaining. Are there any others? I don't know of
any existing mechanisms that use timestamps or crypto-chaining, but I don't
think we should prohibit such mechanisms from using GSSAPI.
I think we have to consider the three classes of mechanism separately, since
they have different properties. However, I'd like to see the flag bits have
the same meaning to both types of mechanism where possible.
1) Sequence-numbering mechanisms.
GSS_S_UNSEQ_TOKEN should be returned whenever a token is received whose
sequence number is different from that expected, irrespective of whether
the received token's number is smaller or larger than that expected.
GSS_S_OLD_TOKEN can be used to indicate that the received token sequence
number was smaller than expected; UNSEQ_TOKEN without OLD_TOKEN implies a
gap in the received tokens. Alternatively, OLD_TOKEN could be reserved to
indicate a token that is too old to determine whether it's a duplicate or
not - what do people think?
Note that if the mechanism employs sequence numbers that wrap, receipt of
a very old token may be indistinguishable from receipt of a token far
ahead of that expected. This probably isn't a problem in practice.
GSS_S_DUPLICATE_TOKEN (probably in conjunction with UNSEQ_TOKEN and
possibly OLD_TOKEN) should be used if the mechanism has detected that
the presented token has already been processed; however a mechanism may
not be able to guarantee 100% detection of duplicates, especially if
many tokens have been processed between the original and duplicate are
processed.
How the receipt of an out-of-order token changes (or doesn't change) the
next sequence number that the mechanism expects is up to the mechanism (or
is it resonable to specify that a mechanism should never decrease its
expected sequence number?)
2) Timestamp-based mechanisms
This type of mechanism can't really detect dropped messages. It can only
detect messages that are received after a later message has been processed.
If for sequence-number mechanisms we use OLD_TOKEN to indicate that a
token has a lower sequence number than expected, then a timestamp-based
mechanism should return both UNSEQ_TOKEN and OLD_TOKEN to indicate a
dropped token; If the sequence-number mechanism reserves OLD_TOKEN to
mean "so old that duplicate detection won't work", then we should only
return UNSEQ_TOKEN for mis-ordered messages.
If the mechanism maintains a window of recently-received timestamps, then
it can also detect duplicate tokens within the window, so DUPLICATE_TOKEN
may also be returned.
If the mechanism sets an expiration time on its tokens, a return status of
GSS_S_OLD_TOKEN alone (without GSS_S_UNSEQ_TOKEN) can be used to indicate
that a token has expired.
3) Crypto-chaining mechanisms
This type of mechanism can only really tell if a given token is the one
that was expected; if not then the only option is to return UNSEQ_TOKEN
(and then only if the token MIC can be verified out-of-sequence).
I quite like the idea of reserving OLD_TOKEN to mean "really old" - i.e.
"expired" for timestamp-based mechanisms, and "outside the window" for
sequence-number mechanisms.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04052;
20 Jan 95 11:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04048;
20 Jan 95 11:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa07890;
20 Jan 95 11:51 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA24370 at pad-thai.cam.ov.com>; Fri, 20 Jan 1995 11:05:37 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA27884; Fri, 20 Jan 95 11:02:48 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA15966; Fri, 20 Jan 95 07:54:35 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA13272; Fri, 20 Jan 95 10:54:56 -0500
Message-Id: <9501201554.AA13272 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 20 Jan 95 10:54:56 EST
Date: Fri, 20 Jan 95 10:54:56 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 20-Jan-1995 1042" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@in.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Anonymous authentication
One authentication style that GSSAPI doesn't currently support is the
oxymoronic "anonymous authentication". This style of authentication allows the
establishment of a context (for use with confidentiality and/or integrity
protection), and possibly authentication of the server to the client, but not
client->server.
I think that GSSAPI can support this facility (when running over mechanisms
that provide it) by adding an additional bit to the req_flags parameter of
gss_init_sec_context() and the ret_flags parameter of both
gss_init_sec_context() and gss_accept_sec_context(). Used in req_flags, this
flag would be a request for anonymous authentication. If the mechanism
supports anonymity, it will set the bit in the ret_flags argument from both
init_sec_context and accept_sec_context.
In addition to defining one extra bit, the mechanism should define a name value
that it can return via the src_name parameter of gss_accept_sec_context to mean
"Anonymous". Doing this will mean that context-acceptors that don't expect
anonymous access won't break if they don't check the anonymous bit in the
ret_flags argument and try to pass the returned src_name to gss_display_name()
or gss_compare_names().
I'd also like to add text to the next revision of RFC-1509 that explicitly says
that undefined bits in ret_flags arguments must be set to zero by GSSAPI
implementations, and that non-zero undefined req_flags bits should be ignored.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05616;
20 Jan 95 13:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05612;
20 Jan 95 13:09 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09415;
20 Jan 95 13:09 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA26364 at pad-thai.cam.ov.com>; Fri, 20 Jan 1995 12:14:18 -0500
Received: from Sun.COM by MIT.EDU with SMTP
id AA07298; Fri, 20 Jan 95 12:11:30 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA05234; Fri, 20 Jan 95 09:10:10 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA01278; Fri, 20 Jan 95 09:09:58 PST
Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id JAA00571; Fri, 20 Jan 1995 09:10:05 -0800
Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4)
id JAA01880; Fri, 20 Jan 1995 09:09:51 -0800
Date: Fri, 20 Jan 1995 09:09:51 -0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Nessett <Danny.Nessett at eng.sun.com>
Message-Id: <199501201709.JAA01880 at elrond.ss-eng.eng.sun.com>
To: cat-ietf at mit.edu, wray at tuxedo.enet.dec.com
Subject: Re: GSSAPI out-of-sequence indications
Cc: Hemma.Prafullchandra at eng.sun.com
X-Sun-Charset: US-ASCII
John,
The imprecise definitions of the status codes you cite should be corrected
and I support this. However, there is a larger problem with sequence number
processing that also requires attention. It is a problem that exists not only
in GSSAPI, but in the Kerberos V5 GSSAPI library and potentially in other
mechanism libraries.
Currently, the GSSAPI spec assumes that the GSSAPI implementation provides
sequence number processing, both in generating a sequence number and in checking
whether it is correct on arrival. The current GSSAPI library for Kerberos V5
generates a sequence number of 0 when init_sec_context() is called. This is
necessary since krb5_mk_priv() and krb5_mk_safe(), the cognates of gss_seal()
and gss_sign(), take a sequence number as input. The Kerberos mechanism is
somewhat asymmetric in this regard, since krb5_rd_priv() and krb5_rd_safe() both
check this sequence number to ensure it is one more than the last one received.
Consequently, sequence number management in Kerberos V5 is a combined activity
shared by both the application and the Kerberos V5 library. The Kerberos GSSAPI
interface, by virtue of its lack of a sequence number argument in either
gss_sign()/gss_verify() or gss_seal()/gss_unseal(), hides all sequence number
processing from the application.
While in some situations the provision of sequence number processing in the
underlying library is the correct tactic, there are significant cases where
it is wrong. One that we at Sun have encountered, albeit using a non-GSSAPI
based mechanism, is processing of RPC requests by multi-threaded clients.
Our security mechanism is interested only in detecting replayed requests,
since individual RPC messages are independent and need not arrive in order.
We use a timestamp and check to ensure the timestamp in a given request is
later than the last timestamp received.
This mechanism fails to work properly in multi-threaded environments, since
the order in which RPC messages are sent is not necessarily the order in which
they are timestamped. Similarly, the order in which they are processed by
a multi-threaded server is not necessarily the order in which they are
timestamped. Consequently, requests can be rejected when they are not replays.
This problem will also exist for sequence number based mechanisms. Thus,
to handle multi-threaded environments, a simple check of the form "is the
sequence number in this message one more than the last received" doesn't
work.
This is but one example of when sequence number checking by the GSSAPI
implementation fails. Other potential situations come to mind, for example,
replay detection of real-time video packets that arrive over multi-path
networks. This probably works best with a timestamped based mechanism, but
one that can adjust its "valid interval" timestamp bounds based on
characteristics of the transport medium.
These situations suggest to me that both GSSAPI and the underlying mechanisms
should at least provide the option of the application handling sequence
number and/or timestamp management itself. This would mean changing the
GSSAPI definition to allow the provision of a sequence number/timestamp
on each gss_sign() and gss_seal() call and the return of the sequence
number/timestamp carried by a token by each gss_verify() and gss_unseal() call.
Regards,
Dan Nessett
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06136;
20 Jan 95 13:39 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09947;
20 Jan 95 13:39 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06091;
20 Jan 95 13:39 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05658;
20 Jan 95 13:12 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-idr-idrp-v6-01.txt
Date: Fri, 20 Jan 95 13:12:06 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501201312.aa05658 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Inter-Domain Routing Working
Group of the IETF.
Title : IDRP for IPv6
Author(s) : Y. Rekhter, P. Traina
Filename : draft-ietf-idr-idrp-v6-01.txt
Pages : 22
Date : 01/19/1995
IDRP [5] is defined as the protocol for exchange of Inter-Domain routing
information between routers to support forwarding of ISO 8473
(Connectionless Network Layer Protocol (CLNP))[6] packets.
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-idr-idrp-v6-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-idrp-v6-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-idr-idrp-v6-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 cnri.reston.va.us.
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: <19950119153302.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-idr-idrp-v6-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-idr-idrp-v6-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950119153302.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07719;
20 Jan 95 15:01 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11518;
20 Jan 95 15:01 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07709;
20 Jan 95 15:01 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07533;
20 Jan 95 14:54 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11371;
20 Jan 95 14:54 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07527;
20 Jan 95 14:54 EST
To: IETF-Announce: ;
cc: ietf-edi at byu.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: MIME Encapsulation of EDI Objects to Proposed Standard
Date: Fri, 20 Jan 95 14:54:41 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501201454.aa07527 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Electronic Data Interchange
Working Group to consider "MIME Encapsulation of EDI Objects"
<draft-ietf-edi-mime-02.txt, .ps> for the status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
February 3, 1995.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09024;
20 Jan 95 16:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09016;
20 Jan 95 16:12 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12973;
20 Jan 95 16:12 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08988;
20 Jan 95 16:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08846;
20 Jan 95 16:08 EST
Received: from rip.psg.com by CNRI.Reston.VA.US id aa12880; 20 Jan 95 16:08 EST
Received: by rip.psg.com (Smail3.1.29.1 #1)
id m0rVQZW-00030eC; Fri, 20 Jan 95 13:08 PST
Message-Id: <m0rVQZW-00030eC at rip.psg.com>
Date: Fri, 20 Jan 95 13:08 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Randy Bush <randy at psg.com>
To: namedroppers <namedroppers at internic.net>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: 95.02.08 dnsind dynupd : location revealed
The location of the 8 Feb 08:30 meeting has been revealed. Stanford
University, Durand 301. A <gasp> paper map is being sent to me. I
can try to get it scanned in and webbable if folk feel that would be
helpful.
The meeting may be voicecast (i.e. a speakerphone) courtesy of DEC.
Folk who can not attend and can foot the bill for joining a loooong
conference call should contact me.
Please remember, the subject is strictly Dynamic Update, and all will
be expected to have done their homework.
randy
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09891;
20 Jan 95 17:07 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09884;
20 Jan 95 17:07 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa14071;
20 Jan 95 17:07 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <QAA01405 at pad-thai.cam.ov.com>; Fri, 20 Jan 1995 16:04:17 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA06615; Fri, 20 Jan 95 16:01:28 EST
Received: from dun-dun-noodles.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <QAA01400 at pad-thai.cam.ov.com>; Fri, 20 Jan 1995 16:04:14 -0500
Received: by dun-dun-noodles.cam.ov.com (4.1/4.7) id AA00279; Fri, 20 Jan 95 16:04:12 EST
Message-Id: <9501202104.AA00279 at dun-dun-noodles.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 20-Jan-1995 1042" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
Subject: Re: Anonymous authentication
In-Reply-To: Your message of "Fri, 20 Jan 1995 10:54:56 EST."
<9501201554.AA13272 at us1rmc.bb.dec.com>
Date: Fri, 20 Jan 1995 16:04:11 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> I think that GSSAPI can support this facility (when running over
>> mechanisms that provide it) by adding an additional bit to the
>> req_flags parameter of gss_init_sec_context() and the ret_flags
>> parameter of both gss_init_sec_context() and gss_accept_sec_context().
>> Used in req_flags, this flag would be a request for anonymous
>> authentication. If the mechanism supports anonymity, it will set the
>> bit in the ret_flags argument from both init_sec_context and
>> accept_sec_context.
>> In addition to defining one extra bit, the mechanism should define a
>> name value that it can return via the src_name parameter of
>> gss_accept_sec_context to mean "Anonymous". Doing this will mean that
>> context-acceptors that don't expect
I don't think you need to change the API at all. Define a new name
type for anonymous "names". To do anonymous authentication, one would
acquire a credential with the anonymous name type, and use that with
gss_initiate_sec_context(). If the mechanism doesn't support
anonymous authentication, this will fail with GSS_S_BAD_NAMETYPE.
Similarly, gss_accept_sec_contect() would return an anonymous name if
the initiator used one.
>> I'd also like to add text to the next revision of RFC-1509 that
>> explicitly says that undefined bits in ret_flags arguments must be set
>> to zero by GSSAPI implementations, and that non-zero undefined
>> req_flags bits should be ignored.
This seems like a good idea.
Marc
P.S. John, you really need to get your mailer fixed :-)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21269;
21 Jan 95 1:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21263;
21 Jan 95 1:21 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22051;
21 Jan 95 1:21 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21251;
21 Jan 95 1:21 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa21209;
21 Jan 95 1:17 EST
Received: from rip.psg.com by CNRI.Reston.VA.US id aa21978; 21 Jan 95 1:17 EST
Received: by rip.psg.com (Smail3.1.29.1 #1)
id m0rVZ9D-00031wC; Fri, 20 Jan 95 22:18 PST
Message-Id: <m0rVZ9D-00031wC at rip.psg.com>
Date: Fri, 20 Jan 95 22:18 PST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Randy Bush <randy at psg.com>
To: namedroppers <namedroppers at internic.net>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: map for dnsind/dynupd 95.02.08
"Roland J. Schemers III" <schemers at slapshot.Stanford.EDU> was kind enough to
send the following reference: http://www.stanford.edu/map/campus-map.html.
Durand is about 5.2 C.0, just WSW of the Main Quad. Note the map has SW
being 'up'.
randy
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01089;
23 Jan 95 6:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01083;
23 Jan 95 6:52 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03087;
23 Jan 95 6:52 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01065;
23 Jan 95 6:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00977;
23 Jan 95 6:35 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02883;
23 Jan 95 6:35 EST
Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA24365>; Mon, 23 Jan 1995 03:36:05 -0800
Received: from trane.uninett.no by relay1.UU.NET with SMTP
id QQxzxm19344; Mon, 23 Jan 1995 06:35:56 -0500
Received: by trane.uninett.no id AA06101
(5.67b/IDA-1.5 for info-ietf at uunet.uu.net); Mon, 23 Jan 1995 12:35:49 +0100
To: info-ietf at uunet.uu.net
Path: uninett.no!hta
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Harald T. Alvestrand" <hta at uninett.no>
Newsgroups: info.ietf
Subject: IETF logo?
Date: 23 Jan 1995 11:35:47 GMT
Organization: Uninett
Lines: 10
Distribution: world
Message-Id: <3g04aj$5uj at trane.uninett.no>
Nntp-Posting-Host: domen.uninett.no
Who knows where I can get an online copy of the IETF logo that was
presented in Seattle?
--
Harald Tveit Alvestrand
Harald.T.Alvestrand at uninett.no
G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
http://domen.uninett.no/~hta/
+47 73 59 70 94
My son's name is Torbjxrn. The letter between "j" and "r" is o with a slash.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02216;
23 Jan 95 9:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02212;
23 Jan 95 9:33 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa05615;
23 Jan 95 9:33 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA00260 at pad-thai.cam.ov.com>; Mon, 23 Jan 1995 08:51:12 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA21707; Mon, 23 Jan 95 08:48:25 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA25388; Mon, 23 Jan 95 05:43:49 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA02515; Mon, 23 Jan 95 08:44:13 -0500
Message-Id: <9501231344.AA02515 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 23 Jan 95 08:44:13 EST
Date: Mon, 23 Jan 95 08:44:13 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 23-Jan-1995 0820" <wray at tuxedo.enet.dec.com>
To: marc at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at cam.ov.com
Subject: Re: Anonymous authentication
>I don't think you need to change the API at all. Define a new name
>type for anonymous "names". To do anonymous authentication, one would
>acquire a credential with the anonymous name type, and use that with
>gss_initiate_sec_context(). If the mechanism doesn't support
>anonymous authentication, this will fail with GSS_S_BAD_NAMETYPE.
>
>Similarly, gss_accept_sec_contect() would return an anonymous name if
>the initiator used one.
I don't really see why an application should need different credentials to
establish anonymous contexts. In fact, the underlying mechanism might require
a real non-anonymous credential. For example, consider a public-key mechanism.
To establish an anonymous session, the initiator might encrypt a symmetric key
under the target's public-key, and then take the target's use of that key as
proof of the target's identity. This requires that the initiator establish
trust in the target's public key. The standard way to do this is to use
certificates, and one possible trust model (the DASS model) is to start from
the initiator's key and walk the certificate space from there. To be able to
do this, the mechanism on the initiator's side would have to have a valid
credential for the initiator - one that isn't anonymous.
In general I would expect that the initiator's mechanism would need to know the
initiator's identity in order to construct a valid authentication token.
Requesting anonymous authentication should just prevent that identity
information from being passed to the context-acceptor.
There may also be a not-insignificant cost incurred by some mechanisms in
acquiring credentials (in the public-key example above, initiator credential
acquisition might well pre-verify the chain of certificates from the initiator
up to the name-space root).
One problem with introducing a new name type is that it requires that all
mechanisms that provide anonymous authentication support this name-type (along
with a corresponding string syntax that gss_display/_import_name() can use).
If anonymous authentication is already built in to a given mechanism, there's a
good chance that the mechanism already has at least a string-syntax defined to
mean "anonymous", presumably a syntax that fits into the mechanism's existing
name-space. There doesn't seem any reason to burden the mechanism or the
GSSAPI implementation with the introduction of an additional name-type, and the
recognition of the value that means "anonymous", just so it can be presented to
the application as a distinct name-type.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02619;
23 Jan 95 10:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02615;
23 Jan 95 10:14 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06367;
23 Jan 95 10:14 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <JAA01252 at pad-thai.cam.ov.com>; Mon, 23 Jan 1995 09:39:48 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA26078; Mon, 23 Jan 95 09:37:00 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <JAA01245 at pad-thai.cam.ov.com>; Mon, 23 Jan 1995 09:39:41 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA14046; Mon, 23 Jan 95 09:39:39 EST
Message-Id: <9501231439.AA14046 at winkl.cam.ov.com>
To: jis at mit.edu
Cc: linn at cam.ov.com, cat-ietf at mit.edu
Subject: Draft of revised CAT WG charter statement
Date: Mon, 23 Jan 1995 09:39:38 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Jeff,
Reflecting several comments I've received from individual WG members,
I'd like to propose the attached as a revision to the CAT WG charter.
One comment: parallelism between work on the GSS-V2 draft and the
negotiated mechanism creates a risk; if the negotiated mechanism
implies any changes to the base spec, these need to be constrained and
identified quickly.
--jl
-----------draft revised charter attached-----------
Common Authentication Technology (cat)
--------------------------------------
Charter
Current status: active working group
Chair(s):
John Linn <john.linn at ov.com>
Security Area Director(s):
Jeffrey Schiller <jis at mit.edu>
Mailing lists:
General Discussion:cat-ietf at mit.edu
To Subscribe: cat-ietf-request at mit.edu
Archive: [TBS]
Description of Working Group:
The goal of the Common Authentication Technology Working Group is to
provide strong authentication, integrity, and confidentiality services
to a variety of protocol callers in a manner which insulates those
callers from the specifics of underlying security mechanisms. We
anticipate future work in extensions to support authorization
services and for facilities to protect store-and-forward messaging.
By separating security implementation tasks from the tasks of
integrating security data elements into caller protocols, those tasks
can be partitioned and performed separately by implementors with
different areas of expertise. This provides leverage for the IETF
community's security-oriented resources, and allows protocol
implementors to focus on the functions their protocols are designed to
provide rather than on characteristics of security mechanisms. CAT
seeks to encourage uniformity and modularity in security approaches,
supporting the use of common techniques and accommodating evolution of
underlying technologies.
In support of these goals, the working group pursues several
interrelated tasks. We have defined a common service interface
allowing callers to invoke security services, and a common security
token format, incorporating means to identify the mechanism type in
conjunction with which security data elements should be interpreted.
We are currently working on a revision to these documents ("GSS-V2")
in response to implementation experience.
In addition to interface and token framing issues, the CAT Working
Group also works towards agreements on suitable underlying mechanisms
to implement security functions; Kerberos V5 and Simple Public-Key
Mechanism (SPKM) proposals are discussed in currently active Proposed
Standards and Internet-Drafts, with a prior public-key proposal
(Distributed Authentication Security Services (DASS)) documented in an
Informational RFC.
The CAT Working Group also consults with other IETF working groups
responsible for candidate caller protocols, pursuing and supporting
design refinements as appropriate. FTP Security is a particular
integration example; preparation of this specification has proceeded
within the CAT WG.
Goals and Milestones (as of January 1995):
Done: Standards-track RFCs 1508 and 1509, Internet-Drafts on GSS-V2,
Kerberos V5 GSS-API Mechanism, SPKM, IOP, Kerberos One-Time
Password integration, and FTP Security.
Jan 95: Agree on revision to WG charter and on scope of GSS-V2
changes vs. issues to be deferred for later consideration.
Jan 95: Issue Internet-Draft proposal re GSS-API Windows bindings.
Mar 95: Finalize FTP Security Internet-Draft for advancement to
Proposed Standard.
Mar 95: Finalize Kerberos V5 GSS-API Mechanism Internet-Draft for
advancement to Proposed Standard.
Mar 95: Submit SPKM as Proposed Standard, assuming sufficient and
suitable implementation experience.
Apr 95: Finalize GSS-V2 Internet-Draft as basis for advancement of
GSS-API to Draft Standard or for submission to become new Proposed
Standard.
Apr 95: Revision of RFC-1509 for GSS-V2.
Apr 95: Initial Internet-Draft for GSS-API negotiation mechanism,
exchanging tokens to identify a common security mechanism shared
between peers and then proceeding to establish a security context
using that mechanism.
Apr 95: Revised IOP Internet-Draft.
Jul 95: Initial Internet-Draft for GSS-API multi-mechanism
registration (SPI) facilities.
Jul 95: Plan next phase of activities to follow GSS-V2, with
particular attention to authorization and store-and-forward protection
support.
Internet-Drafts:
Posted Revised I-D Title <Filename>
------ ------- ------------------------------------------
Mar 94 Jul 94 <draft-ietf-cat-kerb5gss-01.txt>
The Kerberos Version 5 GSS-API Mechanism
Jul 94 Oct 94 <draft-ietf-cat-spkmgss-01.txt>
The Simple Public-Key GSS-API Mechanism (SPKM)
Nov 94 New <draft-ietf-cat-gssv2-00.txt>
Generic Security Service Application Program Interface, Version
2
Nov 94 New <draft-ietf-cat-iop-gss-00.txt>
Independent Object Protection Generic Security Service
Application Program Interface (IOP-GSS-API)
Nov 94 New <draft-ietf-cat-kerberos-passwords-00.txt>
Integrating One-time Passwords with Kerberos
Request For Comments:
RFC Stat Published Title
------- -- ---------- -----------------------------------------
RFC1508 PS Sep 93 Generic Security Service Application Program Interface
RFC1507 E Sep 93 DASS - Distributed Authentication Security Service
RFC1510 PS Sep 93 The Kerberos Network Authentication Service (V5)
RFC1511 I Sep 93 Common Authentication Technology Overview
RFC1509 PS Sep 93 Generic Security Service API : C-bindings
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04661;
23 Jan 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04655;
23 Jan 95 13:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10803;
23 Jan 95 13:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04646;
23 Jan 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04555;
23 Jan 95 13:35 EST
Received: from [192.80.11.3] by CNRI.Reston.VA.US id aa10677;
23 Jan 95 13:34 EST
Received: by SOFTSW.SSW.COM
(Soft*Switch Central V4L400B2) id 335735130095023FOPNOTES;
23 Jan 1995 13:35:13 EDT
Message-Id: <OPNOTES.THINDER.335735130095023FOPNOTES at SSW.COM>
Date: 23 Jan 1995 13:35:13 EDT
Reply-To: THINDER at softsw.ssw.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Hinders, Thomas" <THINDER at softsw.ssw.com>
Subject: SMTP FAQ
To: IETF at nri.reston.va.us
Comment: Memo 01-23-95 12:44:16
This is probably not the forum...but I have a number of SMTP questions:
- Is there a FAQ
- Is there a list to subscribe to.
Thanks.......tom hinders thinder at ssw.com
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07393;
23 Jan 95 17:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15342;
23 Jan 95 17:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07316;
23 Jan 95 17:18 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07156;
23 Jan 95 17:11 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sdrp at catarina.usc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-sdr-sdrp-05.txt
Date: Mon, 23 Jan 95 17:11:05 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501231711.aa07156 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Source Demand Routing Working
Group of the IETF.
Title : Source Demand Routing: Packet Format and Forwarding
Specification (Version 1).
Author(s) : Deborah Estrin, Daniel Zappala, Tony Li,
Yakov Rekhter, Kannan Varadhan
Filename : draft-ietf-sdr-sdrp-05.txt
Pages : 27
Date : 01/19/1995
The purpose of SDRP is to support source-initiated selection of routes to
complement the route selection provided by existing routing protocols for
both inter-domain and intra-domain routes.
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-sdr-sdrp-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-sdr-sdrp-05.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-sdr-sdrp-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 cnri.reston.va.us.
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: <19950120153223.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-sdr-sdrp-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sdr-sdrp-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950120153223.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07396;
23 Jan 95 17:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15341;
23 Jan 95 17:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07314;
23 Jan 95 17:18 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07206;
23 Jan 95 17:12 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-irl-fun-req-03.txt
Date: Mon, 23 Jan 95 17:12:32 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501231712.aa07206 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Functional Requirements for Internet Resource Locators
Author(s) : J. Kunze
Filename : draft-ietf-uri-irl-fun-req-03.txt
Pages : 7
Date : 01/20/1995
This document specifies a minimum set of requirements for Internet resource
locators, which convey location and access information for resources.
Typical examples of resources include network accessible documents, WAIS
databases, FTP servers, and Telnet destinations.
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-uri-irl-fun-req-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-irl-fun-req-03.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-irl-fun-req-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950120162054.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-irl-fun-req-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-irl-fun-req-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950120162054.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07428;
23 Jan 95 17:18 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07400;
23 Jan 95 17:18 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15353;
23 Jan 95 17:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07313;
23 Jan 95 17:18 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07098;
23 Jan 95 17:09 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-dckmtr-proxy-00.txt
Date: Mon, 23 Jan 95 17:09:38 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501231709.aa07098 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Proxy Solution to the Multiple Component Problem
Author(s) : D. Kostick, M. Rose
Filename : draft-dckmtr-proxy-00.txt
Pages : 12
Date : 01/20/1995
Traditionally, an SNMP agent has four top-level functions: receive requests
from a management application; access the corresponding local
instrumentation; generate responses; and, generate traps.
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-dckmtr-proxy-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dckmtr-proxy-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-dckmtr-proxy-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950120133730.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-dckmtr-proxy-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dckmtr-proxy-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950120133730.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07466;
23 Jan 95 17:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15343;
23 Jan 95 17:18 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07318;
23 Jan 95 17:18 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07122;
23 Jan 95 17:10 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-teraoka-ipv6-mobility-suport-00.txt
Date: Mon, 23 Jan 95 17:10:08 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501231710.aa07122 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Options for Mobility Support in IPv6
Author(s) : F. Teraoka, K. Uehara
Filename : draft-teraoka-ipv6-mobility-suport-00.txt
Pages : 13
Date : 01/20/1995
This memo describes a protocol for mobility support in IPv6[1]. This
protocol is based on the same concept of VIP[2], a protocol for mobility
support in IPv4. The basic concept in this memo is to separate identifiers
and addresses. A cache mechanism is employed for mapping between an
identifier and an address so that most packets travel the optimal route.
TCP/UDP communicates with other hosts by specifying the identifiers. Two
options are added in the Hop-by-Hop Options Header to support mobility.
One option is used for data communication while another for control. Each
message has authentication data to prevent impersonation and guarantee the
integrity of the mobile option headers.
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-teraoka-ipv6-mobility-suport-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-teraoka-ipv6-mobility-suport-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-teraoka-ipv6-mobility-suport-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950120145740.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-teraoka-ipv6-mobility-suport-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-teraoka-ipv6-mobility-suport-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950120145740.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07923;
23 Jan 95 18:20 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16424;
23 Jan 95 18:20 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07914;
23 Jan 95 18:20 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07278;
23 Jan 95 17:15 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: notifications at cs.utk.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-notary-mime-delivery-04.txt
Date: Mon, 23 Jan 95 17:15:55 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501231715.aa07278 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Notifications and
Acknowledgements Requirements Working Group of the IETF.
Title : An Extensible Message Format for
Delivery Status Notifications
Author(s) : K. Moore, G. Vaudreuil
Filename : draft-ietf-notary-mime-delivery-04.txt
Pages : 33
Date : 01/20/1995
This memo defines a MIME content-type that may be used by a message
transfer agent (MTA) or electronic mail gateway to report the result of an
attempt to deliver a message to one or more recipients. This content-type
is intended as a machine-processable replacement for the various types of
delivery status notifications currently used in Internet electronic mail.
Because many messages are sent between the Internet and other messaging
systems (such as X.400 or the so-called "LAN-based" systems), the DSN
environment. To this end, the protocol described in this memo provides for
the carriage of "foreign" addresses and error codes, in addition to those
normally used in Internet mail. Additional attributes may also be defined
to support "tunneling" of foreign notifications through Internet mail.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-notary-mime-delivery-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-notary-mime-delivery-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-notary-mime-delivery-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 cnri.reston.va.us.
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: <19950123171454.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-notary-mime-delivery-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-notary-mime-delivery-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950123171454.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04981;
24 Jan 95 12:58 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04975;
24 Jan 95 12:58 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09433;
24 Jan 95 12:58 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04958;
24 Jan 95 12:58 EST
Received: from othello.admin.kth.se by IETF.CNRI.Reston.VA.US id aa04625;
24 Jan 95 12:36 EST
Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b)
id AA28723; Tue, 24 Jan 95 18:37:01 +0100
Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0)
id AA02949; Tue, 24 Jan 95 18:36:47 +0100
Date: Tue, 24 Jan 95 18:36:47 +0100
Message-Id: <9501241736.AA02949 at mercutio.admin.kth.se>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Olle Jarnefors <ojarnef at admin.kth.se>
To: ietf at IETF.CNRI.Reston.VA.US, RFC-EDITOR at isi.edu,
iesg-secretary at CNRI.Reston.VA.US
Cc: Olle Jarnefors <ojarnef at admin.kth.se>
Subject: Editorial updates of important RFCs
RFC 1590, "Media Type Registration Procedure", published March
1994, contains this text in section 2.1:
> Send a proposed Media Type (content-type/subtype) to the "ietf-
> types at cs.utk.edu" mailing list. This mailing list has been
> established for the sole purpose of reviewing proposed Media Types.
Since then this mailing list has migrated to
ietf-types at uninett.no, which will be difficult to know for a
new-comer to the IETF work, who only has read the RFC.
(It's a pity URNs for mailing lists can't be used yet.)
What do you think about the following possible solution?
The RFC Editor publishes a short RFC Amendment, in this case
called "RFC 1590 Amendment 1". In FTP archives, the filename
could be rfc1590_1.txt, so a "dir *1590*" command would expose
the existence of both the main RFC and the amendment.
Amendments would only be used for editorial corrections or
updates. Any change of substance would still bring about a new
RFC with a new series number.
In the current case the content of this amendment need not be
more than this:
------
Amendment 1 of Request for Comments 1590:
Media Type Registration Procedure
In section 2.1, change
- Send a proposed Media Type (content-type/subtype) to the "ietf-
- types at cs.utk.edu" mailing list. This mailing list has been
to
+ Send a proposed Media Type (content-type/subtype) to the "ietf-
+ types at uninett.no" mailing list. This mailing list has been
------
--
Olle Jarnefors, Royal Institute of Technology, Stockholm <ojarnef at admin.kth.se>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05622;
24 Jan 95 13:30 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05615;
24 Jan 95 13:30 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10118;
24 Jan 95 13:30 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05580;
24 Jan 95 13:30 EST
Received: from NYU.EDU by IETF.CNRI.Reston.VA.US id aa05455; 24 Jan 95 13:25 EST
Received: from BJR.ACF.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34)
id AA12596; Tue, 24 Jan 95 13:25:38 -0500
X-Sender: russell at cmcl2.nyu.edu
Message-Id: <ab4af5ce450210046b20 at [128.122.207.11]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 24 Jan 1995 13:27:42 -0500
To: Olle Jarnefors <ojarnef at admin.kth.se>, ietf at IETF.CNRI.Reston.VA.US,
RFC-EDITOR at isi.edu, iesg-secretary at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Russell <Bill.Russell at nyu.edu>
Subject: Re: Editorial updates of important RFCs
Cc: Olle Jarnefors <ojarnef at admin.kth.se>
The addition of editorial corrections is a good idea.
I would further state that all "offical" request lists/email-addresses
of the type being discussed should be of the form:
address at IETF.CNRI.Reston.VA.US
And then the mail can be redirected to the current holder of the
position. This way as folks come and go in the Internet structure,
you won't be changing very many documents. A standard announcement
can than go out saying that so and so has taken over of the
position of "Media Type" registrar, or whatever.
Bill
At 12:36 1/24/95, Olle Jarnefors wrote:
>RFC 1590, "Media Type Registration Procedure", published March
>1994, contains this text in section 2.1:
>
>> Send a proposed Media Type (content-type/subtype) to the "ietf-
>> types at cs.utk.edu" mailing list. This mailing list has been
>> established for the sole purpose of reviewing proposed Media Types.
>
>Since then this mailing list has migrated to
>ietf-types at uninett.no, which will be difficult to know for a
>new-comer to the IETF work, who only has read the RFC.
>
>(It's a pity URNs for mailing lists can't be used yet.)
>
>What do you think about the following possible solution?
>
>The RFC Editor publishes a short RFC Amendment, in this case
>called "RFC 1590 Amendment 1". In FTP archives, the filename
>could be rfc1590_1.txt, so a "dir *1590*" command would expose
>the existence of both the main RFC and the amendment.
>
>Amendments would only be used for editorial corrections or
>updates. Any change of substance would still bring about a new
>RFC with a new series number.
>
>In the current case the content of this amendment need not be
>more than this:
>
>------
>Amendment 1 of Request for Comments 1590:
>Media Type Registration Procedure
>
>In section 2.1, change
>
>- Send a proposed Media Type (content-type/subtype) to the "ietf-
>- types at cs.utk.edu" mailing list. This mailing list has been
>
>to
>
>+ Send a proposed Media Type (content-type/subtype) to the "ietf-
>+ types at uninett.no" mailing list. This mailing list has been
>------
>
>--
>Olle Jarnefors, Royal Institute of Technology, Stockholm <ojarnef at admin.kth.se>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05797;
24 Jan 95 13:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05791;
24 Jan 95 13:34 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10201;
24 Jan 95 13:34 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05773;
24 Jan 95 13:33 EST
Received: from THOR.INNOSOFT.COM by IETF.CNRI.Reston.VA.US id aa05597;
24 Jan 95 13:30 EST
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-13 #2001)
id <01HM3ZBLKCCG8ZDW0P at INNOSOFT.COM>; Tue, 24 Jan 1995 10:29:34 -0800 (PST)
Date: Tue, 24 Jan 1995 10:28:16 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ned Freed <NED at innosoft.com>
Subject: Re: Editorial updates of important RFCs
In-reply-to: Your message dated "Tue, 24 Jan 1995 18:36:47 +0100"
<9501241736.AA02949 at mercutio.admin.kth.se>
To: Olle Jarnefors <ojarnef at admin.kth.se>
Cc: ietf at IETF.CNRI.Reston.VA.US, RFC-EDITOR at isi.edu,
iesg-secretary at CNRI.Reston.VA.US, Olle Jarnefors <ojarnef at admin.kth.se>
Message-id: <01HM7ZFWQ5NW8ZDW0P at INNOSOFT.COM>
MIME-version: 1.0
Content-type: Text/Plain; charset=us-ascii
Content-transfer-encoding: 7bit
> RFC 1590, "Media Type Registration Procedure", published March
> 1994, contains this text in section 2.1:
> > Send a proposed Media Type (content-type/subtype) to the "ietf-
> > types at cs.utk.edu" mailing list. This mailing list has been
> > established for the sole purpose of reviewing proposed Media Types.
> Since then this mailing list has migrated to
> ietf-types at uninett.no, which will be difficult to know for a
> new-comer to the IETF work, who only has read the RFC.
This is just one (fairly minor) issue in RFC1590 out of many. I plan to
have a draft of a new version of this RFC out within the week.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07427;
24 Jan 95 14:44 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07421;
24 Jan 95 14:44 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11738;
24 Jan 95 14:44 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07384;
24 Jan 95 14:44 EST
Received: from othello.admin.kth.se by IETF.CNRI.Reston.VA.US id aa07318;
24 Jan 95 14:41 EST
Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b)
id AA29604; Tue, 24 Jan 95 20:41:49 +0100
Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0)
id AA03656; Tue, 24 Jan 95 20:41:47 +0100
Date: Tue, 24 Jan 95 20:41:47 +0100
Message-Id: <9501241941.AA03656 at mercutio.admin.kth.se>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Olle Jarnefors <ojarnef at admin.kth.se>
To: ietf at IETF.CNRI.Reston.VA.US, RFC-EDITOR at isi.edu,
iesg-secretary at CNRI.Reston.VA.US
Cc: Olle Jarnefors <ojarnef at admin.kth.se>
In-Reply-To: <ab4af5ce450210046b20 at [128.122.207.11]>
(Tue, 24 Jan 1995 13:27:42 -0500; From: Bill Russell <Bill.Russell at nyu.edu>)
Subject: Re: Editorial updates of important RFCs
Bill Russell writes:
> The addition of editorial corrections is a good idea.
Considering that only editorial changes, guaranteed to be
uncontroversial, are in question, "RFC Correction" or "RFC
Corrigenda" would be a better name for this kind of documents
than my original suggestion, "RFC Amendment".
> I would further state that all "offical" request lists/email-addresses
> of the type being discussed should be of the form:
>
> address at IETF.CNRI.Reston.VA.US
That's a better solution in this case (as long as IETF is
hosted at CNRI.Reston.VA.US ...)
But there are other kinds of errors or out-of-date information
that could be handled by a general "RFC Corrigenda" mechanism,
such as
- a typing error that was not caught before RFC publication
- a reference to another RFC that subsequently is replaced by a
new RFC
- a bit of the text that seems to simply have disappeared
during the production of the final RFC text.
For example, RFC 1522 contains this text:
: A "Q"-encoded encoded-word which appears in a comment MUST NOT
: contain the characters "(", ")" or " encoded-word that appears in
The correct text is:
+ A "Q"-encoded encoded-word which appears in a comment MUST NOT
+ contain the characters "(", ")" or "\". In addition, an
+ encoded-word that appears in
Suppose that this error wasn't discovered until half a year
after the publication of RFC 2012, the definitive Internet
standard corresponding to RFC 1522. In that case "RFC 2012" would
be a very well-established RFC-number of an Internet standard.
It would be a pity if a new RFC with yet another RFC number had
to be published, with only this editorial (but to MIME
implementers essential) correction.
The same mechanism that is used for announcing new RFCs could be
used for announcing RFC Corrigenda. In addition, the filename
convention
rfc<number>_<corrigenda-number>.txt
will make it easy to check in an up-to-date RFC repository if a
certain RFC has any corrigenda.
--
Olle Jarnefors, Royal Institute of Technology, Stockholm <ojarnef at admin.kth.se>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08112;
24 Jan 95 15:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08106;
24 Jan 95 15:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12444;
24 Jan 95 15:11 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08080;
24 Jan 95 15:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07894;
24 Jan 95 15:07 EST
Received: from potogold.rmii.com by CNRI.Reston.VA.US id aa12327;
24 Jan 95 15:07 EST
Received: from newslink.com by potogold.rmii.com with uucp
(Smail3.1.28.1 #13) id m0rWrTL-0002aDC; Tue, 24 Jan 95 12:04 PST
Date: Tue, 24 Jan 95 12:04 PST
Received: by newslink.com (UUPM-1.51)
id D9427uY Tue, Jan 24, 1995 14:02:13 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: mrahmati at newslink.com
Message-Id: <9501241402.D9427uY at newslink.com>
X-Mailer: UUPlus Mail 1.51
To: ietf at CNRI.Reston.VA.US
Subject: FYI
Organization:
Date: Tue, 24 Jan 95 14:02:12 EST
Thank you for your interest in our Corp.
I you need more information, please call us.
============================ Automated Message ============================
There was a file attached to this message on the Bulletin Board System.
This file attachment has been routed in subsequent messages.
============================= End of Message ==============================
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab08134;
24 Jan 95 15:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08127;
24 Jan 95 15:11 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12450;
24 Jan 95 15:11 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08082;
24 Jan 95 15:11 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07884;
24 Jan 95 15:07 EST
Received: from [198.59.29.1] by CNRI.Reston.VA.US id aa12322;
24 Jan 95 15:07 EST
Received: from newslink.com by potogold.rmii.com with uucp
(Smail3.1.28.1 #13) id m0rWrTG-0002YwC; Tue, 24 Jan 95 12:04 PST
Date: Tue, 24 Jan 95 12:04 PST
Received: by newslink.com (UUPM-1.51)
id D6045FP Tue, Jan 24, 1995 14:01:42 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: mrahmati at newslink.com
Message-Id: <9501241401.D6045FP at newslink.com>
X-Mailer: UUPlus Mail 1.51
To: ietf at CNRI.Reston.VA.US
Subject: FYI
Organization:
Date: Tue, 24 Jan 95 14:01:40 EST
Filename: "44337744". File Length: 1116 bytes.
This file is contained in 1 split message chunk(s).
This is message chunk 1 of 1 and was processed on
Tue, 24 Jan 95 14:01:16 EST:
---- cut here ----
Please Send some information about your Company and Products.
Here is a summary of some of the services we offer:
Network Design/Setup & Architecture
- System Study, Problem Solving
- Develop Logical & Physical schematics
- Overlays onto Floorplan
- Server setup, Work-Station Configuration from
Small network to large enterprise & Legacy systems.
- Programming Computer Application C++, FOXPRO, COBOL , BASIC
-Training hardware & software
(MicroSoft Word,WordPerfect, Lotus 123,
Excel,PageMaker,CorelDraw,Foxpro,ACT)
Our Turn-Key Network Systems: Complete Network Turnkey System
5 10 25 50 100 ...user Novell.
Corporate HQ
Irvine Computer S&C
1666 N. Main St.
Ste. 340,
Santa Ana , CA 92701
Sales:(714)973-7753
Tech: (714)956-7027
Or
Mailing Address: Sales
4482 Barranca Pkwy
Ste. 180 Dept 173
Irvine, CA 92714
Or
Mailing Address: Tech Support
3972 Barranca Pkwy.
Ste. J291
Irvine, CA 92714
Thank you for your interest in our Corp.
If you need research...etc. you may send email to mrahmati at newslink.com
or fax us (714)973-7754.
---- cut here ----
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08820;
24 Jan 95 15:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08814;
24 Jan 95 15:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13110;
24 Jan 95 15:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08800;
24 Jan 95 15:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08675;
24 Jan 95 15:37 EST
Received: from darpa.mil by CNRI.Reston.VA.US id aa12989; 24 Jan 95 15:37 EST
Received: from next76.darpa.mil (next76.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5)
id <AA29043>; Tue, 24 Jan 1995 15:33:00 -0500
Received: by next76.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA00727; Tue, 24 Jan 95 15:30:24 EST
Date: Tue, 24 Jan 95 15:30:24 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Sanders <dsanders at csto.snap.org>
Message-Id: <9501242030.AA00727@ next76.darpa.mil >
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Existing_PIs at arpa.mil, Misc_BAA at arpa.mil, New_PIS at arpa.mil,
csto-all at arpa.mil, trp_digital_wireless at arpa.mil,
trp_wireless_gov at arpa.mil, IITA at hpcc.gov, IETF at CNRI.Reston.VA.US,
glomo at arpa.mil
Subject: GloMo BAA
Cc: BLeiner at arpa.mil, DSanders at arpa.mil, Amspaugh at arpa.mil, Lesaar at arpa.mil
Attached is BAA-95-16 for GLOBAL MOBILE INFORMATION SYSTEMS (GLOMO)
that appeared in the January 20, 1995 CBD. You are encouraged to
distribute and forward this BAA to other persons who may be
interested.
The associated PIP is available via WWW at URL
http://www.csto.arpa.mil/Solicitations.
Thank you.
*******************************************************************
Due to the possibility of transcription errors, the official CBD
announcement takes precedence over this transcription in any
disagreement between the two. The transcription is provided for your
convenience only.
=================================================
GLOBAL MOBILE INFORMATION SYSTEMS (GLOMO) SOL BAA95-16 DUE 042895 POC
Barry M. Leiner, POC, ARPA/CSTO, FAX: (703)522-2668.
The Advanced Research Projects Agency (ARPA) is soliciting proposals
in the area of global mobile information systems (GloMo). This
activity is aimed at developing advanced techniques for supporting
information and computing systems operation while in motion. The
motivation behind the program is the military requirement for
efficient and effective access to information and the ability to
manipulate such information in an environment characterized by rapid
changes in connectivity and bandwidth. This BAA focuses on research
interests in the following five technical areas:
1) Design Infrastructure: Integrated design tools, techniques, and
environments supporting the automated design including simulation,
synthesis, physical design, and test of wireless systems spanning
individual integrated circuits to applications running over wireless
networks. Design tools that leverage scalable computing, address
low-power design, address hardware-software co-design, or the
multi-disciplinary nature of wireless system design are of particular
interest. Projects may include extensions to existing design
environments or entirely new concepts or approaches. Design tool
development should be completed through validation and testing to
include validation on the design and demonstration of hardware.
Design tools and environments should be capable of realistically
meeting the system complexity requirements implicit in the GLOMO
program goals. Technical Point of Contact: Robert H. Parker
2) Untethered Node Architectures: The goal is to develop and
demonstrate modular commercial architectures for wireless nodes that
may be enhanced to support military requirements. The goal is a
modular, product line approach that supports the range of
requirements from commercial through to the demanding requirements of
military and civilian disaster management environments. In
particular, the military should be able to procure systems through
straightforward enhancements to available commercial systems.
Proposed efforts should leverage and may include advanced component
technology development such as integrated passives, batteries,
filters, packaging, and VLSI that substantially increase the levels
of integration and reduce the size and/or cost of resulting nodes.
Architectures should leverage programmability and standard physical
form factors such as PCMCIA to produce miniaturized modular units
that will support sophisticated network management in a multi-hop
environment, and waveform diversity such as required by spread
spectrum. Technical Point of Contact: Robert H. Parker
3) Wireless Network Systems: Military and civilian disaster
management environments demand networking technologies that will
support rapid deployment, self-configuration, multi-hop capability,
and robust survivability. The purpose of this portion is to develop
the network architectures, algorithms, and protocols that will
provide these features while at the same time exploiting the radio
technologies discussed above. Earlier results in packet radio network
systems should be considered as a starting point for development of
such systems, with enhancements incorporated to support such
requirements as multimedia communications. Technical Point of
Contact: Barry M. Leiner
4) End-to-End Mobile Networking: The goal of this activity is to
provide effective and reliable end-to-end communications in an
environment including mobile components with their resulting
variability in connectivity and bandwidth. Specific issues to be
addressed in this portion include motion between subnetworks and an
enriched service interface that will allow applications to be
informed of the currently available connectivity, bandwidth, latency,
and error rates. This portion of the program will be conducted in
close coordination with the overall thrust in networking technology,
and should be considered as an enhancement to current Internet
directions. Technical Point of Contact: Michael C. StJohns.
5) Mobile Information Systems: The goal of this activity is to
develop techniques for applications to effectively operate in a
mobile environment, taking full advantage of the underlying
communications. Techniques to be developed include but are not
limited to methods for applications to adapt to variations in the
underlying communications connectivity and parameters, distributed
file systems that deal with sporadic connectivity, migratable
computing that support varying node availability, etc. Technical
Point of Contact: Barry M. Leiner.
The focus of this solicitation is on an integrated set of
technologies that can support effective, reliable, and robust
information systems in a mobile environment typical of military
operations. Proposals may address multiple areas in an integrated
fashion. In particular, proposals that address Areas 2 and 3
(Untethered Node Architectures and Wireless Network Systems) in an
integrated fashion are encouraged. Proposals that leverage the design
infrastructure in Area 1 to produce results in another area are
encouraged. Proposals that incorporate both technology development
and demonstration are encouraged. Demonstrations should be aimed at
motivating and/or validating technology development and not as
stand-alone demonstrations. Collaborative university/industry
research and development is desirable to ensure technology transfer.
Teaming arrangements and cost sharing are encouraged where
appropriate, especially when coupling technology developments to
applications demonstrations. However, teaming is not essential in all
of the technical areas of research.
PROGRAM SCOPE: Proposals for individual efforts should not exceed
three years in length. Technologies which have a broad impact on
military capability will be given highest priority. Contract awards
are expected to be made during the second half of fiscal year 1995.
Total funding is expected to be approximately $30,000,000 over three
years. Multiple awards will be made. Collaborative efforts and
teaming are encouraged where appropriate.
GENERAL INFORMATION: A briefing describing this activity will be
given on 8 Feb 95. Questions and answers resulting from this briefing
as well as the slides used will be available electronically from
http://www.csto. arpa.mil. Reservations for attendance at this
briefing must be made no later than 3 Feb 95. Parties interested in
attending this briefing should contact David Sanders,
DSanders at arpa.mil, (703) 284-8202. In order to minimize unnecessary
effort in proposal preparation and review, proposers are strongly
encouraged to submit brief proposal abstracts in advance of full
proposals. An original and four (4) copies of the proposal abstract
must be submitted to ARPA/CSTO, 3701 North Fairfax Drive, Arlington,
VA 22203-1714 (ATTN: BAA 95-16) on or before 24 Feb 95. Proposal
abstracts received after this date may not be reviewed. Upon review,
ARPA will provide written feedback on the likelihood of a full
proposal being selected. Proposers must submit an original and four
(4) copies of full proposals by 28 Apr 95, in order to be considered.
Proposers must obtain a pamphlet, BAA 95-16 Proposer Information,
which provides further information on areas of interest, the
submission, evaluation, funding processes, proposal and proposal
abstract formats. This pamphlet may be obtained by fax, electronic
mail, or mail request to the administrative contact address given
below, as well as at URL address
http://www.csto.arpa.mil/Solicitations. Proposals not meeting the
format described in the pamphlet may not be reviewed. This notice, in
conjunction with the pamphlet BAA 95-16 Proposer Information,
constitutes the total BAA. No additional information is available,
nor will a formal RFP or other solicitation regarding this
announcement be issued. Requests for same will be disregarded. The
Government reserves the right to select for award all, some, or none
of the proposals received. All responsible sources capable of
satisfying the Government's needs may submit a proposal which shall
be considered by ARPA. Historically Black Colleges and Universities
(HBCU) and Minority Institutions (MI) are encouraged to submit
proposals and join others in submitting proposals. However, no
portion of this BAA will be set aside for HBCU and MI participation
due to the impracticality of reserving discrete or severable areas of
research in GloMo. Evaluation of proposals will be accomplished
through a technical review of each proposal using the following
criteria, which are listed in descending order of relative
importance: (1) overall scientific and technical merit, (2) potential
contribution and relevance to ARPA mission, (3) offeror's
capabilities and related experience (4) plans and capability to
accomplish technology transition, (5) cost realism. Note: Cost
realism will only be significant in proposals which have
significantly under- or overestimated the cost to complete their
effort. All administrative correspondence and questions on this
solicitation, including requests for information on how to submit a
proposal abstract or proposal to this BAA, should be directed to one
of the administrative addresses below, e-mail or fax is preferred.
ARPA intends to use electronic mail and fax for correspondence
regarding BAA 95-16. Proposals and proposal abstracts may not be
submitted by fax, any so sent will be disregarded. The administrative
addresses for this BAA are: Fax: (703) 522-2668 Addressed to:
ARPA/CSTO, BAA 95-16 Electronic Mail: baa9516 at arpa.mil Electronic
File Retrieval: http://www.csto.arpa.mil/Solicitations, Mail:
ARPA/CSTO ATTN: BAA 95-16, 3701 N. Fairfax Drive, Arlington, VA
22203-1714 (0018)
SPONSOR: Advanced Research Projects Agency (ARPA), Contracts
Management Office (CMO), 3701 North Fairfax Drive, Arlington, VA
22203-1714
SUBFILE: PSE (U.S. GOVERNMENT PROCUREMENTS, SERVICES)
SECTION HEADING: A Research and Development
PUBLICATION DATE: JANUARY 20, 1995
ISSUE: PSA-1266
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11416;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15565;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11359;
24 Jan 95 17:26 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10981;
24 Jan 95 17:10 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-flick-interfaces-mib-00.txt
Date: Tue, 24 Jan 95 17:10:16 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501241710.aa10981 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for
IEEE 802.12 Interfaces
Author(s) : J. Flick
Filename : draft-flick-interfaces-mib-00.txt
Pages : 22
Date : 01/23/1995
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing network
interfaces based on the IEEE 802.12 Draft.
This memo does not specify a standard for the Internet community.
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-flick-interfaces-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-flick-interfaces-mib-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-flick-interfaces-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950123094212.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-flick-interfaces-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-flick-interfaces-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950123094212.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11434;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15577;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11357;
24 Jan 95 17:26 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11021;
24 Jan 95 17:11 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-mime-check-00.txt
Date: Tue, 24 Jan 95 17:11:52 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501241711.aa11021 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : Multimedia E-mail (MIME) User Agent checklist
Author(s) : E. Huizer
Filename : draft-ietf-mailext-mime-check-00.txt
Pages : 6
Date : 01/23/1995
This document presents a checklist to facilitate evaluation of MIME capable
User Agents. Access to a MIME test-responder, that generates test-messages
is described.
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-mailext-mime-check-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-mime-check-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-mime-check-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950123114705.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-mime-check-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-mime-check-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950123114705.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11447;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15588;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11360;
24 Jan 95 17:26 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11067;
24 Jan 95 17:14 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-rsvp-spec-04.txt, .ps
Date: Tue, 24 Jan 95 17:14:03 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501241714.aa11067 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification
Author(s) : L. Zhang, R. Braden, D. Estrin,
S. Herzog, S. Jamin
Filename : draft-ietf-rsvp-spec-04.txt, .ps
Pages : 51
Date : 01/23/1995
This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or unicast
data flows, with good scaling and robustness properties.
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-rsvp-spec-04.txt".
Or
"get draft-ietf-rsvp-spec-04.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-spec-04.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-rsvp-spec-04.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-spec-04.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 cnri.reston.va.us.
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: <19950123140942.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-spec-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-spec-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950123140942.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11471;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15604;
24 Jan 95 17:26 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11356;
24 Jan 95 17:26 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11098;
24 Jan 95 17:15 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-mib-06.txt
Date: Tue, 24 Jan 95 17:15:06 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501241715.aa11098 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Open Shortest Path First IGP
Working Group of the IETF.
Title : OSPF Version 2 Management Information Base
Author(s) : F. Baker, R. Coltun
Filename : draft-ietf-ospf-mib-06.txt
Pages : 108
Date : 01/23/1995
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Open Shortest Path First
Routing Protocol.
This memo does not, in its draft form, specify a standard for the
Internet community.
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-ospf-mib-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-mib-06.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-ospf-mib-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950123170029.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-mib-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-mib-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950123170029.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11791;
24 Jan 95 17:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15932;
24 Jan 95 17:41 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11738;
24 Jan 95 17:40 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10971;
24 Jan 95 17:10 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-flick-repeater-dev-mib-00.txt
Date: Tue, 24 Jan 95 17:10:12 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501241710.aa10971 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for
IEEE 802.12 Repeater Devices
Author(s) : J. Flick
Filename : draft-flick-repeater-dev-mib-00.txt
Pages : 42
Date : 01/23/1995
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing 100Mb/second
repeaters based on the IEEE 802.12 Draft.
This memo does not specify a standard for the Internet community.
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-flick-repeater-dev-mib-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-flick-repeater-dev-mib-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-flick-repeater-dev-mib-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950123093816.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-flick-repeater-dev-mib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-flick-repeater-dev-mib-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950123093816.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12613;
24 Jan 95 18:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12607;
24 Jan 95 18:50 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17233;
24 Jan 95 18:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12596;
24 Jan 95 18:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12552;
24 Jan 95 18:45 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17160;
24 Jan 95 18:45 EST
Received: from witch.witchcraft.com by venera.isi.edu (5.65c/5.61+local-20)
id <AA12646>; Tue, 24 Jan 1995 15:45:37 -0800
Received: by witch.witchcraft.com id AA28580
(5.65/1.35 for <ietf at venera.isi.edu>); Tue, 24 Jan 95 18:45:11 -0500
Received: by win.net!video; Tue, 24 Jan 1995 16:37:47
X-Mailer: WinNET Mail, v2.20
Message-Id: <107 at video.win.net>
Reply-To: mark williams <whamo at video.win.net>
To: ietf at isi.edu
Date: Tue, 24 Jan 1995 16:37:47
Subject: programing help
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: mark williams <whamo at video.win.net>
we are a small compeny in California looking for help with our IBM,
windows based Internet product. is this the place to ask for
programers to help us with our project? send E-Mail to Mark
Williams at mmedia at netcom.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24248;
25 Jan 95 1:39 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa24244;
25 Jan 95 1:39 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa23634;
25 Jan 95 1:39 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <BAA15811 at pad-thai.cam.ov.com>; Wed, 25 Jan 1995 01:04:08 -0500
Received: from x400gate.bnr.ca by MIT.EDU with SMTP
id AA13298; Wed, 25 Jan 95 01:01:17 EST
X400-Received:
by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 25 Jan 1995 00:59:47 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 24 Jan 1995 18:11:02 -0500
X400-Received:
by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 24 Jan 1995 18:11:00 -0500
Date: Tue, 24 Jan 1995 18:11:00 -0500
X400-Originator: /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca
X400-Mts-Identifier:
[/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.275:24.00.95.23.11.02]
X400-Content-Type: P2-1984 (2)
Content-Identifier: GSS-API Sugge...
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "carlisle (c.m.) adams" <cadams at bnr.ca>
X-Orig-Sender: "carlisle (c.m.) adams" <cadams at bnr.ca>
Message-Id: <"16277 Tue Jan 24 18:11:05 1995"@bnr.ca>
To: cat-ietf at mit.edu
Cc: kdesplan at intacc.net
Subject: GSS-API Suggestion...
Hi all,
Just a very quick suggestion. In our implementation of
the Simple Public Key GSS-API Mechanism (SPKM), we have
found that it would be useful to have the gss function
GSS_Process_context_token() return the following major
status codes (when appropriate):
GSS_S_DUPLICATE_TOKEN
GSS_S_OLD_TOKEN
GSS_S_GAP_TOKEN
GSS_S_BAD_SIG
(note that, at the moment, only COMPLETE, DEFECTIVE_TOKEN,
NO_CONTEXT, and FAILURE are valid returns).
Both John Linn and John Wray see no problem with such a
modification to 1508 and 1509, but suggested that we poll
the CAT group first.
Are there any objections to such a proposal?
Carlisle.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02147;
25 Jan 95 8:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02141;
25 Jan 95 8:51 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04745;
25 Jan 95 8:51 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02072;
25 Jan 95 8:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01827;
25 Jan 95 8:36 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa04503;
25 Jan 95 8:36 EST
Received: from inet-gw-3.pa.dec.com by venera.isi.edu (5.65c/5.61+local-20)
id <AA08022>; Wed, 25 Jan 1995 05:37:08 -0800
Received: from skidrow.tay.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94)
id AA18399; Wed, 25 Jan 95 05:33:02 -0800
Received: by skidrow.tay.dec.com (5.65/MS-081993);
id AA27183; Wed, 25 Jan 1995 08:37:58 -0500
Message-Id: <9501251337.AA27183 at skidrow.tay.dec.com>
To: mark williams <whamo at video.win.net>
Cc: ietf at isi.edu, postmaster at video.win.net, mmedia at netcom.com,
postmaster at netcom.com, ietf-request at IETF.CNRI.Reston.VA.US
Subject: Re: programing help
In-Reply-To: Your message of "Tue, 24 Jan 95 16:37:47."
<107 at video.win.net>
Date: Wed, 25 Jan 95 08:37:57 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.tay.dec.com>
X-Mts: smtp
Mark,
ABSOLUTELY NOT.
At the expense of more bandwidth for everyone on the IETF list, this
is a reminder that no commercial message are to be posted to the IETF
mailing list. This includes job availability or job wanted type
messages.
In the future, please check FIRST, with the "-request administrator"
or someone you see posting on the list, before wasting the time of
everyone on a mailing list.
Donald
PS: There are plenty of "jobs" newsgroups. I suggest you post there.
From: mark williams <whamo at video.win.net>
X-Mailer: WinNET Mail, v2.20
Reply-To: mark williams <whamo at video.win.net>
To: ietf at isi.edu
Sender: ietf-request at IETF.CNRI.Reston.VA.US
>we are a small compeny in California looking for help with our IBM,
>windows based Internet product. is this the place to ask for
>programers to help us with our project? send E-Mail to Mark
>Williams at mmedia at netcom.com
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02335;
25 Jan 95 8:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02325;
25 Jan 95 8:57 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04928;
25 Jan 95 8:57 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02309;
25 Jan 95 8:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02232;
25 Jan 95 8:54 EST
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa04788;
25 Jan 95 8:54 EST
Received: from skidrow.tay.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA29915; Wed, 25 Jan 95 05:48:08 -0800
Received: by skidrow.tay.dec.com (5.65/MS-081993);
id AA27725; Wed, 25 Jan 1995 08:53:25 -0500
Message-Id: <9501251353.AA27725 at skidrow.tay.dec.com>
To: ietf at CNRI.Reston.VA.US, RFC-EDITOR at isi.edu,
iesg-secretary at CNRI.Reston.VA.US
Subject: Re: Editorial updates of important RFCs
In-Reply-To: Your message of "Tue, 24 Jan 95 13:27:42 EST."
<ab4af5ce450210046b20 at [128.122.207.11]>
Date: Wed, 25 Jan 95 08:53:25 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.tay.dec.com>
X-Mts: smtp
From: Bill Russell <Bill.Russell at nyu.edu>
X-Sender: russell at cmcl2.nyu.edu
To: Olle Jarnefors <ojarnef at admin.kth.se>, ietf at IETF.CNRI.Reston.VA.US,
RFC-EDITOR at isi.edu, iesg-secretary at CNRI.Reston.VA.US
Sender: ietf-request at IETF.CNRI.Reston.VA.US
Cc: Olle Jarnefors <ojarnef at admin.kth.se>
>The addition of editorial corrections is a good idea.
>
>I would further state that all "offical" request lists/email-addresses
>of the type being discussed should be of the form:
>
> address at IETF.CNRI.Reston.VA.US
I don't think such a change is necessary for temporary things like
Working Groups but would be a good idea for "permanent" official
addresses. If it were made, the addresses should be of the form
address at ietf.org or possibly
address at ietf.isoc.org.
>And then the mail can be redirected to the current holder of the
>position. This way as folks come and go in the Internet structure,
>you won't be changing very many documents. A standard announcement
>can than go out saying that so and so has taken over of the
>position of "Media Type" registrar, or whatever.
>>The RFC Editor publishes a short RFC Amendment, in this case
>>called "RFC 1590 Amendment 1". In FTP archives, the filename
>>could be rfc1590_1.txt, so a "dir *1590*" command would expose
>>the existence of both the main RFC and the amendment.
Why is a new mechanism needed? Can't you currently have an RFC the
"updates" another? Just issue RFC-XXXX which is one or two pages and
updates RFC 1590. If the RFC being updated is standards track, the
IESG get to approve the update, which should be trivial for such
minor changes.
Donald
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04016;
25 Jan 95 11:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04012;
25 Jan 95 11:31 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08371;
25 Jan 95 11:31 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <KAA23860 at pad-thai.cam.ov.com>; Wed, 25 Jan 1995 10:42:33 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA15331; Wed, 25 Jan 95 10:39:44 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <KAA23855 at pad-thai.cam.ov.com>; Wed, 25 Jan 1995 10:42:31 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA15134; Wed, 25 Jan 95 10:42:30 EST
Message-Id: <9501251542.AA15134 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Thoughts on anonymity
Date: Wed, 25 Jan 1995 10:42:30 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
All:
Considering the discussion that's been ongoing, I'll observe that we
have two separable issues re autonomy, which I'll break out here as
(1) and (2).
(1) Delivery: how to indicate to a context target that the context's
initiator is anonymous instead of delivering an authenticated name.
The choices that have been presented in this area are:
(1a) reserved name type: specifically, an INTERNAL NAME to be returned
by gss_accept_sec_context which, when passed to gss_display_name,
would emit a pair of a reserved name type OID and an associated value
(an empty string, perhaps?) to indicate "anonymous identity".
Interesting question: how should gss_compare_name behave if asked to
compare two such names?
(1b) new output flags from gss_accept_sec_context
(1c) both (1a) and (1b).
Choice (1a) makes sense to me. New output flags wouldn't be
interpreted by existing callers; therefore, if such a caller found
itself atop a mechanism which provided an anonymous context, it would
start trying to operate on a name with no authenticated meaning.
Given that (1a) is needed, we could add (1b) as well, thereby
comprising (1c), but I don't see that we gain compelling benefit from
this apparent redundancy. I'm not perceiving backward compatibility
for mechanisms already supporting anonymity, but under another name
type than the to-be-reserved one (do any such mechanisms exist?), as a
critical issue: such a mechanism could support both its own and the
reserved "anonymous" type in parallel, eventually (I hope) deprecating
the non-reserved type in the interests of portability.
(2) Service request: how a context's initiator can make a request
(which may or may not be honored by its underlying mechanism) that a
context be established anonymously. The choices that have been
presented in this area are:
(2a) new input flags to gss_init_sec_context
(2b) use of different credentials to establish authenticated vs.
anonymous contexts
Choice (2b) seems unnatural to me; as John Wray noted, it's wholly
possible that a mechanism may need principals' keys within credentials
in order to construct tokens even if a principal's identity isn't to
be delivered to a target. Here, I'm inclined towards including (2a)
in GSS-V2. A flagged anonymity request might or might not be honored
by a mechanism; a caller of gss_init_sec_context should therefore
receive a corresponding output flag in order that it can refuse to
send tokens if the request wasn't granted: unlike other output flags,
this one would need to be valid not only when gss_init_sec_context
returns GSS_COMPLETE but also on predecessor calls indicating
GSS_CONTINUE_NEEDED.
Observation: A solution to (1) is primary to any anonymity support,
and offers some value even before a deployed solution to (2): given
just (1), a mechanism could be constructed which would always provide
anonymous contexts or which would make an intra-mechanism
determination of which contexts would be anonymous and which would be
authenticated.
Discussion solicited.
--jl
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05784;
25 Jan 95 13:19 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10592;
25 Jan 95 13:19 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05722;
25 Jan 95 13:19 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05454;
25 Jan 95 13:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10384;
25 Jan 95 13:09 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05449;
25 Jan 95 13:09 EST
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: The PPP DECnet Phase IV Control Protocol (DNCP) to
Draft Standard
Date: Wed, 25 Jan 95 13:08:59 -0500
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9501251309.aa05449 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "The PPP DECnet Phase IV Control
Protocol (DNCP)" <draft-ietf-pppext-dncp-00.txt> for the status of
Draft Standard.
Note that this document is intended to update RFC 1376. There are a few
minor editorial changes from the text in RFC 1376.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us or ietf at cnri.reston.va.us mailing lists by
February 8, 1995.
IESG Secretary
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07643;
25 Jan 95 14:58 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12795;
25 Jan 95 14:58 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07593;
25 Jan 95 14:58 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07415;
25 Jan 95 14:53 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
cc: ipsec at ans.net
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-metzger-ah-md5-01.txt
Date: Wed, 25 Jan 95 14:53:45 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501251453.aa07415 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Authentication with Keyed MD5
Author(s) : P. Metzger, W. Simpson
Filename : draft-metzger-ah-md5-01.txt
Pages : 4
Date : 01/24/1995
This document describes the use of MD5 with the IPv4 Authentication Header.
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-metzger-ah-md5-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-metzger-ah-md5-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-metzger-ah-md5-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 cnri.reston.va.us.
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: <19950124131912.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-metzger-ah-md5-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-metzger-ah-md5-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950124131912.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07650;
25 Jan 95 14:58 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12796;
25 Jan 95 14:58 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07604;
25 Jan 95 14:58 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07487;
25 Jan 95 14:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
cc: ipsec at ans.net
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-metzger-esp-des-cbc-01.txt
Date: Wed, 25 Jan 95 14:55:03 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501251455.aa07487 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The ESP DES-CBC Transform
Author(s) : P. Metzger, W. Simpson
Filename : draft-metzger-esp-des-cbc-01.txt
Pages : 7
Date : 01/24/1995
This document describes the DES-CBC security transform for the
Encapsulating Security Payload (ESP).
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-metzger-esp-des-cbc-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-metzger-esp-des-cbc-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-metzger-esp-des-cbc-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 cnri.reston.va.us.
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: <19950124132348.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-metzger-esp-des-cbc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-metzger-esp-des-cbc-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950124132348.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07710;
25 Jan 95 15:00 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12862;
25 Jan 95 15:00 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07686;
25 Jan 95 14:59 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07551;
25 Jan 95 14:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-uri-url-mailserver-00.txt
Date: Wed, 25 Jan 95 14:56:58 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501251456.aa07551 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uniform Resource Identifiers
Working Group of the IETF.
Title : Mailserver URL Specification
Author(s) : P. Hoffman
Filename : draft-ietf-uri-url-mailserver-00.txt
Pages : 3
Date : 01/24/1995
A new URL scheme, "mailserver", is defined. It allows mail client software
to create RFC822 mail messages from a URL.
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-uri-url-mailserver-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-mailserver-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-uri-url-mailserver-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950124161604.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-uri-url-mailserver-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-url-mailserver-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950124161604.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab08040;
25 Jan 95 15:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13109;
25 Jan 95 15:09 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08001;
25 Jan 95 15:09 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07811;
25 Jan 95 15:05 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-overflow-01.txt
Date: Wed, 25 Jan 95 15:05:08 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501251505.aa07811 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Open Shortest Path First IGP
Working Group of the IETF.
Title : OSPF Database Overflow
Author(s) : J. Moy
Filename : draft-ietf-ospf-overflow-01.txt
Pages : 11
Date : 01/24/1995
Proper operation of the OSPF protocol requires that all OSPF routers
maintain an identical copy of the OSPF link-state database. However, when
the size of the link-state database becomes very large, some routers may be
unable to keep the entire database due to resource shortages; we term this
"database overflow". When database overflow is anticipated, the routers
with limited resources can be accommodated by configuring OSPF stub areas
and NSSAs. This memo details a way of gracefully handling unanticipated
database overflows.
This memo is a product of the OSPF Working Group. Please send comments to
ospf at gated.cornell.edu.
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-ospf-overflow-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-overflow-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-ospf-overflow-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 cnri.reston.va.us.
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: <19950124140828.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-overflow-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-overflow-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950124140828.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08590;
25 Jan 95 15:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08584;
25 Jan 95 15:41 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14781;
25 Jan 95 15:41 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08561;
25 Jan 95 15:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08476;
25 Jan 95 15:37 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14350;
25 Jan 95 15:37 EST
Received: from relay3.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA23002>; Wed, 25 Jan 1995 12:37:50 -0800
Received: from mail.crl.com by relay3.UU.NET with SMTP
id QQyagg29318; Wed, 25 Jan 1995 15:37:54 -0500
Received: from crl7.crl.com by mail.crl.com with SMTP id AA06643
(5.65c/IDA-1.5 for <info-ietf at uunet.uu.net>); Wed, 25 Jan 1995 12:37:16 -0800
Received: by crl7.crl.com id AA26337
(5.65c/IDA-1.5 for info-ietf at uunet.uu.net); Wed, 25 Jan 1995 12:37:18 -0800
To: info-ietf at uunet.uu.net
Path: crl7.crl.com!not-for-mail
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jym Barnes <jybarnes at crl.com>
Newsgroups: info.ietf,comp.protocols.tcp-ip
Subject: How to search RFCs? Looking for voice messaging RFCs
Date: 25 Jan 1995 12:37:16 -0800
Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest]
Lines: 12
Message-Id: <3g6cps$pmu at crl7.crl.com>
Hi,
I am looking for any RFC's which talk about voice messaging and the
Internet. Does anyone know if there is a easy way to search all
RFCs for a text string. I don't want to have to down load all of
them and search and I don't want to NFS mount say wuarchive and
search.
TIA
-Jym-
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11138;
25 Jan 95 18:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11131;
25 Jan 95 18:13 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18111;
25 Jan 95 18:13 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11122;
25 Jan 95 18:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11072;
25 Jan 95 18:10 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa18029;
25 Jan 95 18:10 EST
Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA29967>; Wed, 25 Jan 1995 15:11:13 -0800
Received: from zephyr.isi.edu by relay1.UU.NET with SMTP
id QQyagq26956; Wed, 25 Jan 1995 18:11:04 -0500
Received: by zephyr.isi.edu (5.65c/5.61+local-17)
id <AA29375>; Wed, 25 Jan 1995 15:10:49 -0800
Date: Wed, 25 Jan 1995 15:10:49 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Postel <postel at isi.edu>
Message-Id: <199501252310.AA29375 at zephyr.isi.edu>
To: jybarnes at crl.com
Subject: Re: How to search RFCs? Looking for voice messaging RFCs
Cc: info-ietf at uunet.uu.net
=================================================================
RFC-Info Smplified Help
-----------------------
Use RFC-Info by sending email messages to RFC-INFO at ISI.EDU.
1. To get a specific RFC send a message with text as follows:
Retrieve: RFC
Doc-ID: RFC1500
This gets RFC 1500. All RFC numbers in the Doc-Id are 4 digits
(RFC 791 would be Doc-ID: RFC0791).
2. To get a specific FYI send a message with text as follows:
Retrieve: FYI
Doc-ID: FYI0004
3. To get a list of available RFC's that match a certain criteria:
LIST: RFC
Keywords: Gateway
Returns a list of RFC's with the word Gateway in the title or
specified as a keyword.
4. To get the Index of all RFCs published:
HELP: rfc_index
5. To get information about other ways to get RFCs, FYIs, STDs, or
IMRs.
HELP: ways_to_get_rfcs
HELP: ways_to_get_fyis
HELP: ways_to_get_stds
HELP: ways_to_get_imrs
6. To get help about using RFC-Info:
HELP: help
or
HELP: topics
=================================================================
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00372;
26 Jan 95 3:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00366;
26 Jan 95 3:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00447;
26 Jan 95 3:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23482;
26 Jan 95 3:37 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23432;
26 Jan 95 3:34 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa27066;
26 Jan 95 3:34 EST
Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.61+local-20)
id <AA18621>; Thu, 26 Jan 1995 00:34:46 -0800
Received: from trane.uninett.no by relay1.UU.NET with SMTP
id QQyaic26226; Thu, 26 Jan 1995 03:34:32 -0500
Received: by trane.uninett.no id AA03469
(5.67b/IDA-1.5 for info-ietf at uunet.uu.net); Thu, 26 Jan 1995 09:34:13 +0100
To: info-ietf at uunet.uu.net
Path: uninett.no!hta
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Harald T. Alvestrand" <hta at uninett.no>
Newsgroups: info.ietf
Subject: Re: Editorial updates of important RFCs
Date: 26 Jan 1995 08:34:11 GMT
Organization: Uninett
Lines: 43
Distribution: world
Message-Id: <3g7mq3$2lk at trane.uninett.no>
References: <9501241736.AA02949 at mercutio.admin.kth.se>
Nntp-Posting-Host: domen.uninett.no
In article <9501241736.AA02949 at mercutio.admin.kth.se>, ojarnef at admin.kth.se (Olle Jarnefors) writes:
|> RFC 1590, "Media Type Registration Procedure", published March
|> 1994, contains this text in section 2.1:
|>
|> > Send a proposed Media Type (content-type/subtype) to the "ietf-
|> > types at cs.utk.edu" mailing list. This mailing list has been
|> > established for the sole purpose of reviewing proposed Media Types.
|>
|> Since then this mailing list has migrated to
|> ietf-types at uninett.no, which will be difficult to know for a
|> new-comer to the IETF work, who only has read the RFC.
|>
|> (It's a pity URNs for mailing lists can't be used yet.)
Olle,
I think the *right* solution is to assign STD numbers to Proposed Standards.
STD numbers point to a set of RFCs, and the RFC numbers may change while
the STD numbers are constant.
Unfortunately, current practice is to assign STD numbers only to full
Standards, leaving us in the dark for all the interesting and evolving stuff.
Anyway, everybody seems to have done his homework:
thta at domen-~> telnet cs.utk.edu 25
Trying 128.169.94.1 ...
Connected to cs.utk.edu.
Escape character is '^]'.
220-CS.UTK.EDU Sendmail (cf v2.9s-UTK) ready at Thu, 26 Jan 1995 03:32:29 -0500
220 ESMTP spoken here
expn ietf-types
250 <ietf-types at uninett.no>
The old address works, too!
--
Harald Tveit Alvestrand
Harald.T.Alvestrand at uninett.no
G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
http://domen.uninett.no/~hta/
+47 73 59 70 94
My son's name is Torbjxrn. The letter between "j" and "r" is o with a slash.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04316;
26 Jan 95 11:51 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04312;
26 Jan 95 11:51 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa08579;
26 Jan 95 11:51 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA22918 at pad-thai.cam.ov.com>; Thu, 26 Jan 1995 11:09:56 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA17760; Thu, 26 Jan 95 11:07:00 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA03467; Thu, 26 Jan 95 07:51:30 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA28971; Thu, 26 Jan 95 10:51:52 -0500
Message-Id: <9501261551.AA28971 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Thu, 26 Jan 95 10:51:52 EST
Date: Thu, 26 Jan 95 10:51:52 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 26-Jan-1995 0944" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: RE: Thoughts on anonymity
>(1) Delivery: how to indicate to a context target that the context's
>initiator is anonymous instead of delivering an authenticated name.
>The choices that have been presented in this area are:
>
>(1a) reserved name type: specifically, an INTERNAL NAME to be returned
>by gss_accept_sec_context which, when passed to gss_display_name,
>would emit a pair of a reserved name type OID and an associated value
>(an empty string, perhaps?) to indicate "anonymous identity".
>Interesting question: how should gss_compare_name behave if asked to
>compare two such names?
>
>(1b) new output flags from gss_accept_sec_context
>
>(1c) both (1a) and (1b).
>
>Choice (1a) makes sense to me. New output flags wouldn't be
>interpreted by existing callers; therefore, if such a caller found
>itself atop a mechanism which provided an anonymous context, it would
>start trying to operate on a name with no authenticated meaning.
An existing acceptor-side caller that is likely to try to operate on anonymous
names whether or not a new OID is reserved to denote them. Let's divide
applications into two classes: well-behaved and badly-behaved (from the
viewpoint of how portably they manipulate names).
A well-behaved application will not use string-form names obtained from GSSAPI
for any purpose other than to display to the user. For access-control
purposes, such an application should invoke gss_import_name on names known to
be allowed the desired access, and use gss_compare_name to test whether the
client's authenticated name is one of the allowed names. This strongly argues
that an anonymous name should never be matched by gss_compare_names with any
other name (anonymous or not). This type of application won't care whether
anonymous names are denoted by a similar or different OID to regular names, as
it won't use the returned name-type OID for anything. In fact, it shouldn't
really care whether the name is anonymous or not, since gss_compare_names
should "do the right thing" with anonymous names. gss_display_name should
return something other than an empty string, so that auditing or
user-displaymessages don't get messed up, but it's up to the implementation to
pick a string name-form that can't be mistaken by a human for a real name in
any of the supported name-spaces.
A badly-behaved application will assume something about the string-form of the
name, and will use gss_display_name to obtain the string-form of the client's
authenticated name, and then search its ACLs on that. This is bad (or at least
non-portable) behavior, since string-form names vary widely in syntax and
matching rules between mechanisms. I assume that it is this type of
application that is referred to above ("...if such a caller found itself atop a
mechanism which provided an anonymous context, it would start trying to operate
on a name with no authenticated meaning"). If such an application checked the
name-type output from gss_display_name, then it might treat obtaining an
unexpected name-type as a hint that this name is a bit special, but I don't
know what it could reasonably do with that knowledge.
I'm still not quite sure what the proposal is here. If it is simply to define
a new OID that gss_display_name can deliver to indicate that the internal-name
it has been asked to translate represents an anonymous name, then I don't see
any real problem, except that the name-space from which the anonymous name was
drawn will be lost. For example, by calling gss_display_name, a user wouldn't
be able to distinguish between a anonymous Kerberos name and an anonymous X.500
name (for a GSSAPI that supported both Kerberos and X.509 mechanisms). This
probably isn't a significant loss of information, though.
If, on the other hand, the proposal is to require the support of a particular
format for gss_name_t that all implementations should support, that's much more
problematic, as today gss_name_t is unconstrained.
>Given that (1a) is needed, we could add (1b) as well, thereby
>comprising (1c), but I don't see that we gain compelling benefit from
>this apparent redundancy.
If we define the anonymous bit for req_flags/ret_flags in gss_init_sec_context,
we have to reserve it in the "bit-space" for these flag values. Therefore it
doesn't cost us anything to let gss_accept_sec_context return it as well. So
far, the ret_flags arguments are identical in gss_init_sec_context and
gss_accept_sec_context; I'd hate to see an asymmetry introduced for no reason.
Also, if the acceptor application really cares about whether or not the client
is anonymous (in the sense of wanting to do something different when with
anonymous access), it's easier for it to find out via a bit returned by
gss_accept_sec_context() than to have to fuss with calling gss_display_name(),
especially as portable application currently should only use gss_display_name()
for user-display.
>unlike other output flags,
>this one would need to be valid not only when gss_init_sec_context
>returns GSS_COMPLETE but also on predecessor calls indicating
>GSS_CONTINUE_NEEDED.
That's true. This constraint should probably be re-worded to say something
like that until GSS_COMPLETE is returned, the ret_flags arguments should
indicate a mechanism's best-guess as to what the context will provide, and in
particular if GSS_C_ANONYMOUS_FLAG (or whatever it's called) is set in
gss_init_sec_context's ret_flags argument, then the client's identity will not
have been included in any emitted token.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04770;
26 Jan 95 12:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04766;
26 Jan 95 12:28 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09342;
26 Jan 95 12:28 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <LAA23785 at pad-thai.cam.ov.com>; Thu, 26 Jan 1995 11:45:22 -0500
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA22138; Thu, 26 Jan 95 11:42:32 EST
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.9/mcc.8.6.9) with SMTP id KAA14911; Thu, 26 Jan 1995 10:41:58 -0600
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA09663; Thu, 26 Jan 95 10:41:57 CST
Date: Thu, 26 Jan 95 10:41:57 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9501261641.AA09663 at krypton.mcc.com>
To: wray at tuxedo.enet.dec.com
Cc: linn at cam.ov.com, cat-ietf at mit.edu
In-Reply-To: <9501261551.AA28971 at us1rmc.bb.dec.com> (wray at tuxedo.enet.dec.com)
Subject: RE: Thoughts on anonymity
(I don't think this made it out the first time, so I'll try again :-)
John> to the user. For access-control purposes, such an
John> application should invoke gss_import_name on names known to
John> be allowed the desired access, and use gss_compare_name to
John> test whether the client's authenticated name is one of the
John> allowed names. This strongly argues that an anonymous name
Hmmm ... this could be costly, versus handing the name to an access
control layer to determine the access rights associated with the name.
- Doug
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05431;
26 Jan 95 13:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10177;
26 Jan 95 13:06 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05380;
26 Jan 95 13:06 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05172;
26 Jan 95 12:56 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-dorner-content-header-01.txt
Date: Thu, 26 Jan 95 12:56:45 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501261256.aa05172 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Communicating Presentation Information in Internet
Messages: The Content-Disposition Header
Author(s) : R. Troost, S. Dorner
Filename : draft-dorner-content-header-01.txt
Pages : 8
Date : 01/25/1995
This memo provides a mechanism whereby messages conforming to the [RFC
1521] ("MIME") specification can convey presentational information. It
specifies a new "Content-Disposition" header, optional and valid for any
[RFC 1521] entity ("message" or "body part"). Two values for this header
are described in this memo; one for the ordinary linear presentation of the
body part, and another to facilitate the use of mail to transfer files. It
is expected that more values will be defined in the future, and procedures
are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such,
the reader is assumed to be familiar with [RFC 1521], [RFC 1522],
and [RFC 822]. The information presented herein supplements
but does not replace that found in those documents.
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-dorner-content-header-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dorner-content-header-01.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-dorner-content-header-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 cnri.reston.va.us.
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: <19950125144849.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-dorner-content-header-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dorner-content-header-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950125144849.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05432;
26 Jan 95 13:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10175;
26 Jan 95 13:06 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05393;
26 Jan 95 13:06 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05126;
26 Jan 95 12:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-rekhter-ip-atm-architecture-00.txt
Date: Thu, 26 Jan 95 12:55:04 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501261255.aa05126 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IP Architecture Extensions for ATM
Author(s) : Y. Rekhter, D. Kandlur
Filename : draft-rekhter-ip-atm-architecture-00.txt
Pages : 8
Date : 01/25/1995
The original IP architecture assumes that each Data Link subnetwork is
labeled with a single IP network number. As indicated in RFC1620, this
assumption may be violated for large data networks, including ATM-based
networks. The architecture works even when this assumption is violated, but
it imposes constraints on communication among hosts and routers through an
ATM-based network, which in turn may preclude full utilization of ATM
capabilities. This document describes extensions to the IP architecture
that relaxes these constraints, thus enabling the full utilization of the
services provided by ATM.
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-rekhter-ip-atm-architecture-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rekhter-ip-atm-architecture-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-rekhter-ip-atm-architecture-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950125165425.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-rekhter-ip-atm-architecture-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-ip-atm-architecture-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950125165425.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05446;
26 Jan 95 13:06 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10176;
26 Jan 95 13:06 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05391;
26 Jan 95 13:06 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05247;
26 Jan 95 12:59 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mailext-smtpas-00.txt
Date: Thu, 26 Jan 95 12:58:58 -0500
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9501261259.aa05247 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail Extensions Working Group
of the IETF.
Title : Requirements for Internet Mail Transport Agents
Author(s) : J. Klensin, N. Freed, K. Moore, J. Houttuin
Filename : draft-ietf-mailext-smtpas-00.txt
Pages : 11
Date : 01/25/1995
This document reflects apparent ambiguities in RFC 821 that remain after
the clarifications in RFC 1123. It also includes some material from RFC
1123 that appeared to need amplification. These have been identified in
multiple ways, mostly by tracking flaming on the header-people list and
problems of unusual readings or interpretations that have turned up as the
SMTP extensions have been deployed. It is important to note that
everything here is in response to some identified confusion or bad
behavior, not just paranoia.
Although SMTP was designed as a mail transport and delivery protocol,
this specification also contains information that is important to
its use as a "mail posting" protocol, as recommended for POP3 [RFC-POP3]
and IMAP4 [RFC-IMAP4].
Except when the historical terminology is necessary for clarity,
this document uses the current "client" and "server" terminology to
identify the sending and receiving SMTP processes, respectively.
A companion document discusses mail bodies and formats: RFC-822, MIME,
and their relationship.
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-mailext-smtpas-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-smtpas-00.txt
Internet-Drafts directories are located at:
o Africa
Address: ftp.is.co.za (196.4.160.2)
o Europe
Address: nic.nordu.net (192.36.148.17)
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-mailext-smtpas-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
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: <19950125142021.I-D at CNRI.Reston.VA.US>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-smtpas-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-smtpas-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19950125142021.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05626;
26 Jan 95 13:15 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05622;
26 Jan 95 13:15 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa10360;
26 Jan 95 13:15 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <MAA24685 at pad-thai.cam.ov.com>; Thu, 26 Jan 1995 12:22:39 -0500
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA26902; Thu, 26 Jan 95 12:18:33 EST
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94)
id AA01542; Thu, 26 Jan 95 09:14:22 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA04494; Thu, 26 Jan 95 12:14:46 -0500
Message-Id: <9501261714.AA04494 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Thu, 26 Jan 95 12:14:46 EST
Date: Thu, 26 Jan 95 12:14:46 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 26-Jan-1995 1200" <wray at tuxedo.enet.dec.com>
To: rosenthl at mcc.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, rosenthl at mcc.com
Subject: RE: Thoughts on anonymity
Doug,
> John> to the user. For access-control purposes, such an
> John> application should invoke gss_import_name on names known to
> John> be allowed the desired access, and use gss_compare_name to
> John> test whether the client's authenticated name is one of the
> John> allowed names. This strongly argues that an anonymous name
>
>Hmmm ... this could be costly, versus handing the name to an access
>control layer to determine the access rights associated with the name.
Yes, it could be expensive. But doing anything else would seem to require some
knowledge by the application about name syntax (or, worse, the semantics
implied by a name), which implies non-portability. So currently GSSAPI
applications may have to make a choice between portability and efficiency.
Maybe the time is right to start to consider GSSAPI authorization services.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07097;
26 Jan 95 14:22 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07093;
26 Jan 95 14:22 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa11748;
26 Jan 95 14:22 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <NAA26825 at pad-thai.cam.ov.com>; Thu, 26 Jan 1995 13:49:59 -0500
Received: from turtle.mcc.com by MIT.EDU with SMTP
id AA08146; Thu, 26 Jan 95 13:47:09 EST
Received: from krypton.mcc.com (krypton.mcc.com [128.62.30.63]) by turtle.mcc.com (8.6.9/mcc.8.6.9) with SMTP id MAA16844; Thu, 26 Jan 1995 12:47:03 -0600
Received: by krypton.mcc.com (4.1/isd-other_920825_17:05)
id AA09905; Thu, 26 Jan 95 12:47:02 CST
Date: Thu, 26 Jan 95 12:47:02 CST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Doug Rosenthal <rosenthl at mcc.com>
Message-Id: <9501261847.AA09905 at krypton.mcc.com>
To: wray at tuxedo.enet.dec.com
Cc: cat-ietf at mit.edu
In-Reply-To: <9501261714.AA04494 at us1rmc.bb.dec.com> (wray at tuxedo.enet.dec.com)
Subject: RE: Thoughts on anonymity
John> Yes, it could be expensive. But doing anything else would
John> seem to require some knowledge by the application about name
John> syntax (or, worse, the semantics implied by a name), which
John> implies non-portability. So currently GSSAPI applications
John> may have to make a choice between portability and
John> efficiency.
It would not necessarily be the application that would need to
understand naming syntax/semantics, but the access control mechanism
certainly would. Thus:
John> Maybe the time is right to start to consider GSSAPI
John> authorization services.
Indeed; some things to consider here:
- There is already a separate Access Control and Authorization WG,
although I don't think they've been active lately; however, since
the GSSAPI is intended to accommodate "Generic Security Services",
it seems that it could/should include access control (authorization)
services
- There are various paradigms for authorization services; I think of
them as "push" .vs. "pull" models, i.e. whether authorization
information is provided with credentials .vs. being looked-up based
on a name/identity that the credentials authenticate
Doug
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01779;
27 Jan 95 8:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01775;
27 Jan 95 8:50 EST
Received: from [192.231.148.11] by CNRI.Reston.VA.US id aa04540;
27 Jan 95 8:50 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA14649 at pad-thai.cam.ov.com>; Fri, 27 Jan 1995 08:14:48 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA07309; Fri, 27 Jan 95 08:11:58 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA14644 at pad-thai.cam.ov.com>; Fri, 27 Jan 1995 08:14:45 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA15875; Fri, 27 Jan 95 08:14:43 EST
Message-Id: <9501271314.AA15875 at winkl.cam.ov.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 26-Jan-1995 0944" <wray at tuxedo.enet.dec.com>
Cc: linn at cam.ov.com, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Thoughts on anonymity
In-Reply-To: Your message of "Thu, 26 Jan 1995 10:51:52 EST."
<9501261551.AA28971 at us1rmc.bb.dec.com>
Date: Fri, 27 Jan 1995 08:14:43 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
John,
I'm not sure that gss_compare_name comparison of one anonymous name
against another should necessarily indicate inequality. I can
imagine, e.g., constructing an ACL structure and associated
interpreter in which the rights accorded to anonymous accessors are
represented explicitly in an entry carrying the anonymous name; here,
a compare_name match would be exactly the right thing to look for in
searching for the right ACL entry.
>I'm still not quite sure what the proposal is here. If it is simply
>to define a new OID that gss_display_name can deliver to indicate that
>the internal-name it has been asked to translate represents an
>anonymous name, then I don't see any real problem, except that the
>name-space from which the anonymous name was drawn will be lost. For
>example, by calling gss_display_name, a user wouldn't be able to
>distinguish between a anonymous Kerberos name and an anonymous X.500
>name (for a GSSAPI that supported both Kerberos and X.509 mechanisms).
>This probably isn't a significant loss of information, though.
This was just the sort of OID definition I had in mind. I'll also note
that the information about what mechanism indicated an anonymous name
could be acquired outside the name (for whatever value it has to
offer) by checking the mechanism ID associated with the context.
>If, on the other hand, the proposal is to require the support of a
>particular format for gss_name_t that all implementations should
>support, that's much more problematic, as today gss_name_t is
>unconstrained.
I think the OID is really the right place to look for the anonymity
indicator. I wasn't really concerned about what would be found in
the associated name itself, but thought that some statement was needed.
Can we simply make a statement that, for the name type identified by
the "anonymous" OID, the contents of the name itself is undefined?
>>Given that (1a) is needed, we could add (1b) as well, thereby
>>comprising (1c), but I don't see that we gain compelling benefit from
>>this apparent redundancy.
>
>
>If we define the anonymous bit for req_flags/ret_flags in
>gss_init_sec_context, we have to reserve it in the "bit-space" for
>these flag values. Therefore it doesn't cost us anything to let
>gss_accept_sec_context return it as well. So far, the ret_flags
>arguments are identical in gss_init_sec_context and
>gss_accept_sec_context; I'd hate to see an asymmetry introduced for no
>reason.
>
>Also, if the acceptor application really cares about whether or not
>the client is anonymous (in the sense of wanting to do something
>different when with anonymous access), it's easier for it to find out
>via a bit returned by gss_accept_sec_context() than to have to fuss
>with calling gss_display_name(), especially as portable application
>currently should only use gss_display_name() for user-display.
OK by me. I think we're converging on a proposal.
>>unlike other output flags,
>>this one would need to be valid not only when gss_init_sec_context
>>returns GSS_COMPLETE but also on predecessor calls indicating
>>GSS_CONTINUE_NEEDED.
>
>That's true. This constraint should probably be re-worded to say
>something like that until GSS_COMPLETE is returned, the ret_flags
>arguments should indicate a mechanism's best-guess as to what the
>context will provide, and in particular if GSS_C_ANONYMOUS_FLAG (or
>whatever it's called) is set in gss_init_sec_context's ret_flags
>argument, then the client's identity will not have been included in
>any emitted token.
I think this works.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01819;
27 Jan 95 8:53 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01814;
27 Jan 95 8:53 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa04624;
27 Jan 95 8:53 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA14829 at pad-thai.cam.ov.com>; Fri, 27 Jan 1995 08:28:26 -0500
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA08088; Fri, 27 Jan 95 08:25:36 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <IAA14825 at pad-thai.cam.ov.com>; Fri, 27 Jan 1995 08:28:24 -0500
Received: by winkl.cam.ov.com (4.1/4.7) id AA15891; Fri, 27 Jan 95 08:28:18 EST
Message-Id: <9501271328.AA15891 at winkl.cam.ov.com>
To: Doug Rosenthal <rosenthl at mcc.com>
Cc: wray at tuxedo.enet.dec.com, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Access Control/Authorization
In-Reply-To: Your message of "Thu, 26 Jan 1995 12:47:02 CST."
<9501261847.AA09905 at krypton.mcc.com>
Date: Fri, 27 Jan 1995 08:28:18 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Doug writes:
>- There is already a separate Access Control and Authorization WG,
> although I don't think they've been active lately; however, since
> the GSSAPI is intended to accommodate "Generic Security Services",
> it seems that it could/should include access control (authorization)
> services
A suggestion was made and accepted at the December IETF to carry out
upcoming access control/authorization work under the framework
of the CAT WG. This was one of the changes I reflected
earlier this month in the revised WG charter, as a focus once we
progress ongoing work on GSS-V2.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02660;
27 Jan 95 9:59 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02656;
27 Jan 95 9:59 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa06264;
27 Jan 95 9:59 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.6.8/) with SMTP
id <JAA15909 at pad-thai.cam.ov.com>; Fri, 27 Jan 1995 09:18:22 -0500
Received: from inet-gw-1.pa.dec.com by MIT.EDU with SMTP
id AA11801; Fri, 27 Jan 95 09:15:31 EST
Received: from us1rmc.bb.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94)
id AA02493; Fri, 27 Jan 95 06:06:37 -0800
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA27658; Fri, 27 Jan 95 09:07:02 -0500
Message-Id: <9501271407.AA27658 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 27 Jan 95 09:07:02 EST
Date: Fri, 27 Jan 95 09:07:02 EST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 27-Jan-1995 0848" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@in.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Thoughts on anonymity
John,
>I'm not sure that gss_compare_name comparison of one anonymous name
>against another should necessarily indicate inequality. I can
>imagine, e.g., constructing an ACL structure and associated
>interpreter in which the rights accorded to anonymous accessors are
>represented explicitly in an entry carrying the anonymous name; here,
>a compare_name match would be exactly the right thing to look for in
>searching for the right ACL entry.
On the other hand, a server may want to check whether two clients are the same,
and you certainly don't want a server that doesn't understand anonymous access
to believe that all anonymous clients are identical.
If an application has knowledge of anonymity, then it can special-case the
access-control if it wants "anonymous" to be treated as a normal name. Access
by anonymous principals is likely to be a special-case anyway, unless the
application is only interested in auditing, in which case compare_names() isn't
relevant. On the other hand, a server that doesn't expect to be invoked
anonymously should "fail-safe" if it is called that way, which to me means that
we shouldn't claim equivalence between two anonymous names.
>>If, on the other hand, the proposal is to require the support of a
>>particular format for gss_name_t that all implementations should
>>support, that's much more problematic, as today gss_name_t is
>>unconstrained.
>
>I think the OID is really the right place to look for the anonymity
>indicator. I wasn't really concerned about what would be found in
>the associated name itself, but thought that some statement was needed.
>Can we simply make a statement that, for the name type identified by
>the "anonymous" OID, the contents of the name itself is undefined?
How's this:
The internal structure of a gss_name_t object should be defined by the
mechanism. When invoked on a gss_name_t representing an anonymous identity,
gss_display_name() should return the "anonymous name-type", as well as a
printable string that clearly indicates that the name is not a "normal"
name for any of the supported mechanisms.
A printable string form is important for user display, and for auditing
purposes. The only problem I can see with the above is that it's conceivable
(although unlikely) that a GSSAPI implementation might support so many
different name-spaces that it's impossible to choose a string-form that's
illegal or obviously "strange" in all of them, while still obviously conveying
the concept of "anonymity". That's the only reason I can really think of for
wanting to preserve the original name-space that the anonymous name came from
(it's easier to invent a name that's illegal in one name-space, than one that's
illegal in all). I don't think this is a major problem, though.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11659;
1 Jan 95 0:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11653;
1 Jan 95 0:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23177;
1 Jan 95 0:09 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11639;
1 Jan 95 0:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11585;
1 Jan 95 0:03 EST
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa23049; 1 Jan 95 0:03 EST
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA29428 for ietf at cnri.reston.va.us; Sun, 1 Jan 95 00:03:44 -0500
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id VAA23426; Sat, 31 Dec 1994 21:01:39 -0800
Message-Id: <199501010501.VAA23426 at aland.bbn.com>
To: "Thomas A. Kalil" <tkalil at arpa.mil>
Cc: ietf at CNRI.Reston.VA.US
Subject: thoughts about G-7
In-Reply-To: Your message of Thu, 29 Dec 94 20:29:18 -0500.
<199412300129.AA13798 at vax.darpa.mil>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Sat, 31 Dec 94 21:01:34 -0800
X-Orig-Sender: craig at aland.bbn.com
> One idea under consideration is a testbed that would promote multi-vendor
> interoperability for ATM signalling, traffic management, and IP over ATM.
> Since there is some concern that the governments not mandate ATM -- I'd
> be interested to know what other technologies the governments should
> consider sponsoring for research/testbed activities to advance
> high-speed, wide-area networking.
Hi Thomas:
When a review was done of the US gigabit testbed program last summer, one of
the interesting observations was that, perhaps as a by product, it had
helped the carriers make tremendous strides understanding the Synchronous
Digital Hierarchy (SDH) protocols (like SONET). Since most plans for
widely available high speed networking assume that the networking protocols
(like ATM) will run over high-speed SONET links, I would suggest that the G-7
encourage group experiments using SONET in particular, inter-country
links running at 155 Mb/s and 622 Mb/s.
I'll note that a SONET project would benefit a large number of folks. Within
many countries, such a project would push the national phone companies
to upgrade some of their long haul links -- aiding high-speed research in
those countries. Speaking from a purely US perspective, the US government
(esp. the US military) is likely to be a big user of high-speed SONET capacity
if we can encourage more countries to upgrade their switching capacity.
Craig Partridge
Phone/Fax: +1 415-326-4541
PS: Nothing I say here should be construed as necessarily representing the
views of BBN, Stanford University, the New England Historic Genealogical
Society or any other group I happen to be affiliated with :-).
PPS: Minor comment. While it may seem that if one says, "do a joint ATM
experiment", it will necessarily cause work on high speed SONET, it ain't
necessarily so. And we need high speed SONET far more than we need ATM.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12411;
1 Jan 95 3:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12405;
1 Jan 95 3:31 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27336;
1 Jan 95 3:31 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12393;
1 Jan 95 3:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12346;
1 Jan 95 3:27 EST
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa27236;
1 Jan 95 3:27 EST
Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14444(5)>; Sun, 1 Jan 1995 00:27:28 PST
Received: by redwing.parc.xerox.com id <57153>; Sun, 1 Jan 1995 00:27:18 -0800
Date: Sun, 1 Jan 1995 00:27:13 PST
X-Orig-Sender: Lixia Zhang <lixia at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Lixia Zhang <lixia at parc.xerox.com>
To: "Peter S. Ford" <peter at goshawk.lanl.gov>
Cc: matsb at sics.se, "Thomas A. Kalil" <tkalil at arpa.mil>,
ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
In-Reply-To: Your message of Sat, 31 Dec 1994 11:11:21 -0800
Message-ID: <CMM.0.88.788948833.lixia at parc.xerox.com>
Peter,
I believe we actually agree on most of the points you raised. Maybe I
didn't make myself clear the first time, so let me try again.
Just like you, I support wholeheartedly the government involvement in
developing a global, scalable infrastructure, and I too believe in the
value of a running testbed. I was merely arguing against a testbed
that focuses exclusively on ATM technology. As I said earlier, I
think the research & development effort should focus on the IP
architecture, on how to further evolve/enhance IP to better support
the global internet. We all want to see G-7 testbed as an IP/IPng testbed.
(likely ATM will be one of the subnet technologies deployed; however
not only ATM can run, BTM or CTM should also be able to join)
I also share the worry with you about carriers deploying various
solutions of their own that may or may not fit the global IP
architecture in an optimal way. If we can help a
government-sponsored testbed choose the right focus on IP, that would,
I feel, have some positive influence over carriers future directions.
I'd further agree with you on the need for consolidating telecom
switching fabric so that IP can both explore the full advantages of
latest switching technology and be better supported. In fact I
personally am involved in a research proposal of building a gigabit IP
switch out of ATM switch fabric, and I hope it can get funded. To
ride on top of various network technologies, IP certainly needs to
work *with* them; my earlier statement was not meant to suggest
otherwise.
1994 has been a great year for the Internet. May the coming year be an
even more splendid one.
Lixia
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01121;
1 Jan 95 7:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01115;
1 Jan 95 7:29 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04684;
1 Jan 95 7:29 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01102;
1 Jan 95 7:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01054;
1 Jan 95 7:23 EST
Received: from LINC.CIS.UPENN.EDU by CNRI.Reston.VA.US id aa04571;
1 Jan 95 7:22 EST
Received: from [130.91.88.102] (MACPOND.CIS.UPENN.EDU [130.91.88.102]) by linc.cis.upenn.edu (8.6.9/UPenn 1.4) with SMTP
id HAA22332; Sun, 1 Jan 1995 07:23:08 -0500
Posted-Date: Sun, 1 Jan 1995 07:23:08 -0500
X-Sender: farber at linc.cis.upenn.edu
Message-Id: <v02110119ab2c4eb50d71 at [130.91.88.102]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 1 Jan 1995 07:23:11 -0500
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Farber <farber at central.cis.upenn.edu>
Subject: Re: J'Accuse, ATM
Cc: "Thomas A. Kalil" <tkalil at arpa.mil>
You may want to read my "New Years Editorial" sent to my
Interesting People "subscribers".
See http://macpond.cis.upenn.edu/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02313;
1 Jan 95 12:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02307;
1 Jan 95 12:50 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11033;
1 Jan 95 12:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02295;
1 Jan 95 12:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02259;
1 Jan 95 12:46 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa10937; 1 Jan 95 12:46 EST
Received: from Eng.Sun.COM ([129.145.1.18]) by Sun.COM (sun-barr.Sun.COM)
id AA07386; Sun, 1 Jan 95 09:47:07 PST
Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1)
id AA16630; Sun, 1 Jan 95 09:46:57 PST
Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4)
id JAA27051; Sun, 1 Jan 1995 09:47:08 -0800
Date: Sun, 1 Jan 1995 09:47:08 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Hinden <Bob.Hinden at eng.sun.com>
Message-Id: <199501011747.JAA27051 at jurassic.Eng.Sun.COM>
To: ietf at CNRI.Reston.VA.US
Subject: Re: J'Accuse, ATM
Folks,
I note that in many of the debates of ATM vs [IP, Fast Ethernet, etc.]
that people tend to fall into the trap of comparing what ATM will/might
do in the future, with what, for example, IP does today.
For example at Paris Interop in a debate between ATM and Fast Ethernet,
the ATM proponent made a comparison between the quality of video
conferencing of ATM and the current MBONE video/audio and claimed that
ATM was much better. What was left unsaid was what he was comparing the
current MBONE facilities (56K, T1, non-native multicast router support,
etc.) to what ATM would do using 155M OC-3 lines and ATM switches. If
the MBONE was upgraded to OC-3 lines and routers (with native multicast
support), then I suspect that even with the current generation of
multicast protocols and applications, the quality would be excellent.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01120;
2 Jan 95 7:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01114;
2 Jan 95 7:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05169;
2 Jan 95 7:48 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01083;
2 Jan 95 7:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00968;
2 Jan 95 7:31 EST
Received: from mail02.mail.aol.com by CNRI.Reston.VA.US id aa04832;
2 Jan 95 7:31 EST
Received: by mail02.mail.aol.com
(1.38.193.5/16.2) id AA24240; Mon, 2 Jan 1995 07:32:44 -0500
Date: Mon, 2 Jan 1995 07:32:44 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Telford001 at aol.com
Message-Id: <950102073244_4478116 at aol.com>
To: peter at goshawk.lanl.gov, lixia at parc.xerox.com, matsb at sics.se
Cc: tkalil at arpa.mil, ietf at CNRI.Reston.VA.US, Telford001 at aol.com
Subject: J'accuse les anti-ATMusards
>Mats and Lixia,
>I think you are missing a lesson from history when you push back on in
>government involvement in the development of a global, scalable
>infrastructure. The Internet is a case study in the effective use of
>"testbeds" brought about by government involvement.
Is this true without qualification? The Arpanet was funded by
DARPA but in fact the Arpanet technology has been basically
abandoned. The protocols developed in the context of the Arpanet
have had some success but mostly because of the use of this
technology in LAN environments which were developed privately
and not in "testbeds" brought about by government involvement.
Probably, the key achievement of US government funding
has been proof of concept. Once the Arpanet proved the
viability of computer internetworking, parties not associated
with the DARPA development programs provided superior
more cost effective technology, and the technology developed
under government aegis was abandoned.
Note that IPX has had success approximately equal to that of the
DARPA protocols without any involvement by the US government
in its development at all except that the US government had
previously proven possible the sort of resource sharing which
Novell IPX was to provide.
Would it have made sense for the US government to spend money
on Novell IPX? Does it make sense for the US government to
spend megabucks on computer internetworking testbeds?
The concept has been proven to work. Private investors can
fund such development. The US government should find some
completely new proposed technology where spending a relatively
small sum could provide invaluable proof of concept.
>
This
is one of the
>big reasons you see industry *asking* governments to support testbeds.
Individuals and businesses rarely restrain themselves from
seeking government support and largesse whether or not they
need it.
>Many people believe that one of the reasons the Internet
>experience has been successful is that it forced deployment and testing
>of technologies with a keen focus on interoperability. Many of these
>people believe this was THE major reason GOSIP(s) failed. Compare:
> The technologies of the future are listed in this GOSIP
> document
>with
> The following network(backbone) is being built, and if you run this
> set of protocols you may have interconnectivity with
> a large set of people/machines you are interested in
> talking to.
Paul Krugman might just argue that the success of DARPA style
networking versus ISO OSI style networking is simply an example
of the QWERTY principle. It can be hard to compete with the inertia
of an existing technological structure.
But Novell has proved that alternate protocol suites could
compete when associated with an application and product which
DARPA style networking did not address well.
Perhaps if ISO OSI had provided a "killer" application, the framework
of this discussion would be quite different.
>Both of these are effectively what voices in the U.S. government
>said at about the same time. And, I don't think this was unique to the U.S.
>Testbeds are just that, testbeds. If they indicate that some technology
>is not up to snuff, that is a great result.
Unfortunately, testbeds really cannot provide such indication. They
can prove that a technology can work. If the technology appears
"not up to snuff," that result might provide indication about the quality of
a specific design or the quality of the implementors. If the technology
does not work, it is possible that the underlying concept may be flawed,
that the designs were wrong, the implementors were not up to the task
or the materials available were not up to the task. Babbage's failure
with the difference machine hardly proved that the concept of the
automatic computer was fundamentally flawed.
There is some evidence that too much has been inferred from
some of the limitations of the ARPANET technology. With few
(maybe only one exception), no-one has attempted to design and
build a low-cost high-bandwidth multiprotocol wide-area switching
fabric communications subnet which uses the ARPANET model
of delivery to the subnet rather than the terminal network
model of X.25, FR and now ATM.
> I would
rather see real
>results from a testbed than read the debates on the ietf mailing lists
>that try to pass for thought experiments (the ATM discussions seem to
>come to mind).
Just remember to analyze these results cum grano salis.
> A good mix of venture capital and government
spending
>seems to have yielded pretty good results in the past. I would argue
>this is a good test for spending government funds is if more than
>just the government is willing to, and actually do, pony up
>significant funding for testbed or technology deployment trials. In
>these cases you are more likely to be using "the taxpayers' money"
>wisely.
But private capital is likely to invest when the result of that
investment is getting a lucrative seat on the government gravy
train.
>Another nice feature of testbeds is that they foster inter-enterprise
>collaborations. This is critically important in the global telecom
>world, where the actions of old monopolies are often so heavily
>scrutinized and feared that it hampers innovation, experimentation and
>work with similar companies.
This comment really has to be qualified. Computer internetworking
isn't rocket science. Scheduling and staffing the development of a
high performance switching product is fairly straightforward.
The problems are fairly well understood. The
hardware and software development environments even in the
case of chip design are not particularly expensive. Computer
internetworking simply does not require that the government
make a special effort to create an environment for
inter-enterprise collaboration to facilitate innovation or
experimentation.
If the government wants to throw a lot of money at the development
of internetworking technology and some lands in my direction,
I would not reject it, but government spending in this area except
as a consumer would probably be misdirected.
>>>> We need to worry about the *infrastructure* of the future global
>>>> internet, issues like system robustness, scalability, and
>>>> heterogeneity (of the underneath technologies); let the industry and
>>>> market take care of technologies. As long as we do our IP/IPng right,
>>>> we'll just run IP on top of whatever technology they happen to provide
>>>> for the day.
>At one level this sounds right, but I think it is tragically flawed. If
>IP/IPng is a base technology for "the future global internet" then it
>should be able to meet the requirements of "the industry and market".
>We want the industry to deploy this stuff (IP/IPng) in a big way. I would
>like my telecom providers to be able to deploy and operate Internet
>technology in a cost effective manner.
Except for tariffing rules and the laws related to common carriage,
the telecom providers could probably do this right now.
> Today this is
really hard and not
>very cost effective. We are getting to the point where we *HAVE* to worry
>about consolidating the telecom switching fabric so that it is scalable and
>cost effective. Today carriers deploy too many switching solutions and
>it is keeping telcom costs high. And simply layering routers on top is
>a reasonable intermediate solution to get an Internet, but I would much
>rather see a simple layering:
> Internet Switching and Signalling
> Transmission (current leading candidates: SONET and T-* hierarchy)
>The techology needs of the industry and market are include those of the
>future global Internet. I have yet to see a reason why telecom
>switching and signalling technology needs to be different from
>Internet switching and signalling technology. I would agree that
>Internet switching and signalling should not depend on telcom
>switching and signalling.
There is a big difference in the model between voice
circuit switching and computer internetwork packet switching.
When a voice call is placed, the network is designed so that
it can on the basis of call information choose the necessary
resources which are statically allocated end-to-end for
the duration of the call.
In the DARPA IP model, the end node delivers the packet to the
communications subnet which is responsible for getting the
packet to its next hop. A communications subnet allocates
resources dynamically as needed. The communications subnet
dynamically learns how to best deliver packets to the next
hop.
In the case where the packet might have to be routed through
several networks, the source network delivers the
packet to second order communications subnet which is composed
of the network of routers, and this second order communications
subnet is responsible for getting the packet to its destination
network. The second order communications subnet dynamically
learns how to best deliver packets to the destination network.
X.25, FR and ATM conform to a terminal network model
wherein terminals connect to computers via virtual circuits
provided by a packet network. The model is closer to the voice
call model than to the DARPA IP model.
Integrating all these models in the context of telephony
technology is a serious problem. There is a very large mostly
TDM based network which really is not well suited to
internetworking needs but which handles voice perfectly.
The telcos apparently want to reduce the amount of cabling
and the amount of equipment used to hook customers
up to their digital networks.
The telcos do not want to create a parallel internetworking
packet switched network. Cell switching with a mechanism
to arbitrate allocation of the cells between connections
is not an unreasonable approach to using telephony
technologies in situations which require constant
fixed allocations of bandwidths while still having the
capability to allocate bandwidth more dynamically.
Thus with a single hook-up to the local office, the telco
could provide
1) effective constant bandwidth switching for voice, video,
teleconferencing,
2) dynamically allocated bandwidth for terminal network style
connectivity and
3) dynamically allocated bandwidth for an exterior IP style
packet switched network to connect multiple autonomous
internetworking systems or dynamically allocated bandwidth
for a private interior IP style network which could connect
multiple areas within an autonomous internetworking system.
For the last service, the most direct approach would be to
build the ARPANET model of connectivity into the ATM
switching fabric. Unfortunately, doing that would require
some government policy changes and some modifications of
the laws which apply to common carriage.
Nevertheless useful networking connectivity can be provided
with the terminal network model. In either case it might
be reasonable for the telcos to provide routing information
to customers either via an exterior gateway protocol
or via an interior gateway protocol.
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.
