[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
BTW, I think Ran Atkinson's posting expressed this all quite clearly.
Ned
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13472;
28 Jul 93 17:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00704;
28 Jul 93 17:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13454;
28 Jul 93 17:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13373;
28 Jul 93 17:29 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa00569;
28 Jul 93 17:29 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA12346>; Wed, 28 Jul 1993 14:29:53 -0700
Message-Id: <199307282129.AA12346 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1493 on Bridge MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 28 Jul 93 14:29:45 PDT
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 1493:
Title: Definitions of Managed Objects for Bridges
Author: E. Decker, P. Langille, A. Rijsinghani, &
K. McCloghrie
Mailbox: cire at cisco.com, langille at edwin.enet.dec.com,
anil at levers.enet.dec.com, kzm at hls.com
Pages: 34
Characters: 74,493
Obsoletes: 1286
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 MAC bridges based on the
IEEE 802.1D-1990 standard between Local Area Network (LAN) segments.
Provisions are made for support of transparent bridging. Provisions
are also made so that these objects apply to bridges connected by
subnetworks other than LAN segments. This document is the product of
the Bridge MIB Working Group of the IETF.
This is now a Draft Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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 NIC.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 1111, "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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1493.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1493.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13518;
28 Jul 93 17:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13511;
28 Jul 93 17:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00811;
28 Jul 93 17:33 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13498;
28 Jul 93 17:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13428;
28 Jul 93 17:31 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa00675;
28 Jul 93 17:31 EDT
Received: by ginger.lcs.mit.edu
id AA11567; Wed, 28 Jul 93 17:32:11 -0400
Date: Wed, 28 Jul 93 17:32:11 -0400
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: <9307282132.AA11567 at ginger.lcs.mit.edu>
To: ALH at eagle.es.net, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
This whole discussion is based on a serious 'not-invented-here' attitude
that the IETF needs to loose or die.
Look, not everyone who diasagrees with someone has the basest of motives. I
had the interesting experience of talking on the phone over the last two days
with a number of people on both sides of this. Each seemed to think that the
other was manoeuvering darkly in the shadows, while the descriptions they gave
for the own actions i) sounded reasonable to me, and ii) didn't sound anything
like what I was hearing from others. Now, maybe I'm mind-bogglingly gullible,
bit I don't think so. I heard descriptions of people I know and like, that
didn't sound at all like the people I know.
Can we stop please making assumptions about why people are advocating various
things, and simply talk about the technical advantages and disadvantages?
Vendors are VERY reluctant to invest in development of "non-standard"
software, and even more so when there appears to be a political issue
involved.
True, but this whole IPng thing is getting rapidly embroiled in politics.
Can everyone just back off, please?
It suffers from a contingent that would rather 'OWN' the stack than admit
that someone else might have a useful idea.
This is, I reckon, more of an legitimate issue than you seem to think. RFC1310
spends a lot of time talking about use of outside standards. Use of an
outside standard, as is, is fine, provided it doesn't get in the way of making
the network work. Sure, we use ASCII, but it doesn't have anything we want to
change or otherwise limit. Adoption of CLNP as is, with complete backward
compatibility (which is the preferred alternative of the Tuba community, as
far as I could tell), has a number of technical strikes against it (from my
point of view); this makes change control, *and the practical ability to use
it*, a real issue.
For instance, the 173 different allocation schemes for NSAP: we're gonna have
enough problems with to make the routing work in a relatively small Internet,
by reorganizing IPv4 addresses, using CIDR. Trying to accomodate all those
existing NSAP formats (and there will be considerable pressure to do so, let's
not kid ourselves) is going to make things much more difficult. Well, let's
not start a big debate - this is just to illustrate that there are real
technical concerns here, not just 'nih'.
For the last 4 years I have been trying to get the point across that if
the IETF would spend its effort fixing the problems it can identify in the
OSI definitions instead of fighting we would all be ahead.
This seems to make the implicit assumption that the best course for the
Internet is to adopt OSI stuff, and go from there. Are you really ready to
listen to a case that says that this is not necessarily the best idea? If
not, why should others be any more open-minded than you are?
Integrators have long known how to take the best ideas from different
sources and minimize the amount of work they have to do to glue it all
together.
So? This sort of assumes that they are working with a selection of
demonstrated functional pieces. What we're trying to decide is what a workable
design is for an internet layer to support a world-wide internet. I don't
regard it as at all decided that we know which, if any of the designs will do
this. We don't *have* a number of proven options to decide from.
> PS: BTW, if you're doing PIP, SIP, or TP/IX, I'll ask you the same
> questions...
Good.... but you should also ask how well IPv4 will scale over the next
few years.
This is really unfair. Nobody is suggesting that IPv4, *as is*, is an option
for the long term (unless you count NAT). I think everyone agrees that it needs
to be replaced (or finessed with NAT).
And I'll say exactly the same thing as him; if SIP, PIP, or any other
alternative were the subject of this disussion, I'd be saying pretty much
the same thing.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14147;
28 Jul 93 18:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14140;
28 Jul 93 18:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02338;
28 Jul 93 18:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14106;
28 Jul 93 18:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14072;
28 Jul 93 18:28 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa02312;
28 Jul 93 18:28 EDT
Received: by inet-gw-1.pa.dec.com; id AA27129; Wed, 28 Jul 93 15:28:34 -0700
Received: by xirtlu.zk3.dec.com; id AA02290; Wed, 28 Jul 1993 18:28:29 -0400
Message-Id: <9307282228.AA02290 at xirtlu.zk3.dec.com>
To: henryc at oar.net
Cc: desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US, tuba at lanl.gov,
bound at zk3.dec.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Wed, 28 Jul 93 11:59:31 EDT."
<199307281559.AA20882 at loki.oar.net>
Date: Wed, 28 Jul 93 18:28:29 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bound at zk3.dec.com
X-Mts: smtp
Regarding mail on TUBA being deployed. At the IPdecide BOF at the IETF
Amsterdam several times it was stated in the audience that TUBA is a
widely deployed IPng. After the 2cnd or 3rd time Steve Knowles INT Area
Director stood up and basically stated this is a false statement, and
not even the TUBA working group would stand up and make this claim at
the IPdecide BOF. No one stood up.
I would also be very interested in any response to Henrys questions
about CLNP deployment to the scale of the Internet too. Personally I do
not think this matters for the process. If TUBA is the best IPng solution
then whether it is deployed widely or not at all, it can still be selected,
as I understand the IETF process. I believe the phrase is demonstrable
operational code base, across multiple implementations. But as I keep saying
that must include transition code base too. (for Hosts/End Systems too not
just routers).
Regarding 1006 comment on previous mail:
The RFC 1006 comment was unclear to me. 1006 permits OSI apps to run
over TCP. If the statement is saying 1006 could now use OSI services
directly, that still will not be the case with TUBA. The reason is that
the TCP services are not changing or effected by IPng. At least I hope
that does not happen. Maybe I missed the point?
/jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14209;
28 Jul 93 18:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14202;
28 Jul 93 18:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02494;
28 Jul 93 18:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14190;
28 Jul 93 18:34 EDT
Received: from xap.xyplex.com by IETF.CNRI.Reston.VA.US id aa14162;
28 Jul 93 18:33 EDT
Received: by xap.xyplex.com id <AA29436 at xap.xyplex.com>; Wed, 28 Jul 93 20:32:57 -0500
Date: Wed, 28 Jul 93 20:32:57 -0500
Message-Id: <9307290132.AA29436 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: Claudio Allocchio - +39 40 3758523's message of Wed, 28 Jul 1993 21:55:13 +0200 (WET-DST) <930728215513.2ae002de at elettra.trieste.it>
Subject: Re: Last Call: Use of ISO CLNP in TUBA - CLNP in HEPnet.
>Ok, that's all, folks! (Bugs Bunny).
Can we attribute credibility to anyone who can't tell the difference betwen
Bugs Bunny and Porky Pig?
Thufferin' thuccotash! (Sylvester)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14554;
28 Jul 93 19:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14550;
28 Jul 93 19:12 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa03521;
28 Jul 93 19:12 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA16746; Wed, 28 Jul 93 18:12:51 CDT
Received: by hemlock.cray.com
id AA11489; 4.1/CRI-5.6; Wed, 28 Jul 93 18:12:46 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA11485; 4.1/CRI-5.6; Wed, 28 Jul 93 18:12:42 CDT
Received: from MCIGATEWAY.MCIMail.com by cray.com (4.1/CRI-MX 2.19)
id AA16743; Wed, 28 Jul 93 18:12:40 CDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id br02389;
28 Jul 93 23:04 GMT
Date: Wed, 28 Jul 93 20:50 GMT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: IETF TN3270E Working Group List <TN3270E at list.nih.gov>
To: IBM TCPIP List <IBMTCP-L at pucc.princeton.edu>
To: TN3270-L <TN3270-L%RUTVM1.BITNET at pucc.princeton.edu>
To: telnet ietf <telnet-ietf at cray.com>
Subject: TN3270E BOF at INTEROP
Message-Id: <95930728205059/0003858921NA4EM at mcimail.com>
I appologize to any that get this from more than one list....
I have scheduled a BOF on TN3270 for fall INTEROP. The BOF has been slotted
for Thursday, August 26th in the Golden Gate Hall B at the San Francisco
Marriott Hotel. Time is from 7:30pm until 9:30pm.
This should still leave enough time to hit those all important evening
'gatherings'...
Agenda follows.
Bob Moskowitz
Chrysler Corporation
TN3270E Working Group Chair
(313) 758-8212
---------------------------------------------------------------------
AGENDA
TN3270 Enhancements BOF
INTEROP 93 Meeting
August 26, 1993
7:30 - 9:30 (= 19:30 - 21:30)
We expect new faces and we have a lot to cover, with only two
hours, so at the very least we shouldn't get bored.
19:30-19:45
1. Introductions and purpose of the TN3270E WG. 15 min
19:45-20:00
2. Condensed version of the IETF 26 presentation that led to the
formation of this Working Group.
20:00-21:00
3. Discussion and feedback of current RFC drafts.
"Current TN3270 practices" - An Informational RFC
"LUname/Printer Selection" - An Experimental RFC proposal from
Open Connect Systems
"TN3270 Enhancements" - The TN3270 Standards RFC
21:00-21:15
4. Where do we go from here?
Implementation recommendations
Any other general TELNET options to cover?
Promoting drafts to RFCs.
Vendor interest in implementing "TN3270 Enhancements" and
user testing.
21:15-21:30
5. Wrap up. See you all on the list.
Robert Moskowitz
Chrysler Corporation
TN3270E WG Chair
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14642;
28 Jul 93 19:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14635;
28 Jul 93 19:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03683;
28 Jul 93 19:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14623;
28 Jul 93 19:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14600;
28 Jul 93 19:16 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa03652;
28 Jul 93 19:16 EDT
Received: by inet-gw-1.pa.dec.com; id AA01677; Wed, 28 Jul 93 16:17:03 -0700
Received: by xirtlu.zk3.dec.com; id AA03746; Wed, 28 Jul 1993 19:17:01 -0400
Message-Id: <9307282317.AA03746 at xirtlu.zk3.dec.com>
To: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Wed, 28 Jul 93 18:28:29 EDT."
<9307282228.AA02290 at xirtlu.zk3.dec.com>
Date: Wed, 28 Jul 93 19:17:00 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bound at zk3.dec.com
X-Mts: smtp
I think Tracys' response brings me closer to a consensus on this subject
regarding a proposed standard. But, it would be very bad if any IPng
reached proposed standard and then that event was politically abused as
a marketing tool, as opposed to a technical statement of an operational
implementation of an IPng. So I concur with most recent mail on the
political concerns too.
Regarding CLNP of course its deployed and its being used and the sales
from it add value to many econmic concerns. This was not the issue.
The issue is that TUBA and CLNP as it is implemented today are not the
same beast or architecural structure.. Othewise there would be no
need for all the TUBA documents that exist today to support it as an
IPng. TUBA would just reference pointers to ISO documents or make them
Drafts or Informational RFC, whatever, etc...(though this will take
place per TUBA WG mtg to some degree). Because you have CLNP
products does not mean you have a TUBA implementation or prototype or
demo (all being somewhat different in scope and mirrors).
NIH - All I will say is I think this is a red herring of some kind I
have not figured out. NIH typically refers to a creator of some
technology not being able to integrate new technology into their
creation because the creator cannot get past the fact that they did not
invent it. All people working in all IPngs have implementations of
CLNP or are usig it on their premises. So I am unclear why this comment
was even made &^^%%%**..[??]/or/if i cant grep it i dont get it.
Sounds like Standards discussion - Hmmm yes it does. But is that all
bad? Do we want ISO liaisons? Do we want whether TUBA wins the IPng a
CLNP interface defined for TCP/UDP? Maybe we need to think more like
that, though again I am not sure what this comment mean't either. The
risk factors of the IETF changing IPv4 to the next IPng and how that is
done will be very high, unless very well thought out and reviewed by all
the bright people in the IETF. In addition if the next IPng makes
critical mistakes regarding the Global Internets' network layer address
the penalty will be far greater than any previous pain felt from any
previous mistakes. It won't be a quick call to some vendor engineering
group that can hack out a quick fix or temporary algorithm.
/jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14708;
28 Jul 93 19:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14701;
28 Jul 93 19:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03758;
28 Jul 93 19:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14689;
28 Jul 93 19:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14648;
28 Jul 93 19:18 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03697;
28 Jul 93 19:18 EDT
Received: from brazos.is.rice.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA27407>; Wed, 28 Jul 1993 16:19:15 -0700
Received: by brazos.is.rice.edu (AA16311); Wed, 28 Jul 93 18:18:56 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Manning <bmanning at is.rice.edu>
Message-Id: <9307282318.AA16311 at brazos.is.rice.edu>
Subject: Re: Last Call for TUBA stuff
To: Ned Freed <NED at innosoft.com>
Date: Wed, 28 Jul 1993 18:18:56 -0500 (CDT)
Cc: ietf at isi.edu
In-Reply-To: <01H12TQRCO20984NNW at INNOSOFT.COM> from "Ned Freed" at Jul 28, 93 01:51:17 pm
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 714
There was a point made around the afternoon marshmallows that it might be
best to pull TUBA from the IP:ng shortlist and treat it as just another
stack in the multi-protocol world. If it had to be positioned anywhere,
it might be considered as something between CIDR and NAT, until we can
really figure out what we want to do... :-) -IF- this document is considered
in this context, would there still be any objections to its advancement?
(Not that I have any pull one way or the other about what gets on the short
list you understand)
--
Regards,
Bill Manning bmanning at rice.edu PO Box 1892
713-285-5415 713-527-6099 Houston, Texas
R.U. (o-kome) 77251-1892
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15033;
28 Jul 93 19:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15026;
28 Jul 93 19:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04744;
28 Jul 93 19:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15014;
28 Jul 93 19:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14975;
28 Jul 93 19:51 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa04684; 28 Jul 93 19:51 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA23915; Wed, 28 Jul 93 16:52:13 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA16725; Wed, 28 Jul 93 16:52:06 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9307282352.AA16725 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: bound at zk3.dec.com
Date: Wed, 28 Jul 93 16:51:59 PDT
Cc: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
In-Reply-To: <9307282317.AA03746 at xirtlu.zk3.dec.com>; from "bound at zk3.dec.com" at Jul 28, 93 7:17 pm
Mailer: Elm [revision: 64.9]
> The issue is that TUBA and CLNP as it is implemented today are not the
> same beast or architecural structure.. Othewise there would be no
> need for all the TUBA documents that exist today to support it as an
> IPng. TUBA would just reference pointers to ISO documents or make them
> Drafts or Informational RFC, whatever, etc...(though this will take
> place per TUBA WG mtg to some degree). Because you have CLNP
> products does not mean you have a TUBA implementation or prototype or
> demo (all being somewhat different in scope and mirrors).
Because there are CLNP routers on the Internet which have not had to
change their code is in fact why we now have a TUBA network in place.
What sits above the CLNP is not a concern of CLNP. The applications
have had to change to use bigger addresses so that they can be used
on top of CLNP. But CLNP code does not need to change to support the
applications. The applications would have needed to change to use larger
addresses regardless of what larger address network layer ended up
underneath. Having the CLNP products has allowed for the ease of testing
the prototypes making use of the existing network. The TUBA documents
have not defined a different CLNP. They just define how the existing one
is being used. The prototypes are being prototyped on top of CLNP and
do not replace CLNP with some other variant. It is not CLNP that is
being protyped. That has been with us for years and years already.
Eva
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15182;
28 Jul 93 20:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15175;
28 Jul 93 20:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05306;
28 Jul 93 20:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15163;
28 Jul 93 20:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15140;
28 Jul 93 20:06 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa05183; 28 Jul 93 20:06 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA24347; Wed, 28 Jul 93 17:06:49 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA17501; Wed, 28 Jul 93 17:06:45 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9307290006.AA17501 at hpindda.cup.hp.com>
Subject: re: Last Call for TUBA...
To: craig at aland.bbn.com
Date: Wed, 28 Jul 93 17:06:41 PDT
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9307282059.AA13765 at aland.bbn.com>; from "Craig Partridge" at Jul 28, 93 1:59 pm
Mailer: Elm [revision: 64.9]
>
> My sense of today's public discussion is that few people think it would
> be a travesty to make TUBA a Proposed Standard, once a clear plan is in
> place and has been explained both to the IETF and the larger community
> of users and media for handling the IP:tng issues. But a lot of people
> (myself included) feel moving a protocol document ahead when we don't know
> why and how we're doing it, is premature.
I think there are enough folks who have already expressed why: because they
need the specific capability of running TCP and UDP over CLNP and want to
be able to reference a standard to implement against. I still agree with
the folks who see this as being independent of which IPng is decided. These
are standards which have been written for the use of the existing CLNP
network by people who wish to use this network to deploy TCP and UDP
products. The IPng issues should be kept independent of the requirements
of a community of Internet users which need to have access to these standards.
Meeting the needs of these users should not depend on the implementation
plan for IPng. If one just explains this to the press as a set of
standards to be used on the EXISTING CLNP portion of the Internet, I don't
see that people are going to start leaping to other conclusions.
Eva
>
> Craig
>
> E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15503;
28 Jul 93 20:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15496;
28 Jul 93 20:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06338;
28 Jul 93 20:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15484;
28 Jul 93 20:43 EDT
Received: from moon.src.honeywell.com by IETF.CNRI.Reston.VA.US id aa15455;
28 Jul 93 20:41 EDT
Return-Path: <iacovou at src.honeywell.com>
Received: from smaug.src.honeywell.com by src.honeywell.com (4.0/smail2.6.3/SRCv0.25);
Wed, 28 Jul 93 19:41:44 CDT id AA17150 for ietf at ietf.cnri.reston.va.us at ietf.cnri.reston.va.us
Posted-Date: Wed, 28 Jul 1993 19:41:42 -0500 (CDT)
Received: by smaug.src.honeywell.com (4.0/SMI-3.2)
id AA14140; Wed, 28 Jul 93 19:41:43 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Danny Iacovou <iacovou at src.honeywell.com>
Message-Id: <9307290041.AA14140 at smaug.src.honeywell.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA - CLNP in HEPnet.
To: Bob Stewart <rlstewart at eng.xyplex.com>
Date: Wed, 28 Jul 1993 19:41:42 -0500 (CDT)
Cc: ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <9307290132.AA29436 at xap.xyplex.com> from "Bob Stewart" at Jul 28, 93 08:32:57 pm
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 567
Bob Stewart writes:
>
> >Ok, that's all, folks! (Bugs Bunny).
>
> Can we attribute credibility to anyone who can't tell the difference betwen
> Bugs Bunny and Porky Pig?
>
> Thufferin' thuccotash! (Sylvester)
>
In light of the newsgroup "alt.humor.best-of-usenet" this message
should be saved until the creation of the mailing list "ietf-humor-best-of".
--------------------------------------------------------------------------------
Neophytos Iacovou
Honeywell Systems & Research Center iacovou at src.honeywell.com
Minneapolis, Mn, 55418
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15573;
28 Jul 93 20:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15566;
28 Jul 93 20:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06512;
28 Jul 93 20:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15543;
28 Jul 93 20:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15520;
28 Jul 93 20:48 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa06491;
28 Jul 93 20:48 EDT
Received: by inet-gw-1.pa.dec.com; id AA09163; Wed, 28 Jul 93 17:48:51 -0700
Received: by xirtlu.zk3.dec.com; id AA05049; Wed, 28 Jul 1993 20:48:48 -0400
Message-Id: <9307290048.AA05049 at xirtlu.zk3.dec.com>
To: Eva Kuiper <eva at hpindda.cup.hp.com>
Cc: bound at zk3.dec.com, henryc at oar.net, desjardi at boa.gsfc.nasa.gov,
ietf at CNRI.Reston.VA.US, tuba at lanl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Wed, 28 Jul 93 16:51:59 PDT."
<9307282352.AA16725 at hpindda.cup.hp.com>
Date: Wed, 28 Jul 93 20:48:48 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bound at zk3.dec.com
X-Mts: smtp
> The issue is that TUBA and CLNP as it is implemented today are not the
> same beast or architecural structure.. Othewise there would be no
> need for all the TUBA documents that exist today to support it as an
> IPng. TUBA would just reference pointers to ISO documents or make them
> Drafts or Informational RFC, whatever, etc...(though this will take
> place per TUBA WG mtg to some degree). Because you have CLNP
> products does not mean you have a TUBA implementation or prototype or
> demo (all being somewhat different in scope and mirrors).
>>Because there are CLNP routers on the Internet which have not had to
>>change their code is in fact why we now have a TUBA network in place.
>>What sits above the CLNP is not a concern of CLNP. The applications
>>have had to change to use bigger addresses so that they can be used
>>on top of CLNP. But CLNP code does not need to change to support the
>>applications. The applications would have needed to change to use larger
>>addresses regardless of what larger address network layer ended up
>>underneath. Having the CLNP products has allowed for the ease of testing
>>the prototypes making use of the existing network. The TUBA documents
>>have not defined a different CLNP. They just define how the existing one
>>is being used. The prototypes are being prototyped on top of CLNP and
>>do not replace CLNP with some other variant. It is not CLNP that is
>>being protyped. That has been with us for years and years already.
TUBA is or will become a complete set of specifications to transition
IPv4 to IPng. If all there is to it is CLNP then TUBA is done and
should just go right for Draft Standard with the IESG. Yes the CLNP
network provides the vehicle for the purpose you stated, but that does
not mean that the products that permit that routing are TUBA prototypes,
(they could be), but rather products that have implemented CLNP, which is
the network layer for the TUBA proposal. I doubt I could boot the diskless
node down from my office on the East Coast, or use TCPDUMP to see how the
sequence # for TCP evolved for the application running on a section of the
network stated above, or many other TCP/IP infrastructures people use on a
daily basis for networking. I am also sitting here now looking at a copy of
the recent CLNP for TUBA draft and clearly the variations in the
structure associations will cause kernel changes to many TCP/IP code
paths that use IPv4 (as all IPngs will). I realize a different CLNP is not
being used. That would change everything if we needed new fields in TUBA for
IPng that are not defined at present in CLNP. And I am not sure that infact
is not the case, but that will take more analysis and a better understanding
of where IPng must provide support for future technology. So I still maintain
that TUBA as an IPng will not be able to maintain the same Architectural
implementation that exists on the present products using CLNP from a total
systems software perspective to be a TUBA system. The network layer protocol
may infact stay the same in TUBA. But after that it really has not been
discussed, in any Internet Drafts or RFCs I have seen, which is the formal
process I use to understand any IPngs set of technical proposals.
I am going off-line after this one but will read the mail. I think
enough discussion from my perspective has taken place per the issue of
going to a proposed standard. I will let the processes decide and
see the decision. Maybe we have touched on some ideas that need
further discussion in the TUBA WG (maybe not) mailing list only. I am out
of this one folks. Good discussion and worthwhile on my end, I learned
some stuff.
/jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15968;
28 Jul 93 21:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15961;
28 Jul 93 21:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08550;
28 Jul 93 21:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15949;
28 Jul 93 21:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15922;
28 Jul 93 21:54 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa08511;
28 Jul 93 21:54 EDT
Received: from relay.hp.com by venera.isi.edu (5.65c/5.61+local-12)
id <AA01545>; Wed, 28 Jul 1993 18:54:58 -0700
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA28037; Wed, 28 Jul 93 18:54:56 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA20933; Wed, 28 Jul 93 18:54:52 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9307290154.AA20933 at hpindda.cup.hp.com>
Subject: Re: Last Call for TUBA stuff
To: bmanning at is.rice.edu
Date: Wed, 28 Jul 93 18:54:51 PDT
Cc: NED at innosoft.com, ietf at isi.edu
In-Reply-To: <9307282318.AA16311 at brazos.is.rice.edu>; from "William Manning" at Jul 28, 93 6:18 pm
Mailer: Elm [revision: 64.9]
If Craig is right, that there will be only at the most a few month delay,
it would be best to put a schedule together with a target date by which
time the necessary politically correct statements to feed to the press
will have been created. TUBA should be then allowed to proceed to Proposed
Standard when that date arrives. The only thing that would really happen
would be more prototypes and more experience, which, as was pointed out
in an earlier note, is a very desirable condition for a Proposed Standard.
Having seen how the press can alter reality with their own interpretations
over and over again, this should really be done rather quickly. Otherwise
we might start seeing articles about the standard that was not allowed
to proceed :-)
Eva
>
>
> There was a point made around the afternoon marshmallows that it might be
> best to pull TUBA from the IP:ng shortlist and treat it as just another
> stack in the multi-protocol world. If it had to be positioned anywhere,
> it might be considered as something between CIDR and NAT, until we can
> really figure out what we want to do... :-) -IF- this document is considered
> in this context, would there still be any objections to its advancement?
> (Not that I have any pull one way or the other about what gets on the short
> list you understand)
>
> --
> Regards,
> Bill Manning bmanning at rice.edu PO Box 1892
> 713-285-5415 713-527-6099 Houston, Texas
> R.U. (o-kome) 77251-1892
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17068;
28 Jul 93 22:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17064;
28 Jul 93 22:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09295;
28 Jul 93 22:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17037;
28 Jul 93 22:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17030;
28 Jul 93 22:26 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa09290;
28 Jul 93 22:26 EDT
Received: by ginger.lcs.mit.edu
id AA13157; Wed, 28 Jul 93 22:26:19 -0400
Date: Wed, 28 Jul 93 22:26:19 -0400
X-Orig-Sender:iesg-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: <9307290226.AA13157 at ginger.lcs.mit.edu>
To: eva at hpindda.cup.hp.com, ietf at CNRI.Reston.VA.US
Subject: re: Last Call for TUBA...
Cc: craig at aland.bbn.com, iesg at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
> But a lot of people (myself included) feel moving a protocol document
> ahead when we don't know why and how we're doing it, is premature.
I think there are enough folks who have already expressed why ...
If one just explains this to the press as a set of standards to be used on
the EXISTING CLNP portion of the Internet, I don't see that people are
going to start leaping to other conclusions.
I'm not in favor of delaying the document for an indeterminate time, but if
you think that the fine semantic hair you've split is going to hold up with
people who barely understand what a packet is (i.e. the press, other
outsiders, etc), you're in for a shock. The IESG has been through this kind of
thing before, on smaller issues, and it's amazing how wrong people can get
things. Come on, be realistic: Tuba *is* a contender for IPng, and people
*will* draw conclusions.
I don't think it's in your own best interests to make light of what I perceive
to be the legitimate concerns of people that it's going to up the political
temperature unless it is handled *very carefully*. If the temperature does go
to boil, *everyone* is going to suffer, a lot of old scars are going to get
rubbed, and we're all going to waste a lot of time and energy getting pissed
off at each other. Remember Kobe/IPv7?
I agree with Craig's basic point: we need to have though about how to handle
minimizing the politics of this step before we go forward with this (although
I don't think we need to get the ultimate decision process firmed up; that can
wait). I also don't think it has to cause a giant delay, and remember, a
slight delay to figure out how to damp the politics (with the intention of
having the documents go to PS ASAP) will benefit *everyone*, including Tuba
backers.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23214;
29 Jul 93 0:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23206;
29 Jul 93 0:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12132;
29 Jul 93 0:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23194;
29 Jul 93 0:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23169;
29 Jul 93 0:05 EDT
Received: from POSTOFFICE.MAIL.CORNELL.EDU by CNRI.Reston.VA.US id aa12081;
29 Jul 93 0:05 EDT
Received: from [132.236.236.123] (CU-DIALUP-0417.CIT.CORNELL.EDU) by postoffice.mail.cornell.edu with SMTP id AA29663
(5.65c8/IDA-1.4.4 for ietf at cnri.reston.va.us); Thu, 29 Jul 1993 00:05:57 -0400
Message-Id: <199307290405.AA29663 at postoffice.mail.cornell.edu>
Date: Thu, 29 Jul 1993 00:06:34 -0400
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>, 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: Scott Brim <swb1 at cornell.edu>
X-Sender: swb1 at postoffice.mail.cornell.edu
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
Right. We really need to re-examine the possibilities for NAT. We did
before but not exhaustively. NAT *might* play a very important role --
it's certain that people are going to make assumptions about how much they
can depend on it ("Don't worry, we don't have to decide anything until
after we run out of address space, because we can always use NAT").
Therefore we *must* clarify what the possibilities and their limitations
are as much as possible, to help understand how soon we need to make an
IPng decision and to avoid surprises later on. I think this is as
important as any of the other "solutions".
Scott
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00591;
29 Jul 93 3:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00587;
29 Jul 93 3:02 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa01629;
29 Jul 93 3:02 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (5.65/%I%)
id AA19327; Thu, 29 Jul 93 00:58:22 -0600
Received: by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA24741; Thu, 29 Jul 93 00:58:08 MDT
Return-Path: <brian at dxcern.cern.ch>
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA24737; Thu, 29 Jul 93 00:58:07 MDT
Received: from dxmint.cern.ch by mailhost.lanl.gov (5.65/%I%)
id AA19313; Thu, 29 Jul 93 00:58:06 -0600
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA29176; Thu, 29 Jul 1993 08:58:05 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
id AA08167; Thu, 29 Jul 1993 08:58:03 +0200
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brian Carpenter CERN-CN <brian at dxcern.cern.ch>
Message-Id: <9307290658.AA08167 at dxcern.cern.ch>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Date: Thu, 29 Jul 1993 08:58:01 +0200 (MET DST)
Cc: bound at zk3.dec.com, henryc at oar.net, desjardi at boa.gsfc.nasa.gov,
ietf at CNRI.Reston.VA.US, tuba at lanl.gov
In-Reply-To: <9307290631.AA18973 at mailhost.lanl.gov> from "Jon Crowcroft" at Jul 29, 93 07:27:57 am
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 616
Jon,
...
> a key point is that CLNP is widely deployed in single managed
> organisations, while the Internet consists of an extremely large
> number of looseley affiliaited (and in some cases not affiliated)
> organisations
>
> can CLNP be deployed _across_ these? can TUBA be run between existing
> CLNP regions and such new regions?
>
Anyone who sat in on the joint TUBA/NOOP/RARE-CLNS meeting in
Amsterdam heard a gang of people discussing not WHETHER this can be done,
but HOW to do it better. CLNP is waiting for IDRP just the same as
the IPv4 Internet is waiting for BGP4. It's the same ballgame.
Brian
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00643;
29 Jul 93 3:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00627;
29 Jul 93 3:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01646;
29 Jul 93 3:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00601;
29 Jul 93 3:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00532;
29 Jul 93 2:56 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa01462;
29 Jul 93 2:56 EDT
Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.01392-0 at bells.cs.ucl.ac.uk>; Thu, 29 Jul 1993 07:27:59 +0100
To: bound at zk3.dec.com
cc: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Wed, 28 Jul 93 18:28:29 EDT." <9307282228.AA02290 at xirtlu.zk3.dec.com>
Date: Thu, 29 Jul 93 07:27:57 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Message-ID: <9307290256.aa01462 at CNRI.Reston.VA.US>
>Amsterdam several times it was stated in the audience that TUBA is a
>widely deployed IPng. After the 2cnd or 3rd time Steve Knowles INT Area
>Director stood up and basically stated this is a false statement, and
>not even the TUBA working group would stand up and make this claim at
>the IPdecide BOF. No one stood up.
a key point is that CLNP is widely deployed in single managed
organisations, while the Internet consists of an extremely large
number of looseley affiliaited (and in some cases not affiliated)
organisations
can CLNP be deployed _across_ these? can TUBA be run between existing
CLNP regions and such new regions?
would not a 'pure' new approach fare better?
what of multicast and flow reservations?
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01131;
29 Jul 93 5:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01127;
29 Jul 93 5:29 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa03953;
29 Jul 93 5:29 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (5.65/%I%)
id AA19013; Thu, 29 Jul 93 00:32:16 -0600
Received: by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA24710; Thu, 29 Jul 93 00:31:10 MDT
Return-Path: <J.Crowcroft at cs.ucl.ac.uk>
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA24706; Thu, 29 Jul 93 00:31:08 MDT
Received: from bells.cs.ucl.ac.uk by mailhost.lanl.gov (5.65/%I%)
id AA18973; Thu, 29 Jul 93 00:31:09 -0600
Message-Id: <9307290631.AA18973 at mailhost.lanl.gov>
Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.01392-0 at bells.cs.ucl.ac.uk>; Thu, 29 Jul 1993 07:27:59 +0100
To: bound at zk3.dec.com
Cc: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Wed, 28 Jul 93 18:28:29 EDT." <9307282228.AA02290 at xirtlu.zk3.dec.com>
Date: Thu, 29 Jul 93 07:27:57 +0100
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
>Amsterdam several times it was stated in the audience that TUBA is a
>widely deployed IPng. After the 2cnd or 3rd time Steve Knowles INT Area
>Director stood up and basically stated this is a false statement, and
>not even the TUBA working group would stand up and make this claim at
>the IPdecide BOF. No one stood up.
a key point is that CLNP is widely deployed in single managed
organisations, while the Internet consists of an extremely large
number of looseley affiliaited (and in some cases not affiliated)
organisations
can CLNP be deployed _across_ these? can TUBA be run between existing
CLNP regions and such new regions?
would not a 'pure' new approach fare better?
what of multicast and flow reservations?
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07643;
29 Jul 93 12:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07636;
29 Jul 93 12:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16710;
29 Jul 93 12:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07623;
29 Jul 93 12:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07575;
29 Jul 93 12:27 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa16635;
29 Jul 93 12:27 EDT
Received: by ginger.lcs.mit.edu
id AA16256; Thu, 29 Jul 93 12:28:26 -0400
Date: Thu, 29 Jul 93 12:28:26 -0400
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: <9307291628.AA16256 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US, swb1 at cornell.edu
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ddc at ginger.lcs.mit.edu, jnc at ginger.lcs.mit.edu
We really need to re-examine the possibilities for NAT. We did before
but not exhaustively. ... it's certain that people are going to make
assumptions about how much they can depend on it ... Therefore we *must*
clarify what the possibilities and their limitations are as much as
possible ... I think this is as important as any of the other "solutions".
Yes, the IESG should take this as a major action item.
NAT *might* play a very important role
I've heard an argument, that I take with great seriousness, that economic
forces will make NAT almost inevitable. It goes as follows:
There will be some hosts which don't get converted to IPng (this is almost
inevitable), and there will be enough of them to make it economically
worthwhile to develop NAT technology to support them. Once that technology is
available off the shelf, people will quickly realize that it is easier,
cheaper, and *less diverting of attention*, to buy and deploy a NAT box,
than convert all one's hosts to IPng *and get no extra functionality*.
We shouldn't underestimate the power of convenience. I did once (not realizing
that bridges would be popular because, limited a solution as they are, they
are *trivial* to install), and it's a mistake I'm not soon going to forget.
(One of 17 things that helped Cisco trash Proteon... :-)
In today's competitive environment, where every ounce of energy must be
targeted on delivering against the competition, the diversion of resources and
energy to a IPng conversion (along with potential instability in a key
organizational resource, the information mesh) is just not going to fly if
there's an alternate solution available, and there will be.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08314;
29 Jul 93 13:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08300;
29 Jul 93 13:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18644;
29 Jul 93 13:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08266;
29 Jul 93 13:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08202;
29 Jul 93 13:27 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa18546;
29 Jul 93 13:27 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA20702>; Thu, 29 Jul 1993 10:28:21 -0700
Date: Thu, 29 Jul 1993 10:28:26 -0700
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, 29 Jul 1993 10:28:26 -0700
Message-Id: <199307291728.AA23261 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA23261>; Thu, 29 Jul 1993 10:28:26 -0700
To: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Friends,
I have a question about TUBA. Running TCP and UDP over (unmodified)
CLNP seems like a nice thing, I guess, but where is the multicasting?
I regard multicasting as a fundamental requirement for the Internet.
Those who disagree should consider the impact of audio- and video-
casting IETF over the Internet without multicasting. Suppose TUBA/CLNP
[unmodified] were adopted as IPng. Isn't that a recipe for complete
bandwidth catastrophe on the Internet.
Is it appropriate to make TUBA a Proposed Standard before they develop,
test, and experimentally deploy CLNP-multicasting?
Bob Braden
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08413;
29 Jul 93 13:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08401;
29 Jul 93 13:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18746;
29 Jul 93 13:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08381;
29 Jul 93 13:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08323;
29 Jul 93 13:30 EDT
Received: from eagle.nersc.gov by CNRI.Reston.VA.US id aa18677;
29 Jul 93 13:30 EDT
Date: Thu, 29 Jul 1993 10:31:14 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Hain <ALH at eagle.es.net>
Message-Id: <930729103114.439 at EAGLE.ES.NET>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: ietf at CNRI.Reston.VA.US
X-Vmsmail-To: SMTP%"ietf at cnri.reston.va.us"
A simple question:
Would the same stalling tactics be used if the proposal were to advance SIP/PIP?
The IESG has had plenty of time to see this coming and prepare their position
for the press.
Once a draft meets the established requirements it should be advanced. Stalling
because there might be political fallout is as bad as some of the forced-fits
of the past. The longer we take to define a standard, the longer it will be
until vendors provide the solution to the end of the IPv4 road.
Tony
P.S. Noel- I was not attacking IPv4, just trying to point out to those who
are comforatable where they are that they should look back before
they are run down from behind.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09800;
29 Jul 93 14:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09793;
29 Jul 93 14:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20600;
29 Jul 93 14:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09781;
29 Jul 93 14:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09707;
29 Jul 93 14:30 EDT
Received: from hsdndev.harvard.edu by CNRI.Reston.VA.US id aa20543;
29 Jul 93 14:30 EDT
Date: Thu, 29 Jul 93 14:30:31 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Scott Bradner <sob at hsdndev.harvard.edu>
Message-Id: <9307291830.AA06068 at hsdndev.harvard.edu>
To: ALH at eagle.es.net, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Tony,
At this instant the ball is in my court. As the ops AD I need to
give some sort of assessment of the operational impact of these proposals.
I hope to have this completed in a week or so. As soon as this is done
the IESG should be able to move right along on this.
Scott
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10295;
29 Jul 93 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10288;
29 Jul 93 14:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21262;
29 Jul 93 14:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10276;
29 Jul 93 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10215;
29 Jul 93 14:47 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa21174;
29 Jul 93 14:47 EDT
Received: by ginger.lcs.mit.edu
id AA20292; Thu, 29 Jul 93 14:48:27 -0400
Date: Thu, 29 Jul 93 14:48:27 -0400
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: <9307291848.AA20292 at ginger.lcs.mit.edu>
To: braden at isi.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
I have a question about TUBA. ... but where is the multicasting? I regard
multicasting as a fundamental requirement for the Internet.
Good point, but...
Is it appropriate to make TUBA a Proposed Standard before they develop,
test, and experimentally deploy CLNP-multicasting?
Sigh. I really wish the topic would just Go Away somehow....
We've advanced other major protocols to PS, and had significant
changes from that point. I seem to recall that OSPF was a PS before Version 2
came out (RFC-1245 distinctly states that it's OSPF Version 2 which is going
to DS); stub areas were added, packet formats changed, and the protocol was
changed in a *incompatible* way. SGMP went through even bigger upheavals on
the way to becoming SNMP (and now whatever its new name is).
Perhaps we didn't advance a major protocol to PS, *knowing* changes
were going to have to come, but that's a pretty thin rhetorical hair to split.
You could argue that IP was adopted without multi-cast, too! We've managed to
add it without any change to the packet format, etc, and there's no reason to
think adding it to CLNP would be any more disruptive.
If we really need a new internet layer, Tuba is in fact a legitimate
contender (technically, I mean, not politically) as a choice for a replacement
to IPv4. It's not my first choice, but it's not my last either. As a
legitimate option, it deserves to be treated like any other protocol in the
IETF. Maybe potential IP replacements get a little more care, but the IETF
rules have always been that we try different ways of doing things, *try and
make doing so easy*, and decide based on experience.
It's an unfortunate fact of life that holding up Tuba, for any but the
most rigorously defendable reasons, is going to smack of an excuse to slow it
down. Do I like the fact that the whole thing is politicized, and you can't do
what's right without spending a ton of time wondering if it will look slimy?
No, but I might as well complain about the fact that Athens lost the
Peleponnesian War; you can't change history. There's a lot of bad history,
BOTH SIDES WERE GUILTY, and that's the prism everything gets viewed through
now. You can't avoid it, so you have to figure out how to live with it.
Do I *like* Tuba? No. I am particularly driven to raving, screaming,
pounding, head-banging distraction by the unwillingness of the Tuba community
to make any upward compatible restriction to Tuba (i.e. all old code would
continue to work)! If this body decides to pick Tuba (as is) for IPng, stand
by for some classic Noelgrams.
Do I think there are good reasons to delay the protocol going to PS?
No, especially given the political sensitivity.
At the same time, the Tuba community has to be sensitive to the fact
that the ISO community (maybe diferent individuals from those now involved, I
know, but not everyone knows exactly who did what, when) does not have an
innocent history; manipulation of various processes in a political way (e.g.
GOSIP, CMOT) has left many people with painful scars, so you all have to be
sensitive to people who get nervous that it is happening *again*. It's really
in your own best interests to do so, yes?
My apologies to you all for rambling on at great length on this topic,
and using so much IETF list bandwidth, but I am *so tired* of the way we keep
having these pointless, stupid, wasteful, passages of suspicion and hostility
between the "TCP camp" and "ISO camp".
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11558;
29 Jul 93 16:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11551;
29 Jul 93 16:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23400;
29 Jul 93 16:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11539;
29 Jul 93 16:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11488;
29 Jul 93 15:58 EDT
Received: from POSTOFFICE.MAIL.CORNELL.EDU by CNRI.Reston.VA.US id aa23293;
29 Jul 93 15:58 EDT
Received: from [132.236.195.71] by postoffice.mail.cornell.edu with SMTP id AA02599
(5.65c8/IDA-1.4.4 for ietf at cnri.reston.va.us); Thu, 29 Jul 1993 15:59:00 -0400
Message-Id: <199307291959.AA02599 at postoffice.mail.cornell.edu>
Date: Thu, 29 Jul 1993 15:59:34 -0400
To: braden at isi.edu, 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: Scott Brim <swb1 at cornell.edu>
X-Sender: swb1 at postoffice.mail.cornell.edu
Subject: Re: Last Call: Use of ISO CLNP in TUBA
>I have a question about TUBA. Running TCP and UDP over (unmodified)
>CLNP seems like a nice thing, I guess, but where is the multicasting?
I just listen in on the X3S3.3 mailing list, but here is what I have
gathered. If Someone Who Really Knows answers your mail in the meantime,
then perhaps my mail will be useful in showing what an outsider is being
shown.
Multicast addresses are defined (there were some late complaints recently
but they are being dealt with). Multicast packet formats are defined, in
the USA at least. These are slowly wending their way through the ISO
hierarchy. Multicast transport is being played with in some very
interesting and enriching ways, while they think about what they *really*
want in transport. Since all we really use these days for multicast in IP
is straight UDP, I'm really grateful they are doing these explorations.
I'm getting some fresh ideas from lurking on the list.
As for multicast routing, I didn't get to go to the last IETF so I didn't
get to attend a BOF on the subject and I don't know what the latest is. As
far as I know various ideas have been toyed with, including a straight
translation of mrouted to its CLNP equivalent and of MOSPF to MISIS. Any
of these could be done if necessary. I consider the whole area of
multicast routing to be up in the air right now, regardless of protocol.
I don't know anything about what would be required in forwarding. Since
there are more options (they tried to build on what has been learned in
IP), a full implementation would take more time. I suspect one could clone
Dr. Deering's code; I don't know how hard it would be.
So, my personal view is that if we wanted ISO multicast in a hurry we could
clone what we have for IP. As always, copying someone's work takes a lot
less time than doing it the first time. In the meantime work is being done
to improve on IP. They have all sorts of options, e.g. different kinds of
scope, which may be unnecessary (but they don't know yet). At least it's
nice to have the flexibility to put them in. Bottom line: this particular
issue doesn't worry me at all.
Scott
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11753;
29 Jul 93 16:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11745;
29 Jul 93 16:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23693;
29 Jul 93 16:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11728;
29 Jul 93 16:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11657;
29 Jul 93 16:07 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa23605;
29 Jul 93 16:07 EDT
Received: by large.cisco.com id AA02403
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Thu, 29 Jul 1993 13:07:33 -0700
Date: Thu, 29 Jul 1993 13:07:33 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199307292007.AA02403 at large.cisco.com>
To: braden at isi.edu
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: braden at isi.edu's message of Thu, 29 Jul 1993 10:28:26 -0700 <199307291728.AA23261 at can.isi.edu>
Subject: Last Call: Use of ISO CLNP in TUBA
Work is in progress on multicast extensions to CLNP and to first-hop routing
(ES-IS). The basics have been defined, and are in the process of being
implemented.
It is very likely that the IETF work on multicast routing protocols
will be adopted essentially as-is.
Date: Thu, 29 Jul 1993 10:28:26 -0700
Sender: ietf-request at IETF.CNRI.Reston.VA.US
From: braden at isi.edu
Posted-Date: Thu, 29 Jul 1993 10:28:26 -0700
Friends,
I have a question about TUBA. Running TCP and UDP over (unmodified)
CLNP seems like a nice thing, I guess, but where is the multicasting?
I regard multicasting as a fundamental requirement for the Internet.
Those who disagree should consider the impact of audio- and video-
casting IETF over the Internet without multicasting. Suppose TUBA/CLNP
[unmodified] were adopted as IPng. Isn't that a recipe for complete
bandwidth catastrophe on the Internet.
Is it appropriate to make TUBA a Proposed Standard before they develop,
test, and experimentally deploy CLNP-multicasting?
Bob Braden
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11980;
29 Jul 93 16:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11973;
29 Jul 93 16:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23989;
29 Jul 93 16:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11961;
29 Jul 93 16:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11936;
29 Jul 93 16:17 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa23955;
29 Jul 93 16:17 EDT
Received: by large.cisco.com id AA02572
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Thu, 29 Jul 1993 13:17:44 -0700
Date: Thu, 29 Jul 1993 13:17:44 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199307292017.AA02572 at large.cisco.com>
To: jnc at ginger.lcs.mit.edu
Cc: braden at isi.edu, ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
In-Reply-To: Noel Chiappa's message of Thu, 29 Jul 93 14:48:27 -0400 <9307291848.AA20292 at ginger.lcs.mit.edu>
Subject: Last Call: Use of ISO CLNP in TUBA
Do I *like* Tuba? No. I am particularly driven to raving, screaming,
pounding, head-banging distraction by the unwillingness of the Tuba community
to make any upward compatible restriction to Tuba (i.e. all old code would
continue to work)!
I don't think that this is a fair characterization. There was considerable
interest (I don't believe in the concept of "consensus") at the last IETF
meeting in working on upward-compatible extensions to the protocols, and in
general I think it's safe to say that what we will end up with will be
considerably more than the 1988 CLNP spec. As far as restrictions go
(you've mentioned the plethora of addressing plans, for example), I think
it is possible to define these restrictions in such a way that they provide
the desired result while not necessarily precluding interoperability (though
perhaps less efficiently).
--Dave
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12189;
29 Jul 93 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24415;
29 Jul 93 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12167;
29 Jul 93 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12096;
29 Jul 93 16:26 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa24289;
29 Jul 93 16:26 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA03720>; Thu, 29 Jul 1993 13:26:43 -0700
Message-Id: <199307292026.AA03720 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1488 on X.500 Syntax Encoding
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Thu, 29 Jul 93 13:26:40 PDT
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 1488:
Title: The X.500 String Representation of Standard
Attribute Syntaxes
Author: T. Howes, S. Kille, W. Yeong, & C. Robbins
Mailbox: tim at umich.edu, S.Kille at isode.com,
yeongw at psilink.com
Pages: 11
Characters: 17,185
Updates/Obsoletes: none
The Lightweight Directory Access Protocol (LDAP) requires that the
contents of AttributeValue fields in protocol elements be octet
strings. This document defines the requirements that must be
satisfied by encoding rules used to render Directory attribute
syntaxes into a form suitable for use in the LDAP, then goes on to
define the encoding rules for the standard set of attribute syntaxes.
This RFC is the product of the OSI Directory Services Working Group of
the IETF.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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 NIC.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 1111, "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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1488.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1488.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12191;
29 Jul 93 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24416;
29 Jul 93 16:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12163;
29 Jul 93 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12059;
29 Jul 93 16:25 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa24249;
29 Jul 93 16:25 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA03708>; Thu, 29 Jul 1993 13:25:44 -0700
Message-Id: <199307292025.AA03708 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1487 on X.500 LDAP
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Thu, 29 Jul 93 13:25:41 PDT
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 1487:
Title: X.500 Lightweight Directory Access Protocol
Author: W. Yeong, T. Howes, & S. Kille
Mailbox: yeongw at psilink.com, tim at umich.edu,
S.Kille at isode.com
Pages: 21
Characters: 44,950
Updates/Obsoletes: none
The protocol described in this document is designed to provide access
to the Directory while not incurring the resource requirements of the
Directory Access Protocol (DAP). This protocol is specifically
targeted at simple management applications and browser applications
that provide simple read/write interactive access to the Directory,
and is intended to be a complement to the DAP itself. This RFC is the
product of the OSI Directory Services Working Group of the IETF.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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 NIC.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 1111, "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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1487.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1487.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12532;
29 Jul 93 16:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12525;
29 Jul 93 16:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25449;
29 Jul 93 16:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12513;
29 Jul 93 16:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12490;
29 Jul 93 16:55 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25386;
29 Jul 93 16:55 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA28079>; Thu, 29 Jul 1993 13:55:58 -0700
Date: Thu, 29 Jul 1993 13:56:02 -0700
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, 29 Jul 1993 13:56:02 -0700
Message-Id: <199307292056.AA23352 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA23352>; Thu, 29 Jul 1993 13:56:02 -0700
To: braden at isi.edu, ietf at CNRI.Reston.VA.US, swb1 at cornell.edu
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Scott,
Thanks for your informative response.
*>
*> Multicast addresses are defined (there were some late complaints recently
*> but they are being dealt with). Multicast packet formats are defined, in
*> the USA at least. These are slowly wending their way through the ISO
*> hierarchy.
(I notef that last sentence, with some apprension, but that's another topic...)
I consider the whole area of
*> multicast routing to be up in the air right now, regardless of protocol.
*>
That is certainly true.
*>
*> So, my personal view is that if we wanted ISO multicast in a hurry we could
*> clone what we have for IP. As always, copying someone's work takes a lot
*> less time than doing it the first time. In the meantime work is being done
*> to improve on IP. They have all sorts of options, e.g. different kinds of
*> scope, which may be unnecessary (but they don't know yet). At least it's
*> nice to have the flexibility to put them in. Bottom line: this particular
*> issue doesn't worry me at all.
*>
If there is no hurry, why is there a fuss about making TUBA/CLNP a
Proposed Standard instantly?
"What, me worry?" This issue does worry me, in the context of the
present discussion. I don't like retrograde steps, no matter how
politically useful to somebody.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12639;
29 Jul 93 17:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12632;
29 Jul 93 17:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25567;
29 Jul 93 17:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12608;
29 Jul 93 17:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12556;
29 Jul 93 16:58 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25494;
29 Jul 93 16:58 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA28180>; Thu, 29 Jul 1993 13:59:31 -0700
Date: Thu, 29 Jul 1993 13:59:36 -0700
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, 29 Jul 1993 13:59:36 -0700
Message-Id: <199307292059.AA23356 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA23356>; Thu, 29 Jul 1993 13:59:36 -0700
To: ietf at CNRI.Reston.VA.US
Subject: Another query
Friends (and others),
I am wondering if someone could tell me the progress in supporting
mobility over CLNP. Is it progressing more-or-less in phase with the
mobility development in IPv4? If not, what is the status?
Thanks,
Bob Braden
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12808;
29 Jul 93 17:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12800;
29 Jul 93 17:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25689;
29 Jul 93 17:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12786;
29 Jul 93 17:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12720;
29 Jul 93 17:05 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25615;
29 Jul 93 17:05 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA28417>; Thu, 29 Jul 1993 14:05:35 -0700
Date: Thu, 29 Jul 1993 14:05:40 -0700
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, 29 Jul 1993 14:05:40 -0700
Message-Id: <199307292105.AA23363 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA23363>; Thu, 29 Jul 1993 14:05:40 -0700
To: braden at isi.edu, ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
Subject: Re: Last Call: Use of ISO CLNP in TUBA
*>
*> We've advanced other major protocols to PS, and had significant
*> changes from that point. I seem to recall that OSPF was a PS before Version 2
*> came out (RFC-1245 distinctly states that it's OSPF Version 2 which is going
*> to DS); stub areas were added, packet formats changed, and the protocol was
*> changed in a *incompatible* way. SGMP went through even bigger upheavals on
*> the way to becoming SNMP (and now whatever its new name is).
*> Perhaps we didn't advance a major protocol to PS, *knowing* changes
*> were going to have to come, but that's a pretty thin rhetorical hair to split.
Noel,
I am well aware of all the history you cite, but I don't think it is
relevant.
It has taken a tough slog to get to the point where were are today in
IP multicasting. We didn't have the forcing applications before, now
we do. I would like the Next Step to start at the current level, not
move us back 2 years, because that will spell bandwidth catastrophe.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13479;
29 Jul 93 17:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13472;
29 Jul 93 17:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26707;
29 Jul 93 17:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13460;
29 Jul 93 17:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13438;
29 Jul 93 17:46 EDT
Received: from SIGURD.INNOSOFT.COM by CNRI.Reston.VA.US id aa26667;
29 Jul 93 17:46 EDT
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234)
id <01H1499SS9DS8ZECNY at SIGURD.INNOSOFT.COM>; Thu, 29 Jul 1993 14:47:07 PDT
Date: Thu, 29 Jul 1993 14:36:14 -0700 (PDT)
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 sigurd.innosoft.com>
Subject: RE: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message dated "Thu, 29 Jul 1993 10:31:14 -0700 (PDT)"
<930729103114.439 at EAGLE.ES.NET>
To: Tony Hain <ALH at eagle.es.net>
Cc: ietf at CNRI.Reston.VA.US
Message-id: <01H149WBP7K48ZECNY at SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
> Would the same stalling tactics be used if the proposal were to advance
> SIP/PIP?
Abso-damn-lutely. I am just as opposed to seeing SIP, PIP, or TP/IX documents
issued as proposed standards as I am to seeing TUBA documents treated this way.
> The IESG has had plenty of time to see this coming and prepare their position
> for the press.
Time is not the issue. The fact of the matter is that the press shows no signs
whatsoever of being prepared, and I for one don't think the preparation
necessary to handle such an advancement is at all obvious.
> Once a draft meets the established requirements it should be advanced. Stalling
> because there might be political fallout is as bad as some of the forced-fits
> of the past. The longer we take to define a standard, the longer it will be
> until vendors provide the solution to the end of the IPv4 road.
I have no problem whatsoever with advancing these documents. I have a big
problem with advancing them onto the standards track at this time. There are
plenty of options other than standards-track advancement available, and I have
yet to see any rationale for not using one of these alternatives.
I also disagree with your assessment that political consequences are irrelevant
simply because they're political. Like most technical people I find plenty of
time to moan and groan about the political side of the standards process.
However, just because I don't like it and you don't like it doesn't make it
irrelevant. It is *very* relevant: there are any number of ways how the
political consequences from such a move can lead directly to serious technical
problems down the road.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14221;
29 Jul 93 18:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14214;
29 Jul 93 18:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28208;
29 Jul 93 18:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14202;
29 Jul 93 18:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14178;
29 Jul 93 18:34 EDT
Received: from wizard.gsfc.nasa.gov by CNRI.Reston.VA.US id aa28157;
29 Jul 93 18:34 EDT
Received: by wizard.gsfc.nasa.gov (5.65/1.35)
id AA16658; Thu, 29 Jul 93 18:34:29 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Fink <bill at wizard.gsfc.nasa.gov>
Message-Id: <9307292234.AA16658 at wizard.gsfc.nasa.gov>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Date: Thu, 29 Jul 1993 18:34:28 -0400 (EDT)
Cc: braden at isi.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: <9307291848.AA20292 at ginger.lcs.mit.edu> from "Noel Chiappa" at Jul 29, 93 02:48:27 pm
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2907
> Date: Thu, 29 Jul 93 14:48:27 -0400
> From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
>
> We've advanced other major protocols to PS, and had significant
> changes from that point. I seem to recall that OSPF was a PS before Version 2
> came out (RFC-1245 distinctly states that it's OSPF Version 2 which is going
> to DS); stub areas were added, packet formats changed, and the protocol was
> changed in a *incompatible* way. SGMP went through even bigger upheavals on
> the way to becoming SNMP (and now whatever its new name is).
> Perhaps we didn't advance a major protocol to PS, *knowing* changes
> were going to have to come, but that's a pretty thin rhetorical hair to split.
> You could argue that IP was adopted without multi-cast, too! We've managed to
> add it without any change to the packet format, etc, and there's no reason to
> think adding it to CLNP would be any more disruptive.
I think there is a significant difference in the TUBA case, namely the
issue of change control. If it is determined that there is a need to
change the CLNP spec to meet some new IP requirement, there is no
guarantee that I have seen that this will be doable in the time frames
which the IETF is accustomed to, if at all. And if the professed
benefits of a single stack based upon CLNP are to be realized, it
will be necessary for there always to be only one flavor of CLNP which
would be utilized by both TCP and OSI transports and applications.
Another key problem I see with TUBA/CLNP is that it is way behind the
development curve in several key areas such as multicasting and
interdomain routing. Although interdomain IP routing still needs
much more work, it is still far better than the static routing required
in all vendors' routers that I am familiar with. I am not willing to
take a giant step backward in capabilities during the transition to a
new IP. I guess you could argue that CLNP will catch up in parallel
with the IPng development effort, but the problem is that the IP world
won't be in stasis during this period. In other words, CLNP is
admittedly continually improving but IP is improving at an even
faster rate over the same period. Thus, I favor approaches that
are as close as possible to existing IP practices, such as SIP.
Having said all that, I do believe that it is a fact that the IP Internet
and CLNP Internet will continue to coexist for the foreseeable future.
Thus, the TUBA group has a legitimate right to publish standards for
operating TCP over CLNP networks, regardless of the level of use. I
agree with the suggestion of having the IAB/IESG issue an appropriate
statement that the TUBA spec is only proposing standards for the use
of TCP over existing CLNP networks and does not confer upon it or imply
any special status related to its candidacy as an IPng contender. Once
this was done, I wouldn't have any problem with TUBA becoming a PS.
-Bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14777;
29 Jul 93 19:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14770;
29 Jul 93 19:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29460;
29 Jul 93 19:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14758;
29 Jul 93 19:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14733;
29 Jul 93 19:17 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa29442;
29 Jul 93 19:17 EDT
Received: by large.cisco.com id AA06265
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Thu, 29 Jul 1993 16:18:18 -0700
Date: Thu, 29 Jul 1993 16:18:18 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199307292318.AA06265 at large.cisco.com>
To: bill at wizard.gsfc.nasa.gov
Cc: jnc at ginger.lcs.mit.edu, braden at isi.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: Bill Fink's message of Thu, 29 Jul 1993 18:34:28 -0400 (EDT) <9307292234.AA16658 at wizard.gsfc.nasa.gov>
Subject: Last Call: Use of ISO CLNP in TUBA
Another key problem I see with TUBA/CLNP is that it is way behind the
development curve in several key areas such as multicasting and
interdomain routing.
The IETF seems poised to adopt the OSI interdomain routing protocol for use
with IP.
Yes, you can't buy products with IDRP yet, but at the joint BGP/IDRP working
group meeting, I counted at least four independent implementations underway,
with more likely to follow.
As has been discussed earlier on this list, multicast is being actively worked
on, and the work being done for IP is being followed carefully. At the risk
of sounding heretical, IP multicast is in its infancy.
I think there is a significant difference in the TUBA case, namely the
issue of change control. If it is determined that there is a need to
change the CLNP spec to meet some new IP requirement, there is no
guarantee that I have seen that this will be doable in the time frames
which the IETF is accustomed to, if at all. And if the professed
benefits of a single stack based upon CLNP are to be realized, it
will be necessary for there always to be only one flavor of CLNP which
would be utilized by both TCP and OSI transports and applications.
The IETF is free to extend the CLNP spec in any way that it wishes, without
having to wait for ISO to do anything. This has been done in the past
(and in fact when it has been done, ISO has picked up the work unchanged).
It's worth noting that virtually all of the people, past and present, who
have worked on CLNP and the OSI routing protocols attend the IETF.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14813;
29 Jul 93 19:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14807;
29 Jul 93 19:27 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa29713;
29 Jul 93 19:27 EDT
Received: by bitsy.MIT.EDU
id AA24856; Thu, 29 Jul 93 16:09:18 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA24849; Thu, 29 Jul 93 16:09:16 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA00489; Thu, 29 Jul 93 16:09:14 EDT
Received: from gza-server.aktis.com by pad-thai.aktis.com (8.4/) with SMTP
id <QAA18485 at pad-thai.aktis.com>; Thu, 29 Jul 1993 16:09:27 -0400
Received: by gza-server.aktis.com (4.1/4.7) id AA07337; Thu, 29 Jul 93 16:09:25 EDT
Message-Id: <9307292009.AA07337 at gza-server.aktis.com>
To: minutes at CNRI.Reston.VA.US, cat-ietf at mit.edu
Cc: linn at gza.com
Subject: Minutes for Amsterdam CAT sessions
Date: Thu, 29 Jul 1993 16:09:24 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at gza.com>
Minutes for CAT meetings at Amsterdam IETF, reported by John Linn and
Sam Sjogren.
The CAT WG met for two sessions at the Amsterdam IETF, discussing (in
about equal proportion) general CAT issues and FTP security integration.
REVIEW OF ACTIVITIES
We reviewed the status of CAT-related documents: GSS-API and GSS-API
C bindings are in the hands of the RFC editor pending advancement to
Proposed Standards, as is the Kerberos V5 protocol document. The
Kerberos V5 GSS-API implementation has not received recent development
effort, and is not currently compliant, but a plan to make volunteer
resources available is being explored.
Chuck McManis discussed CAT-related activities ongoing at Sun. Sun
currently supports Kerberos V4, and plans to migrate to V5. Kerberos
is invoked (using its native interface, rather than GSS-API) from RPC.
Separate work on layering RPC atop GSS-API had been ongoing at Sun,
but has not yet yielded conclusive results. One of the U.S. National
Laboratories had ported beta 2 of Kerberos V5 to Solaris, and Sun is
working with the resultant code base.
CAT TECHNICAL DISCUSSION
Two proposals for incremental changes to the GSS-API documents were
considered: a terminology change in response to a request from X/Open,
renaming the per-message protection primitives from GSS_Sign to
GSS_GetMIC, GSS_Seal to GSS_Wrap, GSS_Verify to GSS_VerifyMIC, and
GSS_Unseal to GSS_Unwrap (to avoid conflict with other usage, without
change to function, preserving (though deprecating use of) existing
names in existing code for backward compatibility) was tentatively
accepted pending E-mail review.
In evaluating the request and considering alternatives, it was
observed that ISO's usage of the term "seal" echoes the notion of
applying a wax seal to a document. It was also observed that the
current Kerberos V5 implementation of GSS_Sign emits a token
containing the entirety of the input message rather than just a
signature.
It was also observed that no GSS-API per-message protection interface
currently exists to provide confidentiality without integrity, and
post-meeting review (GSS-API spec, Sec. 1.2.2) confirmed the related
point that mechanisms indicating the availability of per-message
confidentiality services are also expected to indicate and offer
per-message integrity. No definitive conclusion was reached about the
level of demand for confidentiality without integrity.
A proposal to add GSS_set_default_cred and GSS_lookup_default_cred
routines was rejected for reasons of semantics which were considered
to be environment-specific (though considered as a likely initial
entry in a set of extensions for POSIX and like environments). Much
of the motivation for this feature derives from a desire to control
the set of credentials which will be transferred by inheritance across
the UNIX fork operation. It was observed that it would be difficult
to implement the set_default_cred function within the current Kerberos
V5 code base, and that different implementors could implement the
proposal as defined with conflicting semantics which would not support
application portability. Given an observation that credentials
structures are ephemeral, use of acquire_cred with (non-ephemeral)
principal names as arguments was recommended as an alternative
approach which would survive UNIX forks.
Chuck McManis expressed interest in using set_default_cred as a means
to spawn threads using different mechanisms for different threads, and
saw this as a more critical priority than use of different identities
within a single mechanism; he also expressed a desire that credentials
be "lightweight" structures.
FOLLOW-ON TASKS AND ACTION ITEMS
Follow-on tasks identified were: Kerberos V5 GSS-API mechanism spec
and code enhancement, Kerberos V4 GSS-API implementation, "negotiated"
mechanism definition (a task to which a framework discussion authored
by Bob Blakely and forwarded to the list was considered relevant),
CATS stream-oriented overlay definition, documentation of mechanism
implementor's guidance/agreements, environment-specific specifications
and extensions (e.g., credential inheritance semantics). Individuals
and subset groups were associated with several of these items. Activity
on the "negotiated" mechanism's design was argued as not being critical
at this time; it will assume greater importance once multiple mechanisms
are actively supported.
FTP SECURITY
[This discussion moderated, and section reported, by Sam Sjogren]
REVIEW OF ACTIVITIES
Discussions on the cat-ietf mailing list as well as at the Columbus IETF
meeting in March resulted in changes to the specification for security in
FTP. Steve Lunt revised the FTP Security Internet Draft and submitted it
to the Internet Drafts directory. A list of changes made to the document
was also produced which was sent to the cat-ietf mailing list. Since
Steve was not able to physically attend the group's meeting in Amsterdam,
arrangements were made to allow Steve to participate via speakerphone. The
changes list was the focus of most of the group's discussions.
FTP TECHNICAL DISCUSSION
One of the additions to the FTP Security Draft is a specification using
the GSS-API authentication type. This specification needs to be reviewed
in detail and any problems corrected. John Linn will communicate his
observations to Steve on this.
Although the interaction of the AUTH, PASS, and USER commands have been
clarified somewhat, it was agreed that the various possible cases (including
those involving users for whom passwords (which should be protected) may be
required in addition to other forms of authentication) should be more
rigorously.
The form of Base-64 encoding used by FTP Security has been brought into
line with that used by PEM. One concern is that the length of a Base-64
string is currently unbounded, and that may cause problems for small
machine implementations. This will be addressed in the small machine
discussion on the mailing list.
For the time being, proxy file transfers are deferred. One of the effects
of this is that the requirements for negotiating session keys are eased.
However, the negotiating of session keys with the various possible
mechanisms should still be investigated to make sure that in the future
we won't be precluded from supporting this feature.
It is necessary for a server to indicate to a client, somehow, what
levels of security are supported (e.g., integrity but not encryption).
Although this has been left purely to the particular mechanism, there
is a feeling that the protocol itself should provide some support for
determination of this when mechanisms themselves don't support it. So,
a 402 reply code is defined which indicates to a client that ENC and/or
MIC commands aren't accepted, thereby allowing a client to probe a server
to determine the levels of security it supports. Note that this even
allows a server to force the use of privacy but not allow mere integrity
assurance. This method is authentication mechanism idenpendent.
In the case of a server allowing integrity but not privacy, implementors
are encouraged to warn the user that the level of security that is
available is less than they have requested.
Another potential small-machine issue surfaced in the specification of
buffer size and length for protected file transfers. Although the length
field in the specification has been reduced from 4 bytes to 2 bytes,
thereby reducing the buffer size from 4 gigabytes to 64 kilobytes, even
a 64 KB buffer may prove to be a problem for some small machines. This
issue will be discussed further on the mailing list.
Instead of the commonly used 'rcmd' principal that is usually used with
Kerberized TELNET and R-Utilities, the principal name 'ftp' has been
specified for use with FTP Security. There was a feeling that a number
of sites may wish to avoid the additional overhead of creating another
principal for each machine, so there should be some capability to fallback
to use of the 'rcmd' principal. This would appear to be an issue left to
particular implementations and site policy. Perhaps it should, however,
be mentioned in the Internet Draft that it is recommended that clients
first try the 'ftp' principal and then try the 'rcmd' principal if the
'ftp' principal doesn't exist or the FTP server won't accept the 'ftp'
principal.
Various other small changes were made to the Internet Draft that were
either corrections or clarifications and aren't worth mentioning in
the minutes.
FOLLOW-ON TASKS AND ACTION ITEMS
There will be discussion on the CAT/FTP-WG mailing list regarding
the buffer size issues and how a small-system implementation may
be affected by large buffers or buffers of indefinite size.
Steve will incorporate the changes that arose from the group's
discussions into the Internet Draft and produce a new revision
of the Draft and a list of changes.
The most important thing to do at this stage is to gain more
implementation experience. Sam will solicit implementors through
various email lists and other channels.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14865;
29 Jul 93 19:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14858;
29 Jul 93 19:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29834;
29 Jul 93 19:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14845;
29 Jul 93 19:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14821;
29 Jul 93 19:29 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa29787; 29 Jul 93 19:29 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA07976; Thu, 29 Jul 93 16:29:56 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA20274; Thu, 29 Jul 93 16:29:50 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9307292329.AA20274 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: bill at wizard.gsfc.nasa.gov
Date: Thu, 29 Jul 93 16:29:49 PDT
Cc: jnc at ginger.lcs.mit.edu, braden at isi.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: <9307292234.AA16658 at wizard.gsfc.nasa.gov>; from "Bill Fink" at Jul 29, 93 6:34 pm
Mailer: Elm [revision: 64.9]
>
> I think there is a significant difference in the TUBA case, namely the
> issue of change control. If it is determined that there is a need to
> change the CLNP spec to meet some new IP requirement, there is no
> guarantee that I have seen that this will be doable in the time frames
> which the IETF is accustomed to, if at all. And if the professed
> benefits of a single stack based upon CLNP are to be realized, it
> will be necessary for there always to be only one flavor of CLNP which
> would be utilized by both TCP and OSI transports and applications.
The concept of fast-tracking standards work has been widely accepted
and I don't think that changes would necessarily progress any slower
than needed. Most of the work we are talking of is adding new options.
Adding new options does not really have to disturb what is already
there.
>
> Another key problem I see with TUBA/CLNP is that it is way behind the
> development curve in several key areas such as multicasting and
> interdomain routing. Although interdomain IP routing still needs
> much more work, it is still far better than the static routing required
> in all vendors' routers that I am familiar with. I am not willing to
> take a giant step backward in capabilities during the transition to a
> new IP. I guess you could argue that CLNP will catch up in parallel
> with the IPng development effort, but the problem is that the IP world
> won't be in stasis during this period. In other words, CLNP is
> admittedly continually improving but IP is improving at an even
> faster rate over the same period. Thus, I favor approaches that
> are as close as possible to existing IP practices, such as SIP.
>
Gee, I haven't used static routing in over a year. I use ES-IS. Routers
can use IS-IS. On my system I only tell all packets with a given
prefix to please go talk to that router over there.
I must admit that I am puzzled why folks keep saying that capabilities
are not there which are in fact already there. Since there is also
ongoing development work in IDRP, I would say that the routing
capabilities of a CLNP backbone are pretty far advanced. Saying that
CLNP only does static routing does not match my experiences.
> Having said all that, I do believe that it is a fact that the IP Internet
> and CLNP Internet will continue to coexist for the foreseeable future.
> Thus, the TUBA group has a legitimate right to publish standards for
> operating TCP over CLNP networks, regardless of the level of use. I
> agree with the suggestion of having the IAB/IESG issue an appropriate
> statement that the TUBA spec is only proposing standards for the use
> of TCP over existing CLNP networks and does not confer upon it or imply
> any special status related to its candidacy as an IPng contender. Once
> this was done, I wouldn't have any problem with TUBA becoming a PS.
I concur. It will allow more experience to be developed with the protocol
and provide stable documents to point to. It does not affect its candidacy
as an IPng contender. It will allow a good baseline for future improvements.
Eva
>
> -Bill
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15227;
29 Jul 93 19:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15220;
29 Jul 93 19:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00373;
29 Jul 93 19:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15205;
29 Jul 93 19:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15150;
29 Jul 93 19:51 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa00360;
29 Jul 93 19:51 EDT
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3435;
Thu, 29 Jul 93 19:51:41 EDT
Date: Thu, 29 Jul 93 19:41:20 EDT
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: braden at isi.edu, ietf at CNRI.Reston.VA.US
Subject: Another query
Message-ID: <9307291951.aa00360 at CNRI.Reston.VA.US>
Ref: Your note of Thu, 29 Jul 1993 13:59:36 -0700
>I am wondering if someone could tell me the progress in supporting
>mobility in CLNP
Bob,
I've been quite active in mobile-ip WG, and I also participate in TUBA,
so, let me try to answer your question.
>Is it progressing more or less in phase with the mobility development
>in IPv4...
All the proposals I've seen so far presented to the mobile-ip WG can
be changed with a minor set of edits to be used with CLNP.
So, mobile-CLNP is progressing in phase with mobile-ip development for IPv4
(plus/minus editorial changes).
Let me also add that if we'll adopt carrying sysids with TUBA
(as described in the draft by Dave Piscitello), this would
provide further simplifications for mobility (which, by the
way, can't be realized with IPv4).
As Scott Brim said before (in reference to the multicast capabilities
with CLNP) "Bottom line: this particular issue doesn't worry me at all."
Yakov.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15325;
29 Jul 93 20:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15318;
29 Jul 93 20:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00554;
29 Jul 93 20:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15306;
29 Jul 93 20:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15276;
29 Jul 93 19:59 EDT
Received: from aerospace.aero.org by CNRI.Reston.VA.US id aa00468;
29 Jul 93 19:58 EDT
Received: from mve.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
id AA16429 for iepg at cnri.reston.va.us; Thu, 29 Jul 1993 16:58:39 -0700
Posted-Date: Thu, 29 Jul 1993 15:59:58 -0700
Received: from US* *AEROSPACE by mve-gw.aero.org via QTFS with X.400; Thu, 29
Jul 1993 16:59:21 -0700
X400-Received: by /PRMD=AEROSPACE/ADMD=/C=US/ ; Relayed ; Thu, 29 Jul 1993
15:59:58 -0700
X400-Received: by mta MTAASCMVE ; Relayed ; Thu, 29 Jul 1993 16:59:18 -0700
Date: Thu, 29 Jul 1993 15:59:58 -0700
Message-Id: <0006902E.MAI*Sammons at courier2.aero.org>
P1-Message-Id: US**AEROSPACE; 930729225958
Ua-Content-Id: CSI NC V2.1b
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Sammons at courier2.aero.org
Subject: White House File Server
Autoforwarded: FALSE
To: kidsphere at vms.cis.pitt.edu, M2107 at eurokom.ie, iepg at CNRI.Reston.VA.US,
tcp-ip at nic.ddn.mil, alljnt at jnt.ac.uk, ccirn at lbl.gov,
apccirn at aarnet.edu.au, coa-list at rare.nl, ietf at CNRI.Reston.VA.US,
ifip-gtwy at ics.uci.edu, ifip65-prog at ics.uci.edu,
iucc-directors at durham.ac.uk, mhsnews at ics.uci.edu, newsletters at rare.nl,
ripe at ripe.net, wg-all at rare.nl, home-ed-politics-request at mainstream.com,
kincaid at spot.colorado.edu, Comserve at vm.its.rpi.edu,
listserv at uvmvm.uvm.edu, 75300.3115 at compuserve.com, nic at cerf.net,
askeric at ericir.syr.edu, apple.bugs at applelink.apple.com,
odin at pilot.njin.net
I'm not looking to contact Clinton nor Gore (nor Hilery).... especially from
an E-mail system assoicated with Aerospace. Big No No..
What I was looking for was the address with whom to register my E-mail
address to get regular updates on White House news. You distributed such
about 6 months ago.
Thanks,
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15529;
29 Jul 93 20:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15521;
29 Jul 93 20:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00893;
29 Jul 93 20:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15501;
29 Jul 93 20:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15460;
29 Jul 93 20:14 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa00828;
29 Jul 93 20:14 EDT
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3629;
Thu, 29 Jul 93 20:15:27 EDT
Date: Thu, 29 Jul 93 20:14:53 EDT
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: bill at wizard.gsfc.nasa.gov
cc: ietf at CNRI.Reston.VA.US
Subject: Last Call: Use of ISO CLNP in TUBA
Message-ID: <9307292014.aa00828 at CNRI.Reston.VA.US>
Ref: Your note of Thu, 29 Jul 1993 18:34:28 -0400 (EDT)
>Another key problem I see with TUBA/CLNP is that it is
>way behind the development curve in several key areas
>such as ... interdomain routing.
Bill,
To address your concern I would suggest to separate the issue
of protocol spec and the issue of vendors support.
With respect to protocol spec I would be hardly pressed to
see how BGP (which is what is used for interdomain routing in IP)
is more advanced than IDRP. Just remember that BGP-4
is a subset of IDRP, and in fact BGP-4 spec contains large sections
of IDRP spec in pretty much "as is" form (you should trust me on
this, since I was the person who did this "cut and paste").
The issue you raised is vendor support. As Dave Katz pointed
before, there are several independent implementations of IDRP
under way, and some of these implementations are (or will be) in the public
domain. So, to address your concern with vendor support
you may talk to your favorite vendor. My understanding
is that router vendors who are intended to stay in the business
do listen to the requirements of their customers...
Yakov Rekhter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15775;
29 Jul 93 20:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15768;
29 Jul 93 20:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01110;
29 Jul 93 20:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15756;
29 Jul 93 20:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15713;
29 Jul 93 20:27 EDT
Received: from wizard.gsfc.nasa.gov by CNRI.Reston.VA.US id aa01092;
29 Jul 93 20:27 EDT
Received: by wizard.gsfc.nasa.gov (5.65/1.35)
id AA29127; Thu, 29 Jul 93 20:19:59 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Fink <bill at wizard.gsfc.nasa.gov>
Message-Id: <9307300019.AA29127 at wizard.gsfc.nasa.gov>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Eva Kuiper <eva at hpindda.cup.hp.com>
Date: Thu, 29 Jul 1993 20:19:58 -0400 (EDT)
Cc: jnc at ginger.lcs.mit.edu, braden at isi.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: <9307292329.AA20274 at hpindda.cup.hp.com> from "Eva Kuiper" at Jul 29, 93 04:29:49 pm
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1202
> Gee, I haven't used static routing in over a year. I use ES-IS. Routers
> can use IS-IS. On my system I only tell all packets with a given
> prefix to please go talk to that router over there.
>
> I must admit that I am puzzled why folks keep saying that capabilities
> are not there which are in fact already there. Since there is also
> ongoing development work in IDRP, I would say that the routing
> capabilities of a CLNP backbone are pretty far advanced. Saying that
> CLNP only does static routing does not match my experiences.
>
> Eva
Eva,
I'm sorry if you thought I was implying that CLNP only does static
routing. That was not my intent. I was aware of ES-IS and IS-IS
capabilities for intra-domain routing. My reference to static routing
was only for the inter-domain routing case, which is obviously crucial
to supporting a worldwide Internet. I was also aware of the ongoing
efforts on IDRP and have no reason to believe it won't work. I just
get a little nervous with all these development and deployment efforts
going on in parallel with the IPng efforts and having them all be
interdependent. It will certainly make for several interesting years
ahead.
-Bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15912;
29 Jul 93 20:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15905;
29 Jul 93 20:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01393;
29 Jul 93 20:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15891;
29 Jul 93 20:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15862;
29 Jul 93 20:43 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa01343;
29 Jul 93 20:43 EDT
Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/%I%)
id AA07852; Thu, 29 Jul 93 18:44:01 -0600
Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17)
id AA25669; Thu, 29 Jul 93 18:44:04 MDT
Message-Id: <9307300044.AA25669 at goshawk.lanl.gov>
To: braden at isi.edu
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Thu, 29 Jul 93 10:28:26 -0700.
<199307291728.AA23261 at can.isi.edu>
Date: Thu, 29 Jul 93 18:44:03 MST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: peter at goshawk.lanl.gov
Bob,
I don't believe the TUBA spec is the right place to discuss multicast
behavior of CLNP. The last call is to move the TUBA spec to PS.
We can expect documents describing multicast behavior for CLNP in the
Internet when the OSI-EXTND working group is on a roll. As others
have noted, it is a simple matter to clone "multicast" behavior from
IPv4 to CLNP. We were hoping to use the flexibility of NSAP addressing
structure to perhaps add functionality beyond what we are using today.
cheers,
peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16292;
29 Jul 93 21:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16282;
29 Jul 93 21:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02221;
29 Jul 93 21:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16266;
29 Jul 93 21:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16215;
29 Jul 93 21:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02174;
29 Jul 93 21:22 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16199;
29 Jul 93 21:22 EDT
To: ietf at CNRI.Reston.VA.US
cc: isoc at CNRI.Reston.VA.US, hfunk at CNRI.Reston.VA.US, vcerf at CNRI.Reston.VA.US
Subject: Funding IETF Secretariat
Date: Thu, 29 Jul 93 21:22:32 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9307292122.aa16199 at IETF.CNRI.Reston.VA.US>
Dear IETFers,
I apologize for adding to your email load, but this is a matter
of vital importance to all of us who consider the IETF work to
be central to the developing global information infrastructure.
As you know, for many years, ARPA, DOE, NASA and NSF have been
key supporters of Internet-related work and, in recent times,
the work of the IETF and its secretariat at CNRI. In the last
few years, however, the IETF activity has grown dramatically
but the US Agencies quite appropriately have pointed out that
there are now many more beneficiaries of the IETF work than
the federal government. As many of you know, the Internet Society
has undertaken to support part of the cost of the secretariat.
This year, the commitment is $300K and in future years it will
probably be more. The cost of operating the secretariat is
on the order of $1.2M per year. The present attendance fees cover
essentially the out-of-pocket costs associated with each
IETF plenary meeting, but not much more.
The Internet Society has been working with great energy to
recruit sponsors from government, industry and academia around
the world. Your help is now vital if we are to continue this
operation at the level necessary to meet your needs.
I have attached a list of the organizational sponsors of the
Internet Society. If your organization or institution is not
one of them, please give serious thought to joining. The
organizational fees are shown below:
for profit: Founding $20K in 1993, $10K thereafter
non-profit Founding $10K in 1993, $ 5K thereafter
start up (first three years) $1K
Further inquiries may be made at:
Internet Society
1895 Preston White Drive, Suite 100
Reston, VA 22091
+1 703 648 9888
+1 703 620 0913 fax
isoc at isoc.org
Many thanks for your consideration.
Vint Cerf
President
Internet Society
7/29/93
Introducing the Charter, Founding, and Organizational Members
CHARTER MEMBERS
CORPORATION FOR NATIONAL RESEARCH INITIATIVES
EDUCOM
RESEAU ASSOCIEES POUR LA RECHERCHE EUROPEENNE
FOUNDING MEMBERS
ADVANCED NETWORK & SERVICES
APPLE COMPUTER CORPORATION
AT&T
AUSTRALIAN ACADEMIC AND RESEARCH NETWORK
BELL COMMUNICATIONS RESEARCH
BOLT BERANEK AND NEWMAN
CISCO SYSTEMS
COALITION FOR NETWORKED INFORMATION
CORPORATION FOR OPEN SYSTEMS INTERNATIONAL
CORPORATION FOR RESEARCH & EDUCATIONAL NETWORKING
DEFENSE INFORMATION SYSTEMS AGENCY
DIGITAL EQUIPMENT CORPORATION
EUROPEAN ACADEMIC RESEARCH NETWORK
EUROPEAN LABORATORY FOR PARTICLE PHYSICS
FREEPORT-MCMORAN
HUGHES AIRCRAFT COMPANY
INTERNATIONAL BUSINESS MACHINES CORPORATION
INTEROP COMPANY
ISRAELI INTER-UNIVERSITY COMPUTATION CENTER
LAWRENCE LIVERMORE NATIONAL LABORATORY
MCI COMMUNICATIONS CORPORATION
MICROSOFT CORPORATION
NATIONAL LIBRARY OF MEDICINE
NORDUNET
NOVELL, INC.
NYSERNET, INC.
ORACLE CORPORATION
PERFORMANCE SYSTEMS INTERNATIONAL, INC.
PROTEON, INC.
SIEMENS AG
SOFT-SWITCH, INC.
SOFTWARE ENGINEERING INSTITUTE
SPRINT
SUN MICROSYSTEMS, INC.
3COM CORPORATION
UNIVERSITY OF NOTRE DAME
UNIVERSITY OF WASHINGTON
U S WEST COMMUNICATIONS, INC.
UUNET TECHNOLOGIES
WELLFLEET COMMUNICATIONS INC.
ORGANIZATIONAL MEMBERS
ELECTRONIC FRONTIER FOUNDATION
NYNEX SCIENCE & TECHNOLOGY, INC.
PIPEX
TENON INTERSYSTEMS
THE RAND CORPORATION
VEDA DATA SYSTEMS, INC.
Terms of Membership
Charter and Founding Organizations provide the Internet Society with
vital financial support. This substantial and early support has made the founding of the Internet Society possible. For-profit Founding members
commit to a total of $20,000 during the 1992 and 1993 period and $10,000
per year thereafter. Non-profit, Founding government and educational institutions commit to half that amount. Regular for-profit and non-profit organizational members commit to $10,000 and $5,000 per year respectively.
There is also provision for start-ups to become regular members during their first three years at a cost of $1,000 per year. Organizations interested in participating in this program should contact Vinton Cerf at the Internet
Society secretariat.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16471;
29 Jul 93 21:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16464;
29 Jul 93 21:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02563;
29 Jul 93 21:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16452;
29 Jul 93 21:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16418;
29 Jul 93 21:36 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa02532;
29 Jul 93 21:36 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA24249; Thu, 29 Jul 93 18:36:48 -0700
Message-Id: <9307300136.AA24249 at Mordor.Stanford.EDU>
To: IETF at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 29 Jul 93 18:34:28 -0400. <9307292234.AA16658 at wizard.gsfc.nasa.gov>
Date: Thu, 29 Jul 93 18:36:48 -0700
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>
X-Mts: smtp
I have a query. Given my involvement with SIP/IPAE, the query will
likely be viewed askance by some folks. Nonetheless, I decided to
ask the community the following:
The Internet develops standards based on a strong sense of community
need and a clear indication that there are willing worker-bees to
develop the thing. That is, there are providers for the specs and
consumers of the products resulting from the specs.
CLNP has been around for sometime now. It clearly has a strong
community of worker-bees, just as enthusiastic and dedicated as
any other Internet group.
My question is about consumers. I do not have a clear sense of REAL
customers for the technology and would appreciate PRIVATE replies
suggesting who/when/why consumers will buy the products. My premise is
that CLNP products have been available for sometime and are generally
available and installed in routers, but seem not to be generally
installed or used in end-systems. Feel free to educate me on this
premise, also.
In any event, it strikes me that we are in the unusual position of
considering standardization of something that isn't brand new and
that we therefore can/should have rather concrete data about the
consumer base, rather than the more fuzzy sense we have to accept
with brand new specs.
But please don't flame/respond publically. I'll be glad to summarize
responses later, if folks wish.
Thanks.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23313;
30 Jul 93 0:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23306;
30 Jul 93 0:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06947;
30 Jul 93 0:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23294;
30 Jul 93 0:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23270;
30 Jul 93 0:01 EDT
Received: from dirt.cisco.com by CNRI.Reston.VA.US id aa06906;
30 Jul 93 0:01 EDT
Received: from lager.cisco.com by dirt.cisco.com with SMTP id AA12744
(5.67a/IDA-1.5 for ietf at cnri.reston.va.us); Thu, 29 Jul 1993 21:02:31 -0700
Message-Id: <199307300402.AA12744 at dirt.cisco.com>
To: braden at isi.edu
Cc: yakov at watson.ibm.com, ietf at CNRI.Reston.VA.US
Subject: Re: Another query
In-Reply-To: Your message of "Thu, 29 Jul 93 19:41:20 EDT."
<9307291951.aa00360 at CNRI.Reston.VA.US>
Date: Thu, 29 Jul 93 21:02:31 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jim Forster <forster at cisco.com>
> >I am wondering if someone could tell me the progress in supporting
> >mobility in CLNP
Bob,
It's worth noting that CLNP starts with some (limited) mobility built in.
Routing within an area is to the end system, so end systems can always be
moved to a differnet segment in the same area without needing to re-address
or needing to use mobility protocols.
While this does not address the mobility problems encountered when
traveling, typically it would deal well with office churning within an
organization.
-- Jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23506;
30 Jul 93 0:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23502;
30 Jul 93 0:32 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa07442;
30 Jul 93 0:32 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA21837; Thu, 29 Jul 93 23:33:20 CDT
Received: by hemlock.cray.com
id AA28147; 4.1/CRI-5.6; Thu, 29 Jul 93 23:33:16 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA28143; 4.1/CRI-5.6; Thu, 29 Jul 93 23:33:13 CDT
Received: from tsx-11.MIT.EDU by cray.com (4.1/CRI-MX 2.19)
id AA21820; Thu, 29 Jul 93 23:33:10 CDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA22127; Fri, 30 Jul 93 00:33:02 EDT
Date: Fri, 30 Jul 93 00:33:02 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9307300433.AA22127 at tsx-11.MIT.EDU>
To: Jordan Brown <jbrown at qdeck.com>
Cc: stevea at lachman.com, telnet-ietf at cray.com
In-Reply-To: Jordan Brown's message of Thu, 22 Jul 1993 16:06:22 -0700 (PDT),
<9307221606.aa21460 at angel.qdeck.com>
Subject: Re: Environment Option
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
From: Jordan Brown <jbrown at qdeck.com>
X-Mailer: ScoMail 1.0
Date: Thu, 22 Jul 1993 16:06:22 -0700 (PDT)
> 1. Assign a new option value to the Environment option.
> -- this would primarily be done for three reasons
> A. Enable detection of up-to-date systems so that the heuristics
> for interoperability could be safely avoided.
> B. Ensure that over time the old option will die out and
> avoid dragging the heuristics along forever.
> C. Implementations that pre-date the introduction of USERVAR
> will be confused if they ever receive a USERVAR, so in
> some sense there is an additional problem, even if the
> heuristics to detect the VAR/VALUE swap are used
I favor this approach because it will (one would hope) tend to lead to
a well-defined deterministic protocol, not one based on imperfect
heuristics.
In other words, the situation now is a mess and can't really be cleaned up.
Throw it away (with perhaps a bit of work for backwards compatibility)
and make the standard clean.
I favor this approach as well, for the same reasons which Jordan has
brought up. (Although this should not be all that surprising, since I
was the one who suggested it at the meeting. :-)
As for HP's assertion that we should 'uphold the output of the RFC
review process as more "correct" than reference implementations of the
RFC/Proposed Standard', at the Proposed Standard, I view this being
completely irrelevant.
The whole point of the IETF is to produce implementations that work. In
addition, the situation has been complicated by a relatively large
installed base of a "Proposed Standard", which is still subject to
change --- and it appears that at least some of the people who deployed
this large installed base didn't warn their users that they were basing
their implementation of a standard which was still subject to change.
"Mistakes were made", by many sides.
Our best hope to avoid future problems is to choose a new option number,
and to encourage temporary (== 5 years) usage of hueristics in case a
telnet implementation meets up against an older implementation.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23826;
30 Jul 93 1:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23819;
30 Jul 93 1:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08524;
30 Jul 93 1:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23807;
30 Jul 93 1:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23782;
30 Jul 93 1:07 EDT
Received: from upeksa.sdsc.edu by CNRI.Reston.VA.US id aa08426;
30 Jul 93 1:07 EDT
Received: by upeksa.sdsc.edu (AIX 3.2/UCB 5.64/4.03)
id AA13016; Thu, 29 Jul 1993 22:08:25 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Hans-Werner Braun <hwb at upeksa.sdsc.edu>
Message-Id: <9307300508.AA13016 at upeksa.sdsc.edu>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Date: Thu, 29 Jul 93 22:08:25 PDT
Cc: IETF at CNRI.Reston.VA.US
In-Reply-To: <9307300136.AA24249 at Mordor.Stanford.EDU>; from "Dave Crocker" at Jul 29, 93 6:36 pm
I guess one could fairly say that the TCP/IP-Internet was on its way out
before NSF made the strategic decision to go for TCP/IP as their
protocol of choice. Minus some island perhaps of networking
researchers, and minus the DARPA/DoD environment. With the NSF
instigation of giving TCP/IP a "strong push" the Internet just started
to "happen." It was never really designed/architected/engineered as
the Internet. For example, even in 1988, at the threshold of the T1
NSFNET backbone, the network was rather small as the following message
indicates:
Date: Sat, 30 Apr 88 17:13:47 EDT
From: Stephen Wolff <steve at note.nsf.gov>
To: Hans-Werner Braun <hwb at MCR.UMICH.EDU>
Subject: Re: Routing.
H-W - Coincidentally, I just finished reading Yakov's EGP
document, and was wondering about the state of the Policy
database and, therefore, of the (large!) collection of bilateral
agreements upon which it is based. Are the 150+ campuses in fact
making these arrangements with the regionals, and will they be
done in time? -s
All 150+ campuses? And that was very advanced stage then. In fact, the
network has been *so* *successful*, people jumped the bandwagon.
Obviously they must have been pleased with what they have seen and
heard from between the 150 networks then and the 10000+ networks
today. Not to mentioned all the networks that are just not even
connected/routed in a global fashion. Given the great success, why in
the world would people invest in anything but what is globally
accepted to work in an open environment? And obviously, given the
success and everyone liking it so much, it much be oh so robust and oh
so well engineered, nothing can go wrong for generations to come. It
sure took the steam of the OSIs, DECNETs and SNAs of the world,
certainly in the academic environments, and now more and more in
commercial and other environments as well. And until the Internet gets
Seriously In Trouble, nothing will seriously change, as there is no
incentive ("My campus network works just fine, thanks you, why do I
have to reinvest possibly millions of dollars to upgrade my 30000+
hosts on campus; the rest of the world is secondary to me and my
investment"). Also, there will certainly not being a clear path as
long as this kind of haphazard bickering about "let my protocol win"
continues. November 1992 is long gone, and we are not anywhere near a
concerted IPng "solution." The IESG encouragement of the community to
offer multiple competing proposals panned out, though. Lots of good
ideas of lots of good people are on the table. Was really energizing
to the IETF. There is this little detail that you can't cut it down to
"one," but I guess you can't win them all, and we may just have to
wait and see how things will pan out. You reference CLNP. Well, yeah,
there is some CLNP out there. I dunno how much, nor is the competing
with other protocols all that important at this stage of the game. Let
them try to get more acceptance. Let others try geting acceptance for
IPAE/SIP/PIP/whatever, we can perhaps fake it with CIDR for a while.
Generally, wouldn't it be nice if some of the rhetoric would be cut
and views get less polarized? The IETF learned alot in the process, it
may be time to move on and let things play out.
To some extend the IPng is a detail, and should be hidden from users of
whom few will care about their packet headers; no more than they care
about how their speech is digitized during telephone conversations.
They will care about service qualities, being able to communicate, and
such. Personally, I believe that the IPng thing is an
engineering/operations/management issue, and has (in the real world)
very little to do with protocols. Personally, right now I'd be more
worried about the fraction of some real-time flows on "the network"
than I am about routing and addressing. We had trouble with routing
and adressing already when we were at less than 100 networks, as
several of us will sure remember. Except, ahem, the system is Very
Large now, in comparison.
Hans-Werner
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23900;
30 Jul 93 1:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23893;
30 Jul 93 1:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08824;
30 Jul 93 1:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23881;
30 Jul 93 1:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23857;
30 Jul 93 1:18 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa08750; 30 Jul 93 1:18 EDT
Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA12291 for ietf at cnri.reston.va.us; Fri, 30 Jul 93 01:19:31 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA00361; Thu, 29 Jul 93 22:18:07 PDT
Message-Id: <9307300518.AA00361 at aland.bbn.com>
To: Tony Hain <ALH at eagle.es.net>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: 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: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 29 Jul 93 22:18:06 -0700
X-Orig-Sender: craig at aland.bbn.com
> Would the same stalling tactics be used if the proposal were to advance SIP/PIP?
Tony:
This is a truly offensive sentence. What reason is there to believe that
most participants in this discussion wish to engage in stalling? Furthermore,
what good does it do the IETF (which we try to keep collegial) for a member
to impugn the motives of a large number of fellow members?
It seems to me that the discussion has generally been in agreement that
the IETF and IESG haven't worked out the consequences of making one of the
IP:TNG proposals a Proposed Standard, and that once that's straightened out
we can go ahead. No one has suggested we should start doing joint standards
promotions (remember elevating SNMP and CMOT to Draft Standard at the same
time, "to be fair"?) or other skullduggery. (We've learned!)>
I would hope getting the issues straightened out is a matter of weeks,
or at worst a couple of months (keeping in mind that IESG/IETF is a volunteer
organization). Personally, I'd be happy with a public notice and a
few interviews in the press from various IESGers saying simply:
Observers should be aware that the timing of when individual proposals
for IP:TNG become Proposed Standards has nothing to do with their
relative merits. Just because one proposal becomes Proposed Standard
before another doesn't mean the first one is "better", "ahead in
development" or anything more than that their authors felt their
proposal was sufficiently mature to ask the IESG to consider it
as a Proposed Standard and the IESG agreed the proposal had reached
that level of maturity.
And then making sure we repeat this point when the TUBA proposal goes to
Proposed.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00738;
30 Jul 93 3:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00731;
30 Jul 93 3:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01829;
30 Jul 93 3:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00719;
30 Jul 93 3:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00682;
30 Jul 93 3:45 EDT
Received: from bridge2.NSD.3Com.COM by CNRI.Reston.VA.US id aa01738;
30 Jul 93 3:45 EDT
Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA25927
(5.65c/IDA-1.4.4nsd for <ietf at cnri.reston.va.us>); Fri, 30 Jul 1993 00:45:48 -0700
Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA11379
(5.65c/IDA-1.4.4-910725); Fri, 30 Jul 1993 00:45:46 -0700
Message-Id: <199307300745.AA11379 at remmel.NSD.3Com.COM>
To: Craig Partridge <craig at aland.bbn.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Thu, 29 Jul 93 22:18:06 PDT."
<9307300518.AA00361 at aland.bbn.com>
Date: Fri, 30 Jul 93 00:45:45 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: tracym at nsd.3com.com
Craig,
Observers should be aware that the timing of when individual proposals
for IP:TNG become Proposed Standards has nothing to do with their
relative merits. Just because one proposal becomes Proposed Standard
before another doesn't mean the first one is "better", "ahead in
development" or anything more than that their authors felt their
proposal was sufficiently mature to ask the IESG to consider it
as a Proposed Standard and the IESG agreed the proposal had reached
that level of maturity.
This is ok, but it still gives too much weight to the notion that the
TUBA RFC is, in itself, an IPng "proposal". Hopefully the many
interviews will communicate the fact that any IPng proposal will
consist of several [at least] proposed standards including the network
layer, two or more routing protocols, an addressing plan, a transition
plan, and a couple of more things that aren't on the tip of my tongue.
It is simply a reasonably self-contained mechanism which (your text is
pretty good on this point) appears mature enough to be standardized.
Now I'd like to suggest another reason why advancing TUBA might be a
GOOD THING(too strong? well then a good thing). A proposed standard
which includes CLNP and which is otherwise based on IETF-"owned"
protocols, and which then gets used, might provide a perfect vehicle
for helping IETF gain control of CLNP (or maybe CLNPng :-).
I'm off for a week, so flames will be of little avail. Remember:
It's not an IPng proposal. It's not an IPng proposal. It's not...
Tracy
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00978;
30 Jul 93 4:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00971;
30 Jul 93 4:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02531;
30 Jul 93 4:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00958;
30 Jul 93 4:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00931;
30 Jul 93 4:39 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa02481;
30 Jul 93 4:39 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.04306-0 at bells.cs.ucl.ac.uk>; Fri, 30 Jul 1993 09:39:08 +0100
To: Dave Katz <dkatz at cisco.com>
cc: braden at isi.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Thu, 29 Jul 93 13:07:33 PDT." <199307292007.AA02403 at large.cisco.com>
Date: Fri, 30 Jul 93 09:39:07 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Message-ID: <9307300439.aa02481 at CNRI.Reston.VA.US>
>Work is in progress on multicast extensions to CLNP and to first-hop routing
>(ES-IS). The basics have been defined, and are in the process of being
>implemented.
>It is very likely that the IETF work on multicast routing protocols
>will be adopted essentially as-is.
thats clever:-(
adopt a scheme in a proposed ipng for multicast which is currently
undergoing chane in IPv4 becuase of sclaing problems -
does'nt sound like a selling point to me for something proposed to
solve our scaling problems in other areas!
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01940;
30 Jul 93 7:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01933;
30 Jul 93 7:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05421;
30 Jul 93 7:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01919;
30 Jul 93 7:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01801;
30 Jul 93 7:57 EDT
Received: from EMU.NCSL.NIST.GOV by CNRI.Reston.VA.US id aa05396;
30 Jul 93 7:57 EDT
Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm))
id AA10576; Fri, 30 Jul 93 08:01:44 EDT
Date: Fri, 30 Jul 93 08:01:44 EDT
Organization: National Institute of Standards and Technology (NIST)
Sub-Organization: Computer Systems Laboratory (CSL)
Message-Id: <9307301201.AA10576 at emu.ncsl.nist.gov>
To: braden at isi.edu, swb1 at cornell.edu
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at CNRI.Reston.VA.US, colella at nist.gov
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: colella at nist.gov
Reply-To: colella at nist.gov
In the exchange between Scott and Bob:
> I consider the whole area of
> *> multicast routing to be up in the air right now, regardless of protocol.
> *>
>
> That is certainly true.
>
> *>
> *> So, my personal view is that if we wanted ISO multicast in a hurry we could
> *> clone what we have for IP. As always, copying someone's work takes a lot
> *> less time than doing it the first time. In the meantime work is being done
> *> to improve on IP. They have all sorts of options, e.g. different kinds of
> *> scope, which may be unnecessary (but they don't know yet). At least it's
> *> nice to have the flexibility to put them in. Bottom line: this particular
> *> issue doesn't worry me at all.
> *>
>
> If there is no hurry, why is there a fuss about making TUBA/CLNP a
> Proposed Standard instantly?
The last sentence is a non sequitur. More to the point, if multicast
routing is up in the air right now (which statement both agree on),
why is this being used as a criterion for judging any of the proposals.
--Richard
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02629;
30 Jul 93 8:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02622;
30 Jul 93 8:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07147;
30 Jul 93 8:38 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02610;
30 Jul 93 8:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02549;
30 Jul 93 8:37 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa07099;
30 Jul 93 8:37 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa08773;
30 Jul 93 12:28 GMT
Date: Fri, 30 Jul 93 12:29 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: IETF <IETF at CNRI.Reston.VA.US>
Subject: My thoughts on the IPng issue.
Message-Id: <40930730122904/0003858921NA3EM at mcimail.com>
Hans-Werner Braun said:
>And until the Internet gets Seriously In Trouble, nothing will seriously
>change, as there is no incentive ("My campus network works just fine,
>thanks you, why do I have to reinvest possibly millions of dollars to
>upgrade my 30000+ hosts on campus; the rest of the world is secondary to me
>and my investment").
Thank you for a lead in for my developing thoughts on this issue.
I am the TCP/IP tech support person for Chyrsler corporate. Chrysler
engineering has their own specialists and we work together, for the most
part :). In the past two years we have seen an explosion of IP usage and we
see no slowdown in this growth for a few years.
We have a few registered B class networks and have learned the hard way that
these do not give us enough flexablity. So in many places we are using
unregistered C class networks. We view this as a short term, 'not a
problem', as we are well firewalled from the INTERNET. This will
undoubtably change when we have a fully secured internal network ;).
But we have a series of problems with TCP/IP. One is education. I am the
only one on the corporate side that has taken the time to really learn
TCP/IP. I did this by coniving my way to INTEROP two years ago to take the
Comer class on internals (taught by Dr. Peterson). To this, I am 'eternally
grateful'. We still make mistakes (like my subnet 0 problem), but they are
manageable.
What is not manageable are the following:
Static System Addressing
Novell rightly crows about their addressing scheme. We constantly have
users 'sneeking' systems in, copying software (instead of installing), and
plugging in. Then we have to go in and clean up the mess. BOOTP has been
recommended to me as a way to tackle this. I see that it is a lesser of two
evils, but I am only now succeeding on selling management on DNS (the
engineering HOST TABLE is 500Kb and still growing. I have held our 'well
known host file' to 15Kb).
We have constant user moves. Some are 'small moves' and no problem. But
even 'small moves' can cross the 'line of death'. This is the line drawn on
the office diagram of which desks are connected to which wiring closet, thus
on which subnet...
IP Mobility is VERY important for the corporate user.
Routing table size
We are almost all OSPF. Our backbone routers are. Was and is a bit of a
struggle, but my colleagues that support the network have done it. Two
problems. Lots of hosts listen to RIP not OSPF, so we still have RIP at end
points. And RIP has frequently been a problem with our unique IP masks. We
have gotten on a roll of using C licenses for PC LANs in many facilities and
for key datacenter networks. Since we do not have CIDR yet, the rest
follows.
Management acceptance
Management hears the debates between the various technicians (IP, IPX, and
SNA) and in the media and they are frankly scared s**tless about their
mission critical applications. They are not comforted by comments that 'any
addressing scheme has to be re-evaluated and changed every 2 years'. They
want to be isolated from the network. It has to be a managable utility.
So bottom line. I got future worries link real-time video. But I got now
problems that have nothing to do with the scalability of IPv4, or do they?
We won't be changing, internally, from IPv4 anytime soon. Our stack vendors
will have to give it to us practically free (in the maintance agreement
costs). AND for PCs, it better not take up any more memory! I suppose that
only a clean, affordable ($ and memory), solution to the configuration and
mobility issue would cause a change here.
So go ahead and advance TUBA to PS. Make your politically correct press
statements (I know the media as well as the rest of you, sigh). Design your
selection process for IPng. Build your transition plans (do not forget what
you went through for DNS! How many years did that take?). We, the
corporate users of TCP/IP, will be watching and learning with you, but not
following for some time.
BTW, someone mentioned something called NAT. Sounds interesting. Can I be
pointed to documentation on it?
Robert Moskowitz
MIS Technical Support
Chrysler Corporation
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03546;
30 Jul 93 9:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03539;
30 Jul 93 9:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08837;
30 Jul 93 9:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03527;
30 Jul 93 9:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03471;
30 Jul 93 9:13 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa08720;
30 Jul 93 9:13 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aq09853;
30 Jul 93 13:03 GMT
Date: Fri, 30 Jul 93 13:07 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Christopher Zguris <0004854540 at mcimail.com>
To: "IETF at CNRI.RESTON.VA.US" <IETF at CNRI.Reston.VA.US>
Subject: SIGN ME OFF
Message-Id: <84930730130748/0004854540NA2EM at mcimail.com>
Please sign me off the IETF list.
Christopher Zguris
485-4540 at MCIMail.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03726;
30 Jul 93 9:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03719;
30 Jul 93 9:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09014;
30 Jul 93 9:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03706;
30 Jul 93 9:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03587;
30 Jul 93 9:17 EDT
Received: from norge.unet.umn.edu by CNRI.Reston.VA.US id aa08898;
30 Jul 93 9:16 EDT
Received: by norge.unet.umn.edu (5.65c)
id AA01362; Fri, 30 Jul 1993 08:17:31 -0500
Date: Fri, 30 Jul 1993 08:17:31 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Craig A. Finseth" <fin at unet.umn.edu>
Message-Id: <199307301317.AA01362 at norge.unet.umn.edu>
To: wright at lbl.gov
Cc: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
In-Reply-To: Russ Wright's message of Wed, 28 Jul 93 10:40:01 PDT <9307281740.AA03050 at lbl.gov>
Subject: Last Call: Use of ISO CLNP in TUBA
Reply-To: Craig.A.Finseth-1 at umn.edu
Just a quick comment (I'll let someone else give a long, well written response).
The HEPNet (high energy physics) community is currently migrating from
DECNet Phase IV (the current version of DECNet) to DECNet Phase V, which
uses CLNP, so CLNP is very important to them (maybe someone can give the #
of hosts in HEPnet). The bottom line is that CLNP will not go away.
According to our DEC network engineer, DECNet Phave V = Phas IV +
TCP/IP + CLNP, with about 90% of his users going to TCP/IP.
The fact that CLNP is supported on a large part of the Internet should tell
you something. Network providers don't support something unless people ask
for it and can justify its use.
But, seriously....
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04982;
30 Jul 93 10:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04975;
30 Jul 93 10:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10891;
30 Jul 93 10:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04963;
30 Jul 93 10:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04912;
30 Jul 93 10:07 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa10763;
30 Jul 93 10:07 EDT
Received: by ginger.lcs.mit.edu
id AA24998; Fri, 30 Jul 93 10:07:39 -0400
Date: Fri, 30 Jul 93 10:07:39 -0400
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: <9307301407.AA24998 at ginger.lcs.mit.edu>
To: dkatz at cisco.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
The IETF seems poised to adopt the OSI interdomain routing protocol for
use with IP.
I think this is a bit of an exaggeration. When I found the following statement
in RFC-1482:
Therefore, a peer which needs to receive full routing information
should run a protocol which supports CIDR (initially, BGP-4; later,
IDRP).
I went and asked around as to where and when the decision to go to IDRP had
been made, and was told, in essense, that some people wanted to do this, but
it was not a general feeling, and was not by any means decided.
Noel
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06561;
30 Jul 93 11:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13448;
30 Jul 93 11:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06547;
30 Jul 93 11:25 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05284;
30 Jul 93 10:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tn3270e at list.nih.gov
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: ID ACTION:draft-ietf-tn3270e-luname-print-00.txt
Date: Fri, 30 Jul 93 10:22:55 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9307301023.aa05284 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 Telnet TN3270 Enhancements
Working Group of the IETF.
Title : TN3270 Extensions for LUname and Printer Selection
Author(s) : C. Graves
Filename : draft-ietf-tn3270e-luname-print-00.txt
Pages : 12
This document describes protocol extensions to TN3270. There are two
extensions outlined in this document. The first defines a way by which a
TN3270 client can request a specific device (LUname) from a TN3270 server.
The second extension specifies how a TN3270 printer device can be requested
by a TN3270 client and the manner in which the 3270 printer status
information can be sent to the TN3270 server. Discussions and suggestions
for improvements to these enhancements should be sent to the TN3270E
Working Group mailing list TN3270E at list.nih.gov . These extensions will be
called TN3287 in this document. This information is being provided to
members of the Internet community that want to support the 3287 data stream
within the TELNET protocol. The distribution of this memo is unlimited.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tn3270e-luname-print-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-tn3270e-luname-print-00.txt".
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-tn3270e-luname-print-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tn3270e-luname-print-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07157;
30 Jul 93 12:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07150;
30 Jul 93 12:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14951;
30 Jul 93 12:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07138;
30 Jul 93 12:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07103;
30 Jul 93 12:04 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa14856;
30 Jul 93 12:04 EDT
Received: by large.cisco.com id AA16230
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Fri, 30 Jul 1993 09:05:22 -0700
Date: Fri, 30 Jul 1993 09:05:22 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199307301605.AA16230 at large.cisco.com>
To: J.Crowcroft at cs.ucl.ac.uk
Cc: braden at isi.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: Jon Crowcroft's message of Fri, 30 Jul 93 09:39:07 +0100 <199307300839.AA18464 at dirt.cisco.com>
Subject: Last Call: Use of ISO CLNP in TUBA
Perhaps I wasn't clear. How about,
"will be adopted essentially as-will-be."
It is understood that IP multicast is in flux, and that lots more work
needs to be done in this area.
The point is that the people working on this are watching, nay, participating
in what's going on in the IP world. It's not "them," it's "us."
Date: Fri, 30 Jul 93 09:39:07 +0100
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
>Work is in progress on multicast extensions to CLNP and to first-hop routing
>(ES-IS). The basics have been defined, and are in the process of being
>implemented.
>It is very likely that the IETF work on multicast routing protocols
>will be adopted essentially as-is.
thats clever:-(
adopt a scheme in a proposed ipng for multicast which is currently
undergoing chane in IPv4 becuase of sclaing problems -
does'nt sound like a selling point to me for something proposed to
solve our scaling problems in other areas!
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab07519;
30 Jul 93 12:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07507;
30 Jul 93 12:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15587;
30 Jul 93 12:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07488;
30 Jul 93 12:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab07432;
30 Jul 93 12:28 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa15442;
30 Jul 93 12:28 EDT
Received: by large.cisco.com id AA16911
(5.67a/IDA-1.5 for ietf at cnri.reston.va.us); Fri, 30 Jul 1993 09:29:15 -0700
Date: Fri, 30 Jul 1993 09:29:15 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199307301629.AA16911 at large.cisco.com>
To: jnc at ginger.lcs.mit.edu
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
In-Reply-To: Noel Chiappa's message of Fri, 30 Jul 93 10:07:39 -0400 <9307301407.AA24998 at ginger.lcs.mit.edu>
Subject: Last Call: Use of ISO CLNP in TUBA
I will leave it to someone more official than I, but it's my
understanding that the BGP and IPIDRP working groups have been trying
to merge for some time, and have settled for meeting jointly until the
procedural problems are cleared up. I attended the Amsterdam joint
meeting, and came away with the impression that moving to IDRP in fact
was the general feeling among the attendees of the meeting.
I suppose this gets into the dirty business of trying to determine what
is a "general feeling" or a "consensus"--it all depends on who you ask.
Please, let's all drop this thread and get back to work...
Date: Fri, 30 Jul 93 10:07:39 -0400
From: jnc at ginger.lcs.mit.edu (Noel Chiappa)
The IETF seems poised to adopt the OSI interdomain routing protocol for
use with IP.
I think this is a bit of an exaggeration. When I found the following statement
in RFC-1482:
Therefore, a peer which needs to receive full routing information
should run a protocol which supports CIDR (initially, BGP-4; later,
IDRP).
I went and asked around as to where and when the decision to go to IDRP had
been made, and was told, in essense, that some people wanted to do this, but
it was not a general feeling, and was not by any means decided.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08243;
30 Jul 93 13:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08236;
30 Jul 93 13:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17219;
30 Jul 93 13:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab08224;
30 Jul 93 13:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08201;
30 Jul 93 13:27 EDT
Received: from eagle.nersc.gov by CNRI.Reston.VA.US id aa17202;
30 Jul 93 13:27 EDT
Date: Fri, 30 Jul 1993 10:27:57 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Hain <ALH at eagle.es.net>
Message-Id: <930730102757.439 at EAGLE.ES.NET>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: ietf at CNRI.Reston.VA.US
X-Vmsmail-To: smtp%"ietf at cnri.reston.va.us"
Craig,
I am not trying to offend those who are trying to be objective here. I have
recieved comments though, to the effect that this whole discussion would not
have happened if this proposal did not have an OSI reference.
I do like your proposed text, with the exception that the 'for IP:TNG' be
dropped. This should be a generic for all efforts. Mod text:
Observers should be aware that the timing of when individual proposals
become Proposed Standards has nothing to do with their
relative merits. Just because one proposal becomes Proposed Standard
before another doesn't mean the first one is "better", "ahead in
development" or anything more than that their authors felt their
proposal was sufficiently mature to ask the IESG to consider it
as a Proposed Standard and the IESG agreed the proposal had reached
that level of maturity.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09796;
30 Jul 93 14:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09787;
30 Jul 93 14:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19382;
30 Jul 93 14:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09772;
30 Jul 93 14:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09694;
30 Jul 93 14:34 EDT
Received: from vela.acs.oakland.edu by CNRI.Reston.VA.US id aa19330;
30 Jul 93 14:34 EDT
Received: from via.ws13.merit.edu by vela.acs.oakland.edu with SMTP id AA09564
(5.65c+/IDA-1.4.4); Fri, 30 Jul 1993 14:35:07 -0400
Date: Fri, 30 Jul 93 13:18:51 EDT
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: <920.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-To: bsimpson at morningstar.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Wow, 358K of messages on this topic in 24 hours! A bit much for those
of us on 2400 and 9600 bps links, let alone actually reading it.
As for when to publish things as "proposed standards" as opposed to
"experimental" or "prototype", I am glad that we have so many watchdogs.
The "last call" is clearly a good thing, as it gives us an opportunity
to advise.
I will note that the TPIX RFCs were listed as "experimental", and I've
never seen a listing for "prototype" yet.
However, there is another issue: change control. I don't think that
anything from the TUBA WG should be published by the IETF except as
"informational", just as any other proprietary protocol.
1) At the Amsterdam IETF, it was clearly announced by one of the TUBA
co-chairs that even if TUBA were not adopted as IPng, the TUBA work
will continue. This means (to me) that the TUBA proponents are not
willing to work within the IETF standardization process. Having
such a process includes a decision when to *quit*.
2) When directly asked whether the IPng would be proposed to OSI as
the CLNPng, the co-chair was unable to make a commitment. This is
particularly enervating (to me) as so many of the ISO authors also
participate in the IETF. Why bother having an "OSI-EXTEND" WG, if
we can't actually make substantive changes?
3) There has been no effort to formally replace TPx with TCP, or to
gain "official" ISO/IEC recognition for TCP as an alternative.
Ditto IP -- witness the extensive disclamers in ISO/IEC 9577. This
also indicates (to me) that we will have no real change control for
TCP over CLNP.
Not-with-standing arguments and assertions that most IETF innovations
which have been proposed to ISO have been adopted without modification,
if the fundamentals are not subject to change control, then the
information cannot be published by our organisation except as
informational.
I encourage informational cross-publication, which informs the rest of
us about related activities. But, this has its opportunity for
misrepresentation as well.
Remember what happened last winter when Novell got their IPX-WAN as an
informational RFC. It was announced by the press that IPX-WAN had been
accepted by the IETF over its own IPXCP for PPP links, and IPX was now a
"recognized" alternative to IP. Neither statement was true. (BTW,
IPX-WAN is now in version 2, which has not been published, a problem
with proprietary protocols.)
The encapsulation of IPX over IP (and CLNP over IP) is a matter over
which we *do* have change control, and is an appropriate topic for
IETF standardization.
If installed base were really the issue, we would have a TCP over IPX
working group.
> From: tracym at nsd.3com.com
> It's not an IPng proposal. It's not an IPng proposal. It's not...
>
In that case, the TUBA proposal should be dropped from IETF consideration,
and publication should be by the other responsible bodies.
Disclaimer: some of the folks working on the TUBA proposals are among
the smartest engineers I've met, as are those on the other proposals.
This is not about the technical merits of the proposal, but about the
principles which apply to the process. I'm obviously taking an extra
hard line.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10571;
30 Jul 93 15:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10563;
30 Jul 93 15:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20480;
30 Jul 93 15:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10546;
30 Jul 93 15:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10517;
30 Jul 93 15:13 EDT
Received: from lager.cisco.com by CNRI.Reston.VA.US id aa20459;
30 Jul 93 15:13 EDT
Received: by lager.cisco.com id AA02988
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Fri, 30 Jul 1993 12:13:39 -0700
Date: Fri, 30 Jul 1993 12:13:39 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Li <tli at cisco.com>
Message-Id: <199307301913.AA02988 at lager.cisco.com>
To: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Bill,
However, there is another issue: change control. I don't think that
anything from the TUBA WG should be published by the IETF except as
"informational", just as any other proprietary protocol.
This does not follow. The IETF has no change control over Ethernet.
Does this mean that the IETF cannot publish documents on IP over
Ethernet?
1) At the Amsterdam IETF, it was clearly announced by one of the TUBA
co-chairs that even if TUBA were not adopted as IPng, the TUBA work
will continue. This means (to me) that the TUBA proponents are not
willing to work within the IETF standardization process. Having
such a process includes a decision when to *quit*.
I think you need to be very clear about what work will continue and
who will do it. Work will continue on CLNP. This is wholly
orthogonal to the IETF. Will work continue on TUBA? Well, from a
vendor perspective, it will continue iff people are willing to pay for
it. Note that this is not exclusive to TUBA. It is true for all IPng
proposals and for any new proprietary network layers that you care to
think up.
2) When directly asked whether the IPng would be proposed to OSI as
the CLNPng, the co-chair was unable to make a commitment. This is
particularly enervating (to me) as so many of the ISO authors also
participate in the IETF. Why bother having an "OSI-EXTEND" WG, if
we can't actually make substantive changes?
It would be very difficult for any individual to make a commitment
that they cannot support. Proposing IPng to ISO must come from a
national body, NOT an individual. In any case, I'm not sure that it
matters. If we have an installed base, then the money and standards
will follow.
3) There has been no effort to formally replace TPx with TCP, or to
gain "official" ISO/IEC recognition for TCP as an alternative.
Ditto IP -- witness the extensive disclamers in ISO/IEC 9577. This
also indicates (to me) that we will have no real change control for
TCP over CLNP.
This is not necessary. There is no need to replace TPx. It is wholly
orthogonal. Having multiple, competing, protcols on top of the
network layer is not a problem. Please look at IPv4 if you're not
convinced yet.
If installed base were really the issue, we would have a TCP over IPX
working group.
There is no need for a working group in IETF, as Provo/Walnut
Creek/San Jose would simply dictate.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11285;
30 Jul 93 16:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11278;
30 Jul 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21926;
30 Jul 93 16:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab11264;
30 Jul 93 16:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11171;
30 Jul 93 16:01 EDT
Received: from umd5.umd.edu by CNRI.Reston.VA.US id aa21864; 30 Jul 93 16:01 EDT
Received: by umd5.umd.edu id <AA03276 at umd5.umd.edu>; Fri, 30 Jul 93 16:01:22 -0400
Message-Id: <9307302001.AA03276 at umd5.umd.edu>
To: bsimpson at morningstar.com
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Fri, 30 Jul 93 13:18:51 -0400.
<920.bill.simpson at um.cc.umich.edu>
Date: Fri, 30 Jul 93 16:01:17 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike StJohns <stjohns at umd5.umd.edu>
X-Mts: smtp
>
> 3) There has been no effort to formally replace TPx with TCP, or to
> gain "official" ISO/IEC recognition for TCP as an alternative.
> Ditto IP -- witness the extensive disclamers in ISO/IEC 9577. This
> also indicates (to me) that we will have no real change control for
> TCP over CLNP.
How soon we forget history. My understanding (possibly wrong or
incomplete) is that TCP and IP were proposed as the US contribution to
ISO for what eventually became CLNS and TP0-TP4 (yup - this was a
while ago.) After serious discussion they were discarded and other
paths were persued.
Mike
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12900;
30 Jul 93 17:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25820;
30 Jul 93 17:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12887;
30 Jul 93 17:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12829;
30 Jul 93 17:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa25760;
30 Jul 93 17:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA22148>; Fri, 30 Jul 1993 14:35:16 -0700
Message-Id: <199307302135.AA22148 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1486 on an Experiment in Remote Printing
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 30 Jul 93 14:35:13 PDT
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 1486:
Title: An Experiment in Remote Printing
Author: M. Rose & C. Malamud
Mailbox: mrose at dbc.mtview.ca.us, carl at malamud.com
Pages: 14
Characters: 26,373
Updates/Obsoletes: none
Although electronic mail is preferable as a means of third-party
communication, in some cases it may be necessary to print information,
in hard-copy form, at a remote location. The remote output device may
consist of a standard line printer, a printer with multiple fonts and
faces, a printer that can reproduce graphics, or a facsimile device.
Remote output may be accompanied by information that identifies the
intended recipient. This RFC describes a technique for "remote
printing" using the Internet mail infrastructure. In particular, this
memo focuses on the case in which remote printers are connected to the
international telephone network. Furthermore, it describes an
experiment in remote printing.
This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard. Discussion and suggestions
for improvement are requested. Please refer to the current edition of
the "IAB Official Protocol Standards" 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 NIC.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 1111, "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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1486.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1486.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12979;
30 Jul 93 17:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12972;
30 Jul 93 17:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25994;
30 Jul 93 17:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12959;
30 Jul 93 17:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab12935;
30 Jul 93 17:42 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa25972;
30 Jul 93 17:42 EDT
Received: by large.cisco.com id AA24129
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Fri, 30 Jul 1993 14:42:34 -0700
Date: Fri, 30 Jul 1993 14:42:34 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199307302142.AA24129 at large.cisco.com>
To: stjohns at umd5.umd.edu
Cc: bsimpson at morningstar.com, ietf at CNRI.Reston.VA.US
In-Reply-To: Mike StJohns's message of Fri, 30 Jul 93 16:01:17 -0400 <9307302001.AA03276 at umd5.umd.edu>
Subject: Last Call: Use of ISO CLNP in TUBA
C'mon, Mike, when this took place, any of the under-30 set in the IETF
had not yet graduated from high school. A few things have changed
since then.
Can we please all try to put our politics aside and get back to work?
Thank you.
Date: Fri, 30 Jul 93 16:01:17 -0400
Sender: ietf-request at IETF.CNRI.Reston.VA.US
From: Mike StJohns <stjohns at umd5.umd.edu>
X-Mts: smtp
>
> 3) There has been no effort to formally replace TPx with TCP, or to
> gain "official" ISO/IEC recognition for TCP as an alternative.
> Ditto IP -- witness the extensive disclamers in ISO/IEC 9577. This
> also indicates (to me) that we will have no real change control for
> TCP over CLNP.
How soon we forget history. My understanding (possibly wrong or
incomplete) is that TCP and IP were proposed as the US contribution to
ISO for what eventually became CLNS and TP0-TP4 (yup - this was a
while ago.) After serious discussion they were discarded and other
paths were persued.
Mike
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02321;
31 Jul 93 13:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02317;
31 Jul 93 13:54 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa13229;
31 Jul 93 13:54 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (5.65/1.14)
id AA18692; Sat, 31 Jul 93 11:49:32 -0600
Received: by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA06549; Sat, 31 Jul 93 11:48:22 MDT
Return-Path: <wright at lbl.gov>
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1)
id AA06545; Sat, 31 Jul 93 11:48:21 MDT
Received: from lbl.gov by mailhost.lanl.gov (5.65/1.14)
id AA18676; Sat, 31 Jul 93 11:48:20 -0600
Received: from [131.243.64.68] (macruss.lbl.gov) by lbl.gov (4.1/1.39)
id AA03650; Sat, 31 Jul 93 10:53:21 PDT
Date: Sat, 31 Jul 93 10:53:21 PDT
Message-Id: <9307311753.AA03650 at lbl.gov>
To: Craig.A.Finseth-1 at umn.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Russ Wright <wright at lbl.gov>
X-Sender: wright at net.lbl.gov
Subject: PhaseV or Re: Last Call: Use of ISO CLNP in TUBA
Cc: henryc at oar.net, desjardi at boa.gsfc.nasa.gov, ietf at CNRI.Reston.VA.US,
tuba at lanl.gov
At 8:17 AM 7/30/93 -0500, Craig A. Finseth wrote:
...
>According to our DEC network engineer, DECNet Phave V = Phas IV +
>TCP/IP + CLNP, with about 90% of his users going to TCP/IP.
>
Translation: YOUR site doesn't care much about PhaseV. This is OK
(although, you do have 10% of your people to worry about. Ah, just ignore
them when they ask for CLNP connectivity ;-) ).
Sure, there will be sites that don't care about DECNet (phase V or IV).
The 115,000+ hosts in HEPnet and SPAN do care.
BTW- PhaseV = Phase IV + CLNP. (i.e. TCP is not part of PhaseV DECNet)
On ULTRIX systems, there is TCP (since it is UNIX) along with PhaseV.
On VMS systems, you can purchase something like Multinet to get TCP.
Well, this subject has been beaten up enough. I will sit back and listen now.
Russ
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04032;
31 Jul 93 18:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04025;
31 Jul 93 18:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20575;
31 Jul 93 18:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04013;
31 Jul 93 18:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03989;
31 Jul 93 18:56 EDT
Received: from newsun.Novell.COM by CNRI.Reston.VA.US id aa20501;
31 Jul 93 18:56 EDT
Received: from va.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1)
id AA02949; Sat, 31 Jul 93 15:57:15 PDT
Received: by va.SJF.Novell.COM (4.1/SMI-4.1)
id AA25954; Sat, 31 Jul 93 15:55:04 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Neal Castagnoli <Neal_Castagnoli at novell.com>
Message-Id: <9307312255.AA25954 at va.SJF.Novell.COM>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: bsimpson at morningstar.com
Date: Sat, 31 Jul 93 15:55:03 PDT
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <920.bill.simpson at um.cc.umich.edu>; from "William Allen Simpson" at Jul 30, 93 1:18 pm
X-Mailer: Elm [version 2.1 alpha-test]
> Remember what happened last winter when Novell got their IPX-WAN as an
> informational RFC. It was announced by the press that IPX-WAN had been
> accepted by the IETF over its own IPXCP for PPP links, and IPX was now a
> "recognized" alternative to IP. Neither statement was true. (BTW,
> IPX-WAN is now in version 2, which has not been published, a problem
^^^^
> with proprietary protocols.)
Actually, this is incorrect on two counts. First of all, IPXWAN version II
is published and available by contacting Rod Stuhlmuller at his email
address:
rstuhlmu at na.SJF.Novell.COM
Or you can call Novell in San Jose (the general number is 408 434 2300).
In this sense, IPXWAN version II is open, and generally we (meaning myself
and the designers) actually appreciate comments.
Novell has not released any product including IPXWAN version II yet.
Anyway, I did have my 2 cents on the use of TCP over CLNP as a potential
anything. It seems to me that TCP applications rely extensively on the use
of network layer filtering in order to make them secure. However, I
can't figure out a good way to do filtering with CLNP within a level 1 area.
The reason is that CLNP does not assign addresses to networks, but rather to
hosts. If you have lots of workstations, it would seem to me that filtering
would be pretty difficult, because you can not filter on a network. Rather,
you have to identify each host that should be filtered, or each host that
would be allowed service (potentially CPU and administratively intensive).
Some have suggested that the way to solve this problem is to collapse level I
routing and have it operate on a single subnetwork only. Doing this
effectively gives each LAN an address. This has disadvantages. Each
router then would need to run a copy of IS - IS for each of the LANs to
which it is connected. Or IS - IS would need to be redesigned.
It seems to me that simple things like this could potentially make it
difficult to really run TCP applications over CLNP in production. I would
hope that there is more operational experience with TCP over CLNP from a
users perspective, to ensure that some of the assumptions that have built up
in the application layer about the network layer are not violated by the
use of CLNP.
--Neal Castagnoli
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10124;
2 Aug 93 15:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10115;
2 Aug 93 15:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23802;
2 Aug 93 15:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10079;
2 Aug 93 15:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10019;
2 Aug 93 15:27 EDT
Received: from vela.acs.oakland.edu by CNRI.Reston.VA.US id aa23728;
2 Aug 93 15:27 EDT
Received: from via.dsf1.merit.edu by vela.acs.oakland.edu with SMTP id AA25846
(5.65c+/IDA-1.4.4); Mon, 2 Aug 1993 15:27:51 -0400
Date: Sat, 31 Jul 93 23:15:35 EDT
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: <926.bill.simpson at um.cc.umich.edu>
To: Neal Castagnoli <Neal_Castagnoli at novell.com>
Cc: ietf at CNRI.Reston.VA.US
Reply-To: bsimpson at morningstar.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
> Or you can call Novell in San Jose (the general number is 408 434 2300).
> In this sense, IPXWAN version II is open, and generally we (meaning myself
> and the designers) actually appreciate comments.
>
> Novell has not released any product including IPXWAN version II yet.
>
Ah, Neal, when I say "published" in the IETF sense, I mean as an RFC.
The problem with ISO standards is that they are published in a book, and
we don't have change control. Note that in another message I pointed
out that RFC-995 doesn't document the current version of ES-IS.
The problem with Novell is that they are published by a corporate entity,
and we don't have change control. This does not mean that Novell is evil,
or that the work is not good work. As you know I've talked extensively to
Michael Allen and others, and they seem to be fine engineers. But the
process for changes is outside the scope of IETF.
In both cases, changes occurred to the specifications, but the IETF was
not notified, and no new RFC was published.
That is why we have "informational" RFCs. They give us information, but
we are warned that it might not be complete or the lastest version. They
are explicitly *not* standards.
(BTW: could you submit the new version of IPX-WAN for publication? Now
would be a good time, since we are getting ready to post IPXCP and CIPX
as proposed standards, and they could be published as a set.)
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27233;
19 Jul 93 11:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27225;
19 Jul 93 11:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05114;
19 Jul 93 11:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27178;
19 Jul 93 11:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27101;
19 Jul 93 11:44 EDT
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa05012;
19 Jul 93 11:44 EDT
Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690)
id AA19023; Mon, 19 Jul 93 08:44:25 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Arlington Hewes <tpcadmin at dbc.mtview.ca.us>
To: Arlington Hewes <tpcadmin at dbc.mtview.ca.us>
Reply-To: tpc-rp at aarnet.edu.au
Subject: An Experiment in remote printing
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_baaaaaaaaa0"
Date: Mon, 19 Jul 1993 08:44:23 -0700
Message-Id: <19022.743096663 at dbc.mtview.ca.us>
X-Orig-Sender: mrose at dbc.mtview.ca.us
------- =_baaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
At the IETF meeting last Friday, I made a presentation on "An Experiment
in Remote Printing". Here is the FAQ on the experiment.
/mtr
------- =_baaaaaaaaa0
Content-Type: multipart/digest; boundary="----- =_baaaaaaaaa1"
------- =_baaaaaaaaa1
To: tpc-rp at aarnet.edu.au
from: Arlington Hewes <tpcadmin at dbc.mtview.ca.us>
Subject: FAQ for "An Experiment in Remote Printing"
Content-Description: An Experiment in Remote Printing
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Date: Mon, 19 Jul 1993 08:39:35 -0700
Message-ID: <18780.743096375 at dbc.mtview.ca.us>
Sender: mrose at dbc.mtview.ca.us
Table of Contents
part type/subtype size description
multipart/mixed 14K An Experiment in Remote Printing
1 multipart/mixed 1943 General Information
1.1 text/plain 431 What is this experiment, anyway?
1.2 text/plain 848 Outreach? What are you really doing?
1.3 text/plain 96 How can I keep informed?
1.4 text/plain 36 By the way, how can I get another copy ...
2 multipart/mixed 7148 How can I send something?
2.1 text/plain 286 What's the simplest way?
2.2 text/plain 710 Fine, what does this mean?
2.3 text/plain 1099 What about the rest of it?
2.4 text/plain 688 Gee, is there global coverage already?
2.5 text/plain 1401 "Cells"?
2.6 text/plain 291 How can I find out if there is access ...
2.7 text/plain 525 Suppose I want to send images instead ...
2.8 text/plain 902 Suppose I want a lot of information on ...
2.9 text/plain 63 Is there software to help me compose ...
3 multipart/mixed 5210 What does it take to run a cell?
3.1 text/plain 275 Suppose I want to operate a remote ...
3.2 text/plain 177 Is there a document describing the ...
3.3 multipart/mixed 2094 Tell me about the policy
3.3.1 text/plain 403 Who sets policy?
3.3.2 text/plain 88 What do Malamud and Rose get out of this?
3.3.3 text/plain 206 What is this policy?
3.3.4 text/plain 494 What about now?
3.3.5 text/plain 313 What about privacy?
3.4 text/plain 232 Who can I contact for administrative ...
3.5 multipart/mixed 1689 Tell me about the connectivity and ...
3.5.1 text/plain 335 If I want to run a remote printer ...
3.5.2 text/plain 396 Is there software available?
3.5.3 text/plain 510 What's in the openly-available software?
4 text/plain 70 Just who is this Arlington Hewes anyway...
------- =_aaaaaaaaaa0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa1"
Content-Description: General Information
------- =_aaaaaaaaaa1
Content-Type: text/plain; charset="us-ascii"
Content-Description: What is this experiment, anyway?
The experiment is a project in outreach: to integrate the e-mail and
facsimile communities.
Many sites cooperatively provide "remote printing" access to the
international telephone network. This allows people to send faxes via
e-mail. The general-purpose Internet e-mail infrastructures takes care
of all the routing, delivering the message to the appropriate remote
printer gateway in a manner totally transparent to the user.
------- =_aaaaaaaaaa1
Content-Type: text/plain; charset="us-ascii"
Content-Description: Outreach? What are you really doing?
We believe that by providing easy access to remote printing recipients,
enterprise-wide access is enhanced, regardless of kind of institution
(e.g., commercial, educational, or government), or the size of
institution (e.g., global, regional, or local). This approach at
outreach allows an organization to make it easier for the "outside
world" to communicate with personnel in the organization who are
users of facsimile but not e-mail, such as the sales person, the
university registrar, or the (elected) official. The ease in which the
Internet mail infrastructure can be used to provide this facility is
(yet) another example of the power of a general-purpose
infrastructure.
Of course, as the experiment progresses, some of the things we'll be
studying are economic and policy models that deal with issues such
as accounting and settlement.
------- =_aaaaaaaaaa1
Content-Type: text/plain; charset="us-ascii"
Content-Description: How can I keep informed?
There's a mailing list.
Send a note to
tpc-rp-request at aarnet.edu.au
and ask to be added.
------- =_aaaaaaaaaa1
Content-Type: text/plain; charset="us-ascii"
Content-Description: By the way, how can I get another copy of this FAQ?
Send mail to tpc-faq at town.hall.org.
------- =_aaaaaaaaaa1--
------- =_aaaaaaaaaa0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa2"
Content-Description: How can I send something?
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: What's the simplest way?
Is this simple enough?
To: remote-printer.Arlington_Hewes/Room_403 at 0.1.5.2.8.6.9.5.1.4.1.tpc.int
This will get automatically routed to a remote printer server, which
will transmit a facsimile to the recipient. When the transmission
completes, a message will be sent back to you!
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: Fine, what does this mean?
Let's look at the strings on either side of the '@'-sign.
The left-hand part identifies the kind of access (remote-printer) along
with the identity of the recipient (Arlington_Hewes/Room_403).
Because some mailers have difficulty dealing with addresses that
contain spaces, etc., you should be very careful as to what characters
you use to identify the recipient. It safest to use upper and lower
case letters, digits, and two special characters ('_' and '/').
When a cover sheet is generated, the '_' will turn into a space and the
'/' will turn into a end-of-line sequence. So, given the address
above, the cover sheet might start with
Please deliver this facsimile to:
Arlington Hewes
Room 403
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: What about the rest of it?
The right-hand part identifies the telephone number of the
remote-printer. It must be an international telephone number.
Telephone numbers are usually written like this:
+code-number
where "code" identifies the country and "number" is the telephone
number within the country, e.g.,
+1-415 968 1052
(For those interested in trivia, the maximum number of digits is 15.)
In order to get the Internet e-mail infrastructure to automatically
route messages, the punctuation characters are stripped out, e.g.,
14159681052
and then the string is inverted and turned into an Internet domain
name, e.g.,
0.1.5.2.8.6.9.5.1.4.1.tpc.int
This approach allows us to map from the Internet naming scheme onto the
entire international telephone network. And, as you might expect, you
can mix remote-printing and e-mail recipients in the same message, e.g.,
To: remote-printer.Arlington_Hewes/Room_403 at 0.1.5.2.8.6.9.5.1.4.1.tpc.int
cc: Marshall Rose <mrose at dbc.mtview.ca.us>
(In fact, the replies generated by the e-mail recipients can even go to
the remote-printing recipients!)
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: Gee, is there global coverage already?
Get real.
The official kick-off of the experiment was 16 July 1993. However, at
present, there is access available for:
- all of Australia
- all of Washington, DC
- most of Silicon Valley
- parts of Riverside
- and all of the University of Michigan
In addition, we expect the following countries to come online later in
the summer of 1993:
- Denmark
- Finland
- Ireland
- Japan
- Sweden
along with several enterprises such as companies and government R&D
centers.
The basic idea is that each participating site registers a "cell"
indicating the portion of the international telephone number space that
they are willing to provide access to.
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: "Cells"?
Well, we call them cells.
The idea is that there are really four kinds of participating sites:
- neighborhood sites
- regional sites
- enterprise sites
- personal sites
A neighborhood site is someone who provides access to any facsimile
machines in its "local calling area". The idea being that metered
access to this area is fairly inexpensive, and the site is willing to
provide access as a part of their community spirit. Access to Silicon
Valley is provided by several neighboord sites.
A regional site is basically just a large neighborhood site, usually
providing access to an entire country or a large part of a country,
such as an area code. The interesting thing to note is that
neighborhood sites may choose to shrink or expand their cell, depending
on factors such as demand and cost.
An enterprise site is a company that provides access solely to its own
facsimile machines. They register exactly those telephone prefixes
which apply to their enterprise. The University of Michigan is an
example of this. Of course, a geographically-disperse enterprise such
as a multi-national company could also do this.
A personal site is someone who provides access to exactly one facsimile
machine, usually one that resides on their desktop. In this case, when
the remote printer server gets the message, it will just deliver it to
the owner of the desktop--via e-mail.
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: How can I find out if there is access to a particular number?
If you're a guru, it's simple; if not, well...
A graphical tool will be available later this summer. For now, there's
a command-line tool available, e.g.,
% rpvalidate +1-415-968-1052
accessible
The section below on "Is there software available?" will tell you where
to find it.
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: Suppose I want to send images instead of text?
Use MIME.
MIME is the Internet-standards track technology for multi-media
messaging. In fact, this FAQ is formatted using MIME.
When remote-printing, at a minimum, the following MIME content types
are supported:
- text/plain
- message/rfc822
- application/postscript
- image/tiff
- multipart
So, you might send something like the following:
To: remote-printer.Arlington_Hewes/Room_403 at 0.1.5.2.8.6.9.5.1.4.1.tpc.int
MIME-Version: 1.0
Content-Type: application/postscript
%!
...
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: Suppose I want a lot of information on the cover sheet?
You want a lot of things don't you.
Anyway, a MIME content-type has been defined for this. It's called
application/remote-printing
Here's an example:
Content-Type: application/remote-printing
Recipient: Marshall Rose
Title: Principal
Organization: Dover Beach Consulting, Inc.
Address: 420 Whisman Court
Mountain View, CA 94043-2186
US
Telephone: +1 415 968 1052
Facsimile: +1 415 968 2510
Originator: John Q. Public
Organization: The Public Domain
Telephone: +1 801 555 1234
Facsimile: +1 801 555 6789
EMail: "John Q. Public" <jpublic at tpd.org>
Any text appearing here would go on the cover-sheet.
This must be the very first content in your MIME message. Also, if you
use this, then the left-hand part of the recipient's address should just
be "remote-printer".
------- =_aaaaaaaaaa2
Content-Type: text/plain; charset="us-ascii"
Content-Description: Is there software to help me compose messages like this?
Yes.
See the section below on "Is there software available?".
------- =_aaaaaaaaaa2--
------- =_aaaaaaaaaa0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa3"
Content-Description: What does it take to run a cell?
------- =_aaaaaaaaaa3
Content-Type: text/plain; charset="us-ascii"
Content-Description: Suppose I want to operate a remote printer server?
You need four things:
- a computer on the IP-connected Internet
- a fax modem and phone line
- fax spooling software
- glue software
You also need to agree to operate the cell in a fashion consistent with
the policies associated with the "tpc.int." domain.
------- =_aaaaaaaaaa3
Content-Type: text/plain; charset="us-ascii"
Content-Description: Is there a document describing the technical details?
Yes.
A document has been submitted to the RFC editor for publication as an
experimental RFC. In the future, there will probably be several
documents, including one on policy.
------- =_aaaaaaaaaa3
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa4"
Content-Description: Tell me about the policy
------- =_aaaaaaaaaa4
Content-Type: text/plain; charset="us-ascii"
Content-Description: Who sets policy?
At present, the policy is set by the two people running the experiment,
Carl Malamud of the Internet Multicasting Service, a non-profit,
organization, and Marshall Rose of Dover Beach Consulting, Inc. (Rose
spends half of his time on openly-available projects, of which this is
one.)
In the near future, an oversight board will be established which will
formulate and publish administrative policies.
------- =_aaaaaaaaaa4
Content-Type: text/plain; charset="us-ascii"
Content-Description: What do Malamud and Rose get out of this?
An indictment by a federal grand jury. Just kidding. Ha, ha.
They're doing research.
------- =_aaaaaaaaaa4
Content-Type: text/plain; charset="us-ascii"
Content-Description: What is this policy?
Ultimately, it's all about establishing these basic principles:
- Functionality
- Fairness
- Cost Recovery
- Performance
- Efficiency
- Security
- Legality
- Extendibility
------- =_aaaaaaaaaa4
Content-Type: text/plain; charset="us-ascii"
Content-Description: What about now?
For now, there's one simple rule:
- it is perfectly acceptable to deny access on the basis of originator
identity, but it is not acceptable to deny access on the basis of
recipient identity
The reason for this is simple: if a site finds that some originator is
acting in an abusive manner, then the site can deny access. But, when
a site registers a cell, it agrees to provide access to every telephone
number in that cell. Of course, it can always register a smaller
cell.
------- =_aaaaaaaaaa4
Content-Type: text/plain; charset="us-ascii"
Content-Description: What about privacy?
There are strict rules as to the kind of auditing information which a
remote printer server may keep. Basically, this information is
necessary for debugging purposes, e.g., if you send a message and don't
get a completion or failure acknowledgement later on, the site
providing access may need to check into it.
------- =_aaaaaaaaaa4--
------- =_aaaaaaaaaa3
Content-Type: text/plain; charset="us-ascii"
Content-Description: Who can I contact for administrative questions?
Arlington Hewes <tpcadmin at dbc.mtview.ca.us>
Mr. Hewes is a busy man, so before sending him a note, please consider
whether the general discussion list (tpc-rp at aarnet.edu.au) mentioned
earlier might not be a more appropriate forum.
------- =_aaaaaaaaaa3
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa5"
Content-Description: Tell me about the connectivity and software requirements
------- =_aaaaaaaaaa5
Content-Type: text/plain; charset="us-ascii"
Content-Description: If I want to run a remote printer server, do I really need an IP-connected machine?
Not really.
Technically, just about any computer on the Internet could run a remote
printer server. However, we recommend that the computer have
IP-connectivity, since this makes it easier to check things out when
there's a problem.
The more important requirement is that you have fax spooling software
available for your computer.
------- =_aaaaaaaaaa5
Content-Type: text/plain; charset="us-ascii"
Content-Description: Is there software available?
Yes.
An openly-available implementation can be found on
site: ftp.ics.uci.edu
area: mrose/tpc
file: rp.tar.Z
be sure to retrieve it in BINARY mode, eh?
In addition, if you're running Innosoft's PMDF software for OpenVMS,
then you can contact them at service at innosoft.com for the details.
If you're a vendor who adds support for remote-printing to your
software, we want to hear from you.
------- =_aaaaaaaaaa5
Content-Type: text/plain; charset="us-ascii"
Content-Description: What's in the openly-available software?
It contains pointers to existing openly-available software along with
some "glue" software for BSD-derived UNIX systems.
For sites that want to run remote printer servers, there is support for
both the openly-available FlexFAX package and the Bristol Group's IsoFax
product.
For sites that want to use remote printing, there are some scripts,
primarily for MH users.
If you are willing to contribute to the openly-available software package
(e.g., if you've written a Mac client), we want to hear from you.
------- =_aaaaaaaaaa5--
------- =_aaaaaaaaaa3--
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-Description: Just who is this Arlington Hewes anyway, and what does TPC stand for?
Go rent the film "The President's Analyst", Paramount Pictures, 1967.
------- =_aaaaaaaaaa0--
------- =_baaaaaaaaa1--
------- =_baaaaaaaaa0--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00547;
23 Jul 93 3:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00543;
23 Jul 93 3:28 EDT
Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa02537; 23 Jul 93 3:28 EDT
Received: by munnari.oz.au (5.83--+1.3.1+0.50)
id AA00870; Fri, 23 Jul 1993 16:19:15 +1000 (from owner-Big-Internet)
Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA00838; Fri, 23 Jul 1993 16:18:41 +1000 (from brian at dxcern.cern.ch)
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA06894; Fri, 23 Jul 1993 08:18:33 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
id AA07375; Fri, 23 Jul 1993 08:18:32 +0200
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brian Carpenter CERN-CN <brian at dxcern.cern.ch>
Message-Id: <9307230618.AA07375 at dxcern.cern.ch>
Subject: Host count query
To:
Date: Fri, 23 Jul 1993 08:18:31 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 457
Hello,
Can anybody help us trace several mysterious incidents on
our main external gateway recently? Has anybody been running
automatic host counts of some kind in the last few days
(during European night hours) that might account for floods
of ARPs sweeping across our whole Class B network?
Thanks for any help, sorry to use this list but where better?
Regards,
Brian Carpenter CERN, brian at dxcern.cern.ch
voice +41 22 767 4967, fax +41 22 767 7155
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05897;
23 Jul 93 10:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05890;
23 Jul 93 10:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18789;
23 Jul 93 10:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05863;
23 Jul 93 10:44 EDT
Received: from dxmint.cern.ch by IETF.CNRI.Reston.VA.US id aa05779;
23 Jul 93 10:41 EDT
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
id AA08214; Fri, 23 Jul 1993 16:42:12 +0200
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3)
id AA29610; Fri, 23 Jul 1993 16:42:11 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brian Carpenter CERN-CN <brian at dxcern.cern.ch>
Message-Id: <9307231442.AA29610 at dxcern.cern.ch>
Subject: Host count query
To:
Date: Fri, 23 Jul 1993 16:42:10 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 531
Sorry to people who have already seen this on another list,
but we are troubled...
Can anybody help us trace several mysterious incidents on
our main external gateway recently? Has anybody been running
automatic host counts of some kind in the last few days
(during European night hours) that might account for floods
of ARPs sweeping across our whole Class B network?
Thanks, and apologies for this use of the list.
Regards,
Brian Carpenter CERN, brian at dxcern.cern.ch
voice +41 22 767 4967, fax +41 22 767 7155
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11864;
1 Aug 93 0:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11857;
1 Aug 93 0:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27246;
1 Aug 93 0:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11839;
1 Aug 93 0:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11811;
1 Aug 93 0:21 EDT
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa27189;
1 Aug 93 0:21 EDT
Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690)
id AA00153; Sat, 31 Jul 93 21:20:48 -0700
To: tpc-rp at aarnet.edu.au
Cc: Arlington Hewes <tpcadmin at dbc.mtview.ca.us>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Arlington Hewes <tpcadmin at dbc.mtview.ca.us>
Subject: Announcement -- BOF at INTEROP August 93
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 31 Jul 1993 21:20:46 -0700
Message-Id: <151.744178846 at dbc.mtview.ca.us>
X-Orig-Sender: mrose at dbc.mtview.ca.us
If you are interested in remote printing, or tpc.int in general, you
will want to attend this BOF. Carl and Marshall will be discussing,
for the first time in public, how a site can use remote printing as
profit center.
Title: An Experiment in Remote "Printing" on Global Facsimile Devices
When: Wednesday August 25th, 7:30-9:30pm
Where: Marriott hotel in the Presidio Room
Entry: Anyone registered for INTEROP, plus anyone can just walk on in...
Hosts: Carl Malamud, Internet Multicasting Service
Marshall T. Rose, Dover Beach Consulting, Inc.
This BOF describes an experiment in remote printing that allows any
user on the global Internet computer network to "print" documents
on G3-compatible facsimile devices connected to the telephone
network. The BOF describes how the experiment works, how you can
take part, and how many countries all over the world are reachable
from this new Internet service.
#######
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14371;
1 Aug 93 11:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14367;
1 Aug 93 11:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08355;
1 Aug 93 11:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14346;
1 Aug 93 11:01 EDT
Received: from corp.timeplex.com by IETF.CNRI.Reston.VA.US id aa14342;
1 Aug 93 10:59 EDT
Return-receipt-to: MALIS at corp.timeplex.com
Registered-mail-reply-requested-by: MALIS at corp.timeplex.com
Received: from mr.timeplex.com by sys30.timeplex.com (PMDF #2740 ) id
<01H188YADOQE8WWT4V at sys30.timeplex.com>; Sun, 1 Aug 1993 11:02:50 EDT
Received: with PMDF-MR; Sun, 1 Aug 1993 11:02:42 EDT
Date: 01 Aug 1993 11:04:50 -0400 (EDT)
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Malis_A <MALIS at corp.timeplex.com>
Subject: RFC 1356 (IP/X.25) implementation experience
To: IETF <ietf at ietf.nri.reston.va.us>,
IPLPDN Working Group <iplpdn at ietf.nri.reston.va.us>,
TCP-IP <tcp-ip at nic.ddn.mil>
Message-id: <01H188YAB9X08WWT4V at mr.timeplex.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
UA-content-id: RFC 1356 (IP/X.25) implementation experience
X-Hop-count: 1
A1-type: MAIL
To : IETF,IPLPDN Working Group,TCP-IP
Date: 1-AUG-1993 11:04:50.00
In order to advance RFC 1356 (Multiprotocol Interconnect over X.25) from
proposed to draft standard, I am soliciting implementation and interoperability
experience from the Internet community. Any interoperability experience with
RFC 877 would also be appreciated. Please mail replies to malis_a at timeplex.com.
Thanks,
Andy
____________________________________________________________________________
Andrew G. Malis malis_a at timeplex.com Ph: +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 aa02583;
2 Aug 93 10:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02574;
2 Aug 93 10:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12331;
2 Aug 93 10:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02535;
2 Aug 93 10:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02460;
2 Aug 93 10:39 EDT
Received: from relay.surfnet.nl by CNRI.Reston.VA.US id aa12238;
2 Aug 93 10:39 EDT
Received: from erasmus.rare.nl by relay.surfnet.nl with SMTP (PP)
id <13311-0 at relay.surfnet.nl>; Mon, 2 Aug 1993 16:39:37 +0200
Received: from [192.87.30.20] (macewan.rare.nl) by erasmus.rare.nl (5.65c/4.31)
with SMTP id AA29459; Mon, 2 Aug 1993 16:39:28 +0200
Message-Id: <199308021439.AA29459 at erasmus.rare.nl>
X-Mail-Interface: Macintosh Eudora (Ac.Comp.Centr.Utrecht)
Date: Mon, 2 Aug 1993 15:53:03 +0100
To: M2107 at eurokom.ie, tcp-ip at nic.ddn.mil, iepg at nri.reston.va.us,
ietf at nri.reston.va.us, alljnt at jnt.ac.uk, ccirn at lbl.gov,
apccirn at aarnet.edu.au, isoc-dist at nri.reston.va.us,
ifip65-prog at ics.uci.edu, mhsnews at ics.uci.edu, ifip-gtwy at ics.uci.edu,
newsletters at rare.nl, ripe at ripe.net, wg-all at rare.nl, coa at rare.no
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bersee at rare.nl
Subject: Call for Papers - CNRE, 2nd issue
C A L L F O R P A P E R S
- C O N T I N U O U S -
COMPUTER NETWORKS FOR RESEARCH IN EUROPE is a new, joint publication
by RARE and EARN. It is published as a quarterly supplement to
the Elsevier North-Holland journal "Computer Networks and ISDN
Systems".
The editorial board consists of high-level representatives from
national and international research networking organizations and is
chaired by Tomaz Kalin, RARE Secretary-General and Paul Bryant, EARN
Secretary-General.
The colofon reads as follows:
"Scope
COMPUTER NETWORKS for RESEARCH in EUROPE is a publication vehicle
for coverage of topics of interest to those involved in the area.
The audience includes staff from networking service providers of all
sizes as well as application developers, policy makers and
representatives of funding bodies, advanced user groups and
standards organizations.
Subject coverage
Material on aspects of design, implementation, use and management of
computer networks for reseach and education. Specifically included are
non-technical topics related to economic, legal and regulatory issues
and social impact of using network services in the research and
education community.
In addition, both RARE (Reseaux Associes pour la Recherche Europeenne)
and EARN (European Academic and Research Network) report on
developments in their organizations.
Types of contributions considered
The purpose of the journal is to publish complete papers covering a
specific topic or project of practical use to interested readers.
The journal is meant to be a source of information on all aspects
of computer networks for research and education and will also include
news items in addition to the regular contributions discussed above."
- Submission of material -
Preferred format for submitting papers: RTF or ascii text
(+ separate graphs and tables). All material will be formatted in a
standard "Elsevier" layout. Preferred length: around 3500 words.
For more detailed information on submission procedures send a message
to cnre at rare.nl.
- Review procedure -
The editorial board will review submitted material for publication
or appoint expert reviewers to do the review on its behalf.
DEADLINE NEXT ISSUE: SEPTEMBER 1st, 1993
If you intend to submit a paper for an issue later this year
(next deadline November 1st) we would appreciate to be informed as
early as possible.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03024;
2 Aug 93 10:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03017;
2 Aug 93 10:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12853;
2 Aug 93 10:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02997;
2 Aug 93 10:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02954;
2 Aug 93 10:55 EDT
Received: from norge.unet.umn.edu by CNRI.Reston.VA.US id aa12795;
2 Aug 93 10:55 EDT
Received: by norge.unet.umn.edu (5.65c)
id AA06365; Mon, 2 Aug 1993 09:55:54 -0500
Date: Mon, 2 Aug 1993 09:55:54 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Craig A. Finseth" <fin at unet.umn.edu>
Message-Id: <199308021455.AA06365 at norge.unet.umn.edu>
To: wright at lbl.gov
Cc: Craig.A.Finseth-1 at umn.edu, henryc at oar.net, desjardi at boa.gsfc.nasa.gov,
ietf at CNRI.Reston.VA.US, tuba at lanl.gov
In-Reply-To: Russ Wright's message of Sat, 31 Jul 93 10:53:21 PDT <9307311753.AA03650 at lbl.gov>
Subject: PhaseV or Re: Last Call: Use of ISO CLNP in TUBA
Reply-To: Craig.A.Finseth-1 at umn.edu
>According to our DEC network engineer, DECNet Phave V = Phas IV +
>TCP/IP + CLNP, with about 90% of his users going to TCP/IP.
Translation: YOUR site doesn't care much about PhaseV. This is OK
(although, you do have 10% of your people to worry about. Ah, just ignore
them when they ask for CLNP connectivity ;-) ).
Sorry, by "our" I meant the one local to Minnesota. He is a DEC
employee. I was not talking about the local DECNET expert at our
organization.
Craig
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04081;
2 Aug 93 11:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14042;
2 Aug 93 11:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04069;
2 Aug 93 11:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03704;
2 Aug 93 11:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.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: ID ACTION:draft-ietf-pppext-lcp-main-00.txt
Date: Mon, 02 Aug 93 11:19:12 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308021119.aa03704 at IETF.CNRI.Reston.VA.US>
--NextPart
Note: The previous announcement for this Internet-Draft contained
an incorrect file name.
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Point-to-Point Protocol (PPP)
Author(s) : W. Simpson
Filename : draft-ietf-pppext-lcp-main-00.txt
Pages : 60
The Point-to-Point Protocol (PPP) provides a method for transmitting
multi-protocol datagrams over point-to-point links. PPP is comprised of
three main components: 1. A method for encapsulating multi-protocol
datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection. 3. A family of Network Control
Protocols (NCPs) for establishing and configuring different network-layer
protocols. This document defines the PPP organization and methodology,
together with the PPP Link Control Protocol (LCP), an extensible option
negotiation protocol which is able to negotiate a rich assortment of
configuration parameters and provides additional management functions.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-lcp-main-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-lcp-main-00.txt".
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-lcp-main-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-lcp-main-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04714;
2 Aug 93 11:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14859;
2 Aug 93 11:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04688;
2 Aug 93 11:45 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04633;
2 Aug 93 11:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rem-conf at es.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: ID ACTION:draft-ietf-avt-rtp-02.txt
Date: Mon, 02 Aug 93 11:42:25 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308021142.aa04633 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 Audio/Video Transport Working
Group of the IETF.
Title : RTP: A Real-Time Transport Protocol
Author(s) : H. Schulzrinne, S. Casner
Filename : draft-ietf-avt-rtp-02.txt
Pages : 28
This draft describes a real-time transport protocol (RTP) suitable for the
network transport of real-time data, such as audio, video or simulation
data for both multicast and unicast transport services. The data transport
is enhanced by a control protocol (RTCP) designed to provide minimal
control and identification functionality particularly in multicast
networks. RTP and RTCP are designed to be independent of the underlying
transport and network layers. The protocol supports the use of RTP-level
translators and bridges. Within multicast associations, sites can direct
control messages to individual sites.
This specification is a product of the Audio-Video Transport working group
within the Internet Engineering Task Force. Comments are solicited and
should be addressed to the working group's mailing list at rem-conf at es.net
and/or the authors.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-avt-rtp-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-avt-rtp-02.txt".
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-avt-rtp-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-rtp-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04716;
2 Aug 93 11:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14860;
2 Aug 93 11:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04690;
2 Aug 93 11:45 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04581;
2 Aug 93 11:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rem-conf at es.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: ID ACTION:draft-ietf-avt-profile-01.txt
Date: Mon, 02 Aug 93 11:41:51 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308021141.aa04581 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 Audio/Video Transport Working
Group of the IETF.
Title : Sample Profile for the Use of RTP for Audio and Video
Conferences with Minimal Control
Author(s) : H. Schulzrinne
Filename : draft-ietf-avt-profile-01.txt
Pages : 5
This note describes a profile for the use of the real-time transport
protocol (RTP) and the associated control protocol, RTCP, within audio and
video multiparticipant conferences with minimal control. It provides
interpretations of generic fields within the RTP specification suitable for
audio and video conferences. In particular, this document defines a set
of default mappings from content index to encodings.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-avt-profile-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-avt-profile-01.txt".
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-avt-profile-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-profile-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04813;
2 Aug 93 11:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14958;
2 Aug 93 11:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04800;
2 Aug 93 11:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04553;
2 Aug 93 11:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rem-conf at es.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: ID ACTION:draft-ietf-avt-encodings-01.txt
Date: Mon, 02 Aug 93 11:41:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308021141.aa04553 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 Audio/Video Transport Working
Group of the IETF.
Title : Media Encodings
Author(s) : H. Schulzrinne
Filename : draft-ietf-avt-encodings-01.txt
Pages : 7
This document describes a possible structure of the media content for audio
and video for Internet applications. The definitions are independent of
the particular transport mechanism used. The descriptions provide pointers
to reference implementations and the detailed standards. This document is
meant as an aid for implementors of audio, video and other real-time
multimedia applications.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-avt-encodings-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-avt-encodings-01.txt".
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="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-avt-encodings-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-encodings-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab07886;
2 Aug 93 13:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07878;
2 Aug 93 13:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20318;
2 Aug 93 13:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07860;
2 Aug 93 13:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07798;
2 Aug 93 13:54 EDT
Received: from sumax.seattleu.edu by CNRI.Reston.VA.US id aa20205;
2 Aug 93 13:54 EDT
Received: by sumax.seattleu.edu id AA01680
(5.65a/IDA-1.4.2 for IETF at CNRI.Reston.VA.US); Mon, 2 Aug 93 11:02:45 -0700
Date: Mon, 2 Aug 1993 10:59:45 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Cowdin <bcowdin at seattleu.edu>
Subject: Please unsubscribe me
To: IETF at CNRI.Reston.VA.US
Cc: bcowdin at seattleu.edu
Message-Id: <Pine.3.03.9308021045.A31238-7100000 at sumax.seattleu.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Dear Sir;
At this time I wish to unsubscribe from the IETF listing.
Thank you
Bob Cowdin
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11963;
2 Aug 93 17:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11955;
2 Aug 93 17:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27337;
2 Aug 93 17:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11943;
2 Aug 93 17:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11896;
2 Aug 93 17:09 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa27181;
2 Aug 93 17:09 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA11946; Mon, 2 Aug 93 17:10:07 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA09967; Mon, 2 Aug 93 17:12:24 EDT
Message-Id: <9308022112.AA09967 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: bsimpson at morningstar.com
Cc: Neal Castagnoli <Neal_Castagnoli at novell.com>, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Sat, 31 Jul 93 23:15:35 EDT."
<926.bill.simpson at um.cc.umich.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 02 Aug 93 17:12:24 -0400
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>
I think one of the problems we're skirting round here is that there
is no real way for a base level document to be fast-tracked through
the standards process- this causes problems when an author is willing
to cede change-control for future versions of the spec, but not for the
original version, where there may be a large installed base already in
place.
The problems with HTML at the Amsterdam meeting are a good example of
this point. Informational and Experimental don't really fit- ideally
there would be some way to inject a document at the IESG level, probably
with an extended last call.
Simon
----
Hackers Local 42- National Union of Computer Operatives, Chapel Hill section
------------------------------------------------------------------------------
Tar Heel Information Services - Nothing but net! | WAIS/Z39.50 spoken here
CLNP - The C is for Clue | DoD #612 | Tel: +1-919-962-9107
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15750;
2 Aug 93 18:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15743;
2 Aug 93 18:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29692;
2 Aug 93 18:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15623;
2 Aug 93 18:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14950;
2 Aug 93 18:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29629;
2 Aug 93 18:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14940;
2 Aug 93 18:32 EDT
To: bsimpson at morningstar.com
cc: Neal Castagnoli <Neal_Castagnoli at novell.com>, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Sat, 31 Jul 93 23:15:35 EDT."
<926.bill.simpson at um.cc.umich.edu>
Date: Mon, 02 Aug 93 18:32:46 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9308021832.aa14940 at IETF.CNRI.Reston.VA.US>
Just a short note about RFCs and externally produced standards.
One of the purposes of introducing externally produced standards
in RFCs was to have a well-defined version of the external
standard to associate with any applicability statements developed
or other dependent technical specifications. Even if the external
standard evolves away from the RFC, the IETF protocols can un-
ambiguously reference an on-line accessible document.
This practice still leaves one with the problem of deciding what
to do when the external specification changes - pragmatics may
well dictate that a new RFC be issued, for instance.
Vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16524;
2 Aug 93 19:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16517;
2 Aug 93 19:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01204;
2 Aug 93 19:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16506;
2 Aug 93 19:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16455;
2 Aug 93 19:12 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa01158; 2 Aug 93 19:12 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA08653; Mon, 2 Aug 93 16:12:38 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA00229; Mon, 2 Aug 93 16:12:35 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9308022312.AA00229 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: bsimpson at morningstar.com
Date: Mon, 2 Aug 93 16:12:32 PDT
Cc: Neal_Castagnoli at novell.com, ietf at CNRI.Reston.VA.US,
eva at hpindda.cup.hp.com
In-Reply-To: <926.bill.simpson at um.cc.umich.edu>; from "William Allen Simpson" at Jul 31, 93 11:15 pm
Mailer: Elm [revision: 64.9]
There are standards that are proprietary standards where a specification
is maintained by some body and licensed for use by others. There are standards
which are open standards which are maintained by a recognized standards
development organization. The latter are not proprietary standards. The ISO
CLNP standard is not a proprietary standard and I am surprised that people
are referring to it as proprietary. If the RFC which points to the standard
maintains the reference pointers appropriately (and maintenance of an RFC
is only a proper and necessary feature of an RFC) the maintenance of the
RFC should include keeping appropriate pointers up to date, whether they
be other RFCs or documents produced by other standards bodies. Not recognizing
standards produced by other standards bodies and implying that the only
standards that are recognized are those which are under the control of
IETF and published in an RFC was probably not the original intent of this
body. I am really puzzled about the classification of International Standards
as proprietary and I am puzzled that people seem to think that the
Internet community cannot point to an International Standard as a basis
for an RFC. A simple errata process or defect report process for maintenance
of RFCs is probably all that is needed to make sure the maintenance of RFCs
takes place and pointers are updated as required. Any time standards are
cross-referenced this type of process needs to take place. Avoiding the
issue by not cross-referencing existing International Standards does not
seem to me to be the proper solution to this situation.
Eva
> >
> Ah, Neal, when I say "published" in the IETF sense, I mean as an RFC.
>
> The problem with ISO standards is that they are published in a book, and
> we don't have change control. Note that in another message I pointed
> out that RFC-995 doesn't document the current version of ES-IS.
>
> The problem with Novell is that they are published by a corporate entity,
> and we don't have change control. This does not mean that Novell is evil,
> or that the work is not good work. As you know I've talked extensively to
> Michael Allen and others, and they seem to be fine engineers. But the
> process for changes is outside the scope of IETF.
>
> In both cases, changes occurred to the specifications, but the IETF was
> not notified, and no new RFC was published.
>
> That is why we have "informational" RFCs. They give us information, but
> we are warned that it might not be complete or the lastest version. They
> are explicitly *not* standards.
>
.
.
>
> Bill.Simpson at um.cc.umich.edu
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16915;
2 Aug 93 19:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16908;
2 Aug 93 19:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02498;
2 Aug 93 19:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16881;
2 Aug 93 19:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16857;
2 Aug 93 19:55 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa02478;
2 Aug 93 19:55 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA22707; Mon, 2 Aug 93 16:49:58 -0700
Message-Id: <9308022349.AA22707 at Mordor.Stanford.EDU>
To: Eva Kuiper <eva at hpindda.cup.hp.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Mon, 02 Aug 93 16:12:32 -0700. <9308022312.AA00229 at hpindda.cup.hp.com>
Date: Mon, 02 Aug 93 16:49:57 -0700
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>
X-Mts: smtp
Eva,
---- Included message:
The ISO
CLNP standard is not a proprietary standard and I am surprised that people
are referring to it as proprietary. If the RFC which points to the standard
I don't believe Bill used that term. He said that the IETF did not have
change control. There is a difference.
Whether the IETF NEEDS change control depends upon the way the spec is
being used. For example, we do just fine not having change control
to Ethernet. Whether we need change control for CLNP is a point of
current debate. Certainly, there is a large constituency that believes
we do.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17255;
2 Aug 93 20:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17248;
2 Aug 93 20:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03538;
2 Aug 93 20:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17238;
2 Aug 93 20:52 EDT
Received: from eagle.nersc.gov by IETF.CNRI.Reston.VA.US id aa17215;
2 Aug 93 20:50 EDT
Date: Mon, 2 Aug 1993 17:51:24 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Hain <ALH at eagle.es.net>
Message-Id: <930802175124.439 at EAGLE.ES.NET>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: ietf at IETF.CNRI.Reston.VA.US
X-Vmsmail-To: SMTP%"ietf at ietf.nri.reston.va.us"
Dave,
It is not clear that a 'large constituency' belives we do, so much as a
'vocal constituency'. The IETF does not NEED change control for anything
more than a justification to block progression of work on the RFC track.
Several people have pointed out external references (ethernet, fddi, etc...)
that the IETF has no change control over. There have also been discussions
about what the REAL customer wants here, and what I see is they want to
keep running their existing applications. The TUBA effort is an attempt to
do exactly that with a minimum of disruption.
The TUBA effort should be allowed to progress on the basis that it has met
the established requirements that any proposal needs to. It should not be
blocked because a vocal contingent keeps throwing out smoke screens.
Tony
=========================================================================
Eva,
---- Included message:
The ISO
CLNP standard is not a proprietary standard and I am surprised that people
are referring to it as proprietary. If the RFC which points to the standard
I don't believe Bill used that term. He said that the IETF did not have
change control. There is a difference.
Whether the IETF NEEDS change control depends upon the way the spec is
being used. For example, we do just fine not having change control
to Ethernet. Whether we need change control for CLNP is a point of
current debate. Certainly, there is a large constituency that believes
we do.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17363;
2 Aug 93 21:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17356;
2 Aug 93 21:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03794;
2 Aug 93 21:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17340;
2 Aug 93 21:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17312;
2 Aug 93 21:01 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa03774; 2 Aug 93 21:01 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA10972; Mon, 2 Aug 93 18:02:06 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA03611; Mon, 2 Aug 93 18:02:04 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9308030102.AA03611 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: dcrocker at mordor.stanford.edu
Date: Mon, 2 Aug 93 18:02:02 PDT
Cc: ietf at CNRI.Reston.VA.US, eva at hpindda.cup.hp.com
In-Reply-To: <9308022349.AA22707 at Mordor.Stanford.EDU>; from "Dave Crocker" at Aug 02, 93 4:49 pm
Mailer: Elm [revision: 64.9]
Dave,
But Bill did say that. He stated:
'However, there is another issue: change control. I don't think that
anything from the TUBA WG should be published by the IETF except as
"informational", just as any other proprietary protocol.'
Which was the first time in my life I had heard a de jure standard referred
to as proprietary.
I do not really see that there is a problem with pointing to a known stable
standard and actively working as a team to grow this standard. Where the
change control is done is really not going to change the growth or
usefulness of the standard. It also does not prevent incorporation of
extensions which can be added into the standard as part of this process.
Working with the extensions first, prototyping them, and then adding them
to the ISO CLNP standard does not really seem to me to be such a difficult
path to follow. The workers on both sides (it is the same people, after all!)
seems to think that this will work. Why are we assuming from the beginning
that it won't work instead of trying to achieve a harmonized process of
working together? We seem to keep revisiting this issue over and over
instead of accepting that it already works this way. In the meantime, this
process is what has been followed informally for a long time and what you
have coming out now has incorporated ideas from IETF already. It is already
working! What counts is getting the job done, not whose name is on it.
Eva
>
> Eva,
>
> ---- Included message:
>
> The ISO
> CLNP standard is not a proprietary standard and I am surprised that people
> are referring to it as proprietary. If the RFC which points to the standard
>
> I don't believe Bill used that term. He said that the IETF did not have
> change control. There is a difference.
>
> Whether the IETF NEEDS change control depends upon the way the spec is
> being used. For example, we do just fine not having change control
> to Ethernet. Whether we need change control for CLNP is a point of
> current debate. Certainly, there is a large constituency that believes
> we do.
>
> d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17490;
2 Aug 93 21:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17483;
2 Aug 93 21:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03985;
2 Aug 93 21:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17473;
2 Aug 93 21:11 EDT
Received: from Mordor.Stanford.EDU by IETF.CNRI.Reston.VA.US id aa17427;
2 Aug 93 21:09 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA23775; Mon, 2 Aug 93 18:10:38 -0700
Message-Id: <9308030110.AA23775 at Mordor.Stanford.EDU>
To: Tony Hain <ALH at eagle.es.net>
Cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Mon, 02 Aug 93 17:51:24 -0700. <930802175124.439 at EAGLE.ES.NET>
Date: Mon, 02 Aug 93 18:10:37 -0700
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>
X-Mts: smtp
Tony,
---- Included message:
It is not clear that a 'large constituency' belives we do, so much as a
It is quite clear, to ME, that there is a "substantial" and credible
constituency having this concern. It has been raised and discussed
repeatedly. What has, perhaps, NOT been discussed sufficiently are
the precise circumstances and/or limits to this requirement. (I.e.,
when do we REALLY need it and are there any modified forms of control
that would suffice.)
'vocal constituency'. The IETF does not NEED change control for anything
more than a justification to block progression of work on the RFC track.
Surely you don't find language and views like this helpful? For myself,
I find most of the players in this piece of theatre, called IPng, to
be worthy of much more respect that that. Even the turkeys that don't
agree with me... (I don't use smiley faces, but you can assume that
one would be here, if I did...)
Several people have pointed out external references (ethernet, fddi, etc...
)
that the IETF has no change control over. There have also been discussions
Yes, but we don't MODIFY those technologies, nor are they are they
core of our work.
about what the REAL customer wants here, and what I see is they want to
keep running their existing applications. The TUBA effort is an attempt to
do exactly that with a minimum of disruption.
I don't recall any deprecation of the TUBA effort to be part of this
thread.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17905;
2 Aug 93 21:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17898;
2 Aug 93 21:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04953;
2 Aug 93 21:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17877;
2 Aug 93 21:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17855;
2 Aug 93 21:50 EDT
Received: from wizard.gsfc.nasa.gov by CNRI.Reston.VA.US id aa04908;
2 Aug 93 21:50 EDT
Received: by wizard.gsfc.nasa.gov (5.65/1.35)
id AA07773; Mon, 2 Aug 93 21:43:29 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Fink <bill at wizard.gsfc.nasa.gov>
Message-Id: <9308030143.AA07773 at wizard.gsfc.nasa.gov>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Date: Mon, 2 Aug 1993 21:43:28 -0400 (EDT)
Cc: eva at hpindda.cup.hp.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <9308022349.AA22707 at Mordor.Stanford.EDU> from "Dave Crocker" at Aug 2, 93 04:49:57 pm
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1842
> I don't believe Bill used that term. He said that the IETF did not have
> change control. There is a difference.
>
> Whether the IETF NEEDS change control depends upon the way the spec is
> being used. For example, we do just fine not having change control
> to Ethernet. Whether we need change control for CLNP is a point of
> current debate. Certainly, there is a large constituency that believes
> we do.
>
> d/
I for one think there is a major difference between the specs for
Ethernet vs CLNP. Ethernet is below the internet layer and therefore
the IETF isn't concerned with its specification that much except for
interfacing issues like IP over Ethernet and MIB specifications.
Insofar as TUBA is just an interface specification detailing how
to run TCP over CLNP, I don't see that much of a problem with just
referencing an OSI document, although it would certainly still be
desirable to have the documents available on-line. However, to the
extent that TUBA wants to be considered as a serious IPng candidate,
then it becomes *the* internet layer of the future, and as such I
feel very strongly that the IETF must have full change control, with
all relevant primary and supporting documents available on-line as
normal RFCs.
It would be helpful to have a clear statement from the TUBA folks
as to what the exact intent of the TUBA spec is. If it's just an
interface specification, then I doubt there's as much controversy over
that. If it's an IPng candidate, then it needs to be considered
much more carefully. If, as I suspect, it's some of both, it might
be useful to come up with some way of separating the two aspects,
like having a clean and distinct "TCP Over CLNP" interface RFC which
doesn't even mention any IPng issues, and keeping the TUBA/IPng parts
as IDs or experimental or prototype RFCs.
-Bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18138;
2 Aug 93 22:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18131;
2 Aug 93 22:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05351;
2 Aug 93 22:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18110;
2 Aug 93 22:04 EDT
Received: from umd5.umd.edu by IETF.CNRI.Reston.VA.US id aa18088;
2 Aug 93 22:03 EDT
Received: by umd5.umd.edu id <AA11985 at umd5.umd.edu>; Mon, 2 Aug 93 22:03:41 -0400
Message-Id: <9308030203.AA11985 at umd5.umd.edu>
To: Tony Hain <ALH at eagle.es.net>
Cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Mon, 02 Aug 93 17:51:24 -0700.
<930802175124.439 at EAGLE.ES.NET>
Date: Mon, 02 Aug 93 22:03:37 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike StJohns <stjohns at umd5.umd.edu>
X-Mts: smtp
Tony -
The requirement for change control on something we plan to change is
nothing new...
If we (or rather TUBA) wants to use CLNP (*and* all the applicable OSI
protocols and profiles) *exactly* as OSI has defined it - then change
control is not necessary - it can be referenced as an external
protocol. Dave's point about Ethernet is exactly on the mark -- we
neither modify the basic protocol nor use it in an incompatible way.
ASN.1 is another example of an 'external' definition - we use a subset
of ASN.1 for SNMP which is fully compatible with OSI compliant
products.
TUBA could be considered by the IETF under those conditions -- but is
TUBA willing to represent it will never want to change CLNP?
Mutterings about OSIEXT at the last IETF lead me to believe any
statement that "we'll never want to modify CLNP" is delusional at
best. One possibility is to define our own OSI profile ala GOSIP or
UK-GOSIP for CLNP -- *ugh* - but at least its within the OSI standards
realm. I'm not sure even this would give us the degree of
flexibility we need for IPng - it might, but are we willing to bet on
this?
TUBA has a lot going for it - primarily most of its already written.
TUBA also has large amounts of baggage associated with it. This
doesn't have to be a show stopper, but it has to be handled and not
swept under the rug.
By the way, can anyone tell me the "official" relationship between the
Multipeer/Multicast Consortium and OSI? I just re-read the consortia
application and if this is the "official" OSI multicast group we may
have a real problem.
Later, Mike
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21089;
2 Aug 93 22:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21073;
2 Aug 93 22:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06245;
2 Aug 93 22:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20589;
2 Aug 93 22:53 EDT
Received: from GINGER.LCS.MIT.EDU by IETF.CNRI.Reston.VA.US id aa19761;
2 Aug 93 22:52 EDT
Received: by ginger.lcs.mit.edu
id AA15467; Mon, 2 Aug 93 22:52:48 -0400
Date: Mon, 2 Aug 93 22:52:48 -0400
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: <9308030252.AA15467 at ginger.lcs.mit.edu>
To: ALH at eagle.es.net, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
The IETF does not NEED change control for anything more than a
justification to block progression of work on the RFC track.
This is an outrageous and infamous charge.
To speak to the substantial part first (i.e. the claim that the IETF has no
legitimate use for change control), it's one thing to use an external standard
for something peripherally related to what the IETF does, which is
internetworking. The examples you give, "(ethernet, fddi, etc...)" are lower
layers which are not inextricably related to what we do. You could even make a
case that we could use applications from outside the IETF with little harm.
However, it is simply incomprehensible to say that the single standard which is
the most central to this organization's purpose, i.e. to create a working
internet, does not need to be under this organization's control. The only ways
in which it would make sense is either i) you view the specification as
perfect, needing no change, or ii) you think there is some good reason to
shackle the organization by taking away from it control of the key component of
what it is trying to build.
To speak to your implicit charge that to express desire for change control over
IETF core standards is to be motivated by a desire to block progression of
certain work, I am utterly incensed. You're drawing conclusions about the
motivations of many people, who may or may not be acting for the reason you
mention. You're firing a shotgun into a crowd, and innocents are being hit.
Those who are will be extremely insulted, and rightly so. You owe them all an
apology.
No doubt, for some there is a mix of legitimate concern, and calculation on the
behalf of different things that they favor. Even for those who do have mixed
motives, an entirely human condition, this should not enter into it. The
question should be "is this reasonable on its own merits". Is every law passed
by legislators who were not all thinking solely of the merits of that law for
the community at large, by definition a bad law? However, to start questioning
motivations is to go down the slope into disaster, for once we start *everyone*
is going to come under attack, *including you*.
The TUBA effort should be allowed to progress on the basis that it has met
the established requirements that any proposal needs to. It should not be
blocked because a vocal contingent keeps throwing out smoke screens.
I went back along the message track from this afternoon that got us to this
point, and I'm appalled. A fairly academic discussion of use of outside
standards was going on, with *no mention whatsoever of delaying anything to do
with Tuba*. Would you care to share with us what led you to the apparent
conclusion that some hold was being contemplated?
This whole episode is putrid and repellent. If we are to be sentenced to
enduring this sort of thing as long as we are trying to integrate the ISO and
TCP/IP communities, I for one am ready to give up on that goal. There are real,
major, technical problems out there, and I want to spend my time on them, not
this drivel.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03659;
3 Aug 93 9:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03652;
3 Aug 93 9:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id bh03745;
3 Aug 93 9:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00850;
3 Aug 93 7:01 EDT
Received: from mcigateway.mcimail.com by IETF.CNRI.Reston.VA.US id aa00793;
3 Aug 93 6:56 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa13119;
3 Aug 93 10:51 GMT
Date: Tue, 3 Aug 93 10:56 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: Tony Hain <ALH at eagle.es.net>
To: ietf <ietf at IETF.CNRI.Reston.VA.US>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Message-Id: <00930803105600/0003858921NA1EM at mcimail.com>
Tony Hain said:
>There have also been discussions about what the REAL customer wants here,
>and what I see is they want to keep running their existing applications.
>The TUBA effort is an attempt to do exactly that with a minimum of
>disruption.
In someelse's message a few days ago a point was made that CLNP filters on
host, whereas IPv4 filters on network or host or port or any combination.
WE USE FILTERS HERE! They are admin pains, but in some cases real
important. In some cases a single filter insures that traffic for one plant
routes directly to corporate instead of through another plant (even when the
'cost' of the plant-plant-corp connection is 'cheaper'). This single filter
is controlling a few hundred device's traffic. If we have to use a few
hundred filters instead....
So filters would be one area where you would have to make changes to CLNP.
Bill Fink said:
>Insofar as TUBA is just an interface specification detailing how
>to run TCP over CLNP, I don't see that much of a problem with just
>referencing an OSI document, although it would certainly still be
>desirable to have the documents available on-line.
Regardless of TUBA's intend as an interface spec or IPng, CLNP documentation
would have to be online via anonymous FTP. Too many people doing support
work will have too many questions to answer to say 'go buy the OSI
documentation on this'. As you may or may not recall, I burned myself here
by using subnet 0. I had to read a number of RFCs, cut and paste them into
documents for my management to explain what I did wrong to get the resourses
to correct my error. So too CLNP must be in online form.
This is much different, say from my WG's reference to IBM 3270 documentation
for TN3270E. Any support person having problems with TN3270E will be
working directly with their VTAM support person who has the pertinent IBM
manuals. Also these same IBM support people tend to have IBMLINK access
where they can get much of the info in electronic for for inclusion in any
internal document.
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.
