[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
The ISPs which are switching their named root cache files to this list is
not "growing support"?
I will note that we've been running on this alternative set for a couple of
months now, and have seen ZERO negative impact from doing so. What we have
seen is a measurable (~40%) decrease in average nameserver query response
times -- which in my book counts as an operational BENEFIT.
Of course, the fact that the "root" servers in the Alternic world only serve
"." and not the zones COM, NET and ORG pretty much guaranteed better
response. The only reason its not a LOT better is that you still have
to go back to those same machines for these zones.....
> My fault. Note that in my table I assumed it supported the alternative
> roots, so my count of 8 servers for the alternative roots is unchanged.
You also claimed miscellaneous configuration and other problems within the
alternative world. Of course, bad data in = bad conclusions out.
Further, how abotu the fact that the IANA roots were de-sync'd for several
days (and this isn't the first time) very recently (is this fixed yet?)
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa02967; 1 Nov 96 16:09 EST
Received: from nirvana.genesyslab.com by ietf.org id aa02616; 1 Nov 96 16:07 EST
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id NAA21817; Fri, 1 Nov 1996 13:06:35 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id NAA10870; Fri, 1 Nov 1996 13:06:11 -0800 (PST)
Date: Fri, 1 Nov 1996 13:06:11 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611012106.NAA10870 at giant.genesyslab.com>
To: Valdis.Kletnieks at vt.edu
Subject: Re: Re[3]: The cartel begins to crumble?
Cc: gaond at ncr.disa.mil, ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: Valdis.Kletnieks at vt.edu
>On Fri, 01 Nov 1996 12:08:10 PST, Leonid Egoshin said:
>> Offline is offline - you can do resolving on another host.
>> And at second, I think the large part of CPU time is the name-server/resolver
>> side, not mail transfer side.
>
>That's *exactly* the point. As it is *now*, mail systems spend more
>time calling the DNS than anything else. Waiting for it to be done
>"offline" is only making it worse. The whole *reason* that my machine
>runs a LOCAL caching DNS is so it DOESNT have to traverse the net and
>ask another host. And as it is, I often end up having "mail undeliverable"
>popping up because the host has in fact been decommissioned, but they forgot
>to drop the TTL value beforehand, so it stays in my cache for a week before
>I finally get a "host unknown".
>
Oh, no, Valdis. Some time ago I made corrections in BIND to track lost
name-servers and don't wait it again (it was serios in Russia). It had dramatic
influence on processing mail queue. But I had no time to rewrite sendmail -
- in my mind the reason of mail queue processing is not in DNS resolving
but in strategy of mail queue processing: sendmail fork one copy for one mail
in queue and process delivery to remote sites in consequence (I don't know
about modern versions, sorry). And you have choice - have many copies of
sendmail for many mails in queue or restrict delivering time of each attempt
to very short time :-(
Excuse me for particular technical details in this mail-list, but I think
it can illustrate tesis that directory service isn't bad idea and some technical
decisions is possible.
>David Gaon said:
>
>> But I suggest to Vladis Kletnieks that whoever creates the mailing
>> list will in fact resolve the names to port addresses and enter only
>> the last, or parties interested in joining the list will actually
>> offer their network port address through their mail (header or body)
>> since this will be available.
>
[emotional reply of Valdis removed]
but I agree with Valdis - it IS NEED the addition level of reference for high
level protocols - please remember for exam the problem of IP renumbering during
provider change. Especially if some server save addresses as it is in the case
of mail lists or URL references.
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa02966; 1 Nov 96 16:09 EST
Received: from jekyll.piermont.com by ietf.org id aa02679; 1 Nov 96 16:07 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id QAA03177; Fri, 1 Nov 1996 16:06:02 -0500 (EST)
Message-Id: <199611012106.QAA03177 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol
To: Karl Denninger <karl at mcs.net>
cc: Paul Hoffman <paulh at imc.org>, ietf at ietf.org, frezza at interramp.com
Subject: Re: The cartel begins to crumble?
In-reply-to: Your message of "Thu, 31 Oct 1996 17:24:16 CST."
<199610312324.RAA21892 at Mars.mcs.net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 01 Nov 1996 16:06:01 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Karl Denninger writes:
> > If I come along and say, "Ignore Karl, *I'm* selling subdomains of .biz and
> > you can use my DNS server", I can fool people into giving me money just as
> > easily as you can. And there might be two "mcdonalds.biz" domains, and mail
> > to "info at mcdonalds.biz" can go to either place based on which DNS server an
> > ISP happens to point to; same for Web accesses to "www.mcdonalds.biz".
>
> The second person who claims *ANY* TLD is the one to ignore.
>
> Not the first.
Or so you would like.
If you open up the door, who's to say you'll like what the people who
walk through decide to do?
Perry
Received: from ietf.org by ietf.org id aa04488; 1 Nov 96 16:15 EST
Received: from cnri by ietf.org id aa04027; 1 Nov 96 16:13 EST
Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa20639;
1 Nov 96 16:13 EST
Received: (qmail 9416 invoked by uid 1001); 1 Nov 1996 21:12:52 +0000 (GMT)
To: karl at mcs.net
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Folling the crumbling cartel - a note about thread following
Sender:ietf-request at ietf.org
From: sthaug at nethelp.no
In-Reply-To: Your message of "Fri, 1 Nov 1996 14:46:13 -0600 (CST)"
References: <199611012046.OAA29233 at Mercury.mcs.net>
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Fri, 01 Nov 1996 22:12:52 +0100
Message-ID: <9414.846882772 at verdi.nethelp.no>
Source-Info: From (or Sender) name not authenticated.
> From zero operational root nameservers to 80% of the number that the IANA
> has control over for how many years is not "growing support"?
>
> The ISPs which are switching their named root cache files to this list is
> not "growing support"?
My comments were in the context of Jim Fleming's note, which talks about
"the growing list of root name servers which are being deployed around
the world". I count 3 alternative roots outside North America. I don't
know how much this list has grown lately.
I'm quite willing to believe that a number of ISPs are switching their
named root cache files. I haven't seen any good estimates for numbers
here, though.
> You also claimed miscellaneous configuration and other problems within the
> alternative world. Of course, bad data in = bad conclusions out.
As you've already pointed out, I had the wrong IP address for one of
your alternative root servers. When you talk about 'miscellaneous
configuration and other problems', I assume you're referring to
Name IP address Other name Alternative Auth
rootsanswer
-----------------------------------------------------------------------------
MX.ALTERNIC.NET 204.94.42.1 YesNo answer
USVI.NET 204.199.0.4 YesYes *
* Gives authoritative answer for ".", but returns localhost!
I'd say these problems are quite real, and can hardly be called 'bad
data in'. A name server which returns 'localhost' as the authoritative
list of name servers for "." isn't particularly usable. And I still
can't get an answer to a DNS query from MX.ALTERNIC.NET, even if it
answers to ping.
> Further, how abotu the fact that the IANA roots were de-sync'd for several
> days (and this isn't the first time) very recently (is this fixed yet?)
I agree, there have been operational problems with the IANA roots, and
I certainly would prefer to see fewer of them. That doesn't mean that I
agree with your way of 'solving it'. Time will show who is right.
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
Received: from ietf.org by ietf.org id aa05119; 1 Nov 96 16:25 EST
Received: from Kitten.mcs.com by ietf.org id aa04992; 1 Nov 96 16:24 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id PAA11908; Fri, 1 Nov 1996 15:23:10 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJR3U-000DQfC at mailbox.mcs.com>; Fri, 1 Nov 96 15:23 CST
Received: (from karl at localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id PAA02754; Fri, 1 Nov 1996 15:23:07 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611012123.PAA02754 at Mercury.mcs.net>
Subject: Re: The cartel begins to crumble?
To: perry at piermont.com
Date: Fri, 1 Nov 1996 15:23:07 -0600 (CST)
Cc: karl at mcs.net, paulh at imc.org, ietf at ietf.org, frezza at interramp.com
In-Reply-To: <199611012106.QAA03177 at jekyll.piermont.com> from "Perry E. Metzger" at Nov 1, 96 04:06:01 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> Karl Denninger writes:
>> > If I come along and say, "Ignore Karl, *I'm* selling subdomains of .biz and
>> > you can use my DNS server", I can fool people into giving me money just as
>> > easily as you can. And there might be two "mcdonalds.biz" domains, and mail
>> > to "info at mcdonalds.biz" can go to either place based on which DNS server an
>> > ISP happens to point to; same for Web accesses to "www.mcdonalds.biz".
> >
> > The second person who claims *ANY* TLD is the one to ignore.
> >
> > Not the first.
>
> Or so you would like.
>
> If you open up the door, who's to say you'll like what the people who
> walk through decide to do?
>
> Perry
I truly believe that there can be consensus found on what "reasonable"
claims and registry density might be.
I posted one such possible starting point to these lists in the last 24
hours.
Why don't we debate and try to find consensus on *that* point? If we can,
then the entire argument related to this drops to the floor as irrelavent,
yes?
And if THAT happens, then we all have one goal left - leveraging the
hold-outs in the root-server game (or rendering them impotent).
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa06269; 1 Nov 96 16:42 EST
Received: from callandor.cybercash.com by ietf.org id aa06039;
1 Nov 96 16:39 EST
Received: by callandor.cybercash.com; id QAA04498; Fri, 1 Nov 1996 16:34:15 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma004486; Fri, 1 Nov 96 16:33:58 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA13582; Fri, 1 Nov 96 16:36:28 EST
Date: Fri, 1 Nov 1996 16:36:28 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: David Gaon <gaond at ncr.disa.mil>
Cc: ietf at ietf.org
Subject: "directories versus DNS"
In-Reply-To: <9610018468.AA846890402 at ncr.disa.mil>
Message-Id: <Pine.SUN.3.91.961101163304.8887H-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 1 Nov 1996, David Gaon wrote:
> Date: Fri, 01 Nov 96 15:17:47 EST
> From: David Gaon <gaond at ncr.disa.mil>
> To: Valdis.Kletnieks at vt.edu, Leonid Egoshin <egoshin at genesyslab.com>
> Cc: ietf at ietf.org
> Subject: Re[5]: The cartel begins to crumble?
>
> Leonid
>
> Thanks, I believe you have captured my intent.
>
> But I suggest to Vladis Kletnieks that whoever creates the mailing
> list will in fact resolve the names to port addresses and enter only
> the last, or parties interested in joining the list will actually
> offer their network port address through their mail (header or body)
> since this will be available.
>
> Cheers
>
> David Gaon
> DoD/DISA/Center for Standards
But you can't store IP numbers or something like that because the keep
changing (and, it seems likely, will change more often in the future). So
what do you store? If your directory leads to an intermediate value you need
to map to IP addresses, you've just re-invented DNS. So what was the gain?
Donald
Received: from ietf.org by ietf.org id aa06265; 1 Nov 96 16:42 EST
Received: from cnri by ietf.org id aa06114; 1 Nov 96 16:40 EST
Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa21187; 1 Nov 96 16:40 EST
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQbnzq24927; Fri, 1 Nov 1996 16:39:25 -0500 (EST)
Message-Id: <QQbnzq24927.199611012139 at rodan.UU.NET>
X-Mailer: exmh version 1.6.9 8/22/96
To: Karl Denninger <karl at mcs.net>
cc: sthaug at nethelp.no, ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: Folling the crumbling cartel - a note about thread following
References: <199611012011.OAA27288 at Mercury.mcs.net>
In-reply-to: Your message of "Fri, 01 Nov 1996 14:11:38 CST."
<199611012011.OAA27288 at Mercury.mcs.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Nov 1996 16:39:25 -0500
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
> > TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes
> Does someone care to tell me under what authority NSI is running COM, ORG
> and NET on servers owned by the US Government (three of the above) and two
> publically funded universities (2 more of the above)? :-)
When I set up the root server on TERP.UMD.EDU many years ago, it was done
as a public service with no expectation of renumeration. At the time,
that machine was richly connected to the Internet, being one of the
routers between the ARPANET and the then NSFNET phase-1 backbone.
> 1/2 of your operating infrastructure effectively paid for (at least in part)
> with public funds... not bad for a for-profit company!
While we can decend in this rat-hole, I think that the cost is that of
administration of the name space, and not running the servers. There are
very likely no shortage of qualified organizations who would be happy to
run root/TLD name servers at no cost. Certainly UUNET is willing to do
so.
--
Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
UUNET Technologies, Inc. Voice: +1 703 206 5823
3060 Williams Drive Fax: +1 703 208 5390
Fairfax, VA 22031
Received: from ietf.org by ietf.org id aa07233; 1 Nov 96 16:53 EST
Received: from jekyll.piermont.com by ietf.org id aa06904; 1 Nov 96 16:50 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id QAA03325; Fri, 1 Nov 1996 16:49:34 -0500 (EST)
Message-Id: <199611012149.QAA03325 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol
To: Karl Denninger <karl at mcs.net>
cc: Per Gregers Bilse <bilse at eu.net>, ietf at ietf.org, frezza at interramp.com
Subject: Re: The cartel begins to crumble?
In-reply-to: Your message of "Fri, 01 Nov 1996 09:12:36 CST."
<199611011512.JAA06591 at Mercury.mcs.net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 01 Nov 1996 16:49:33 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Karl Denninger writes:
> Operational registries Per Gregers, nothing more or less.
>
> We have it (and had it first), you did not.
>
> I can declare myself emporer of the known universe, but unless I do
> something to demonstrate that I'm serious (ie: find a way to actually govern
> and enforce it across every person on the planet) all I get is laughed at.
Karl;
As it stands, your "operational registries" are invisible to most of
the planet. By your own standards of enforceability, you are doing the
equivalent of declaring yourself emperor of the universe.
Perry
Received: from ietf.org by ietf.org id aa07232; 1 Nov 96 16:53 EST
Received: from cnri by ietf.org id aa06954; 1 Nov 96 16:51 EST
Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa21507;
1 Nov 96 16:51 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id PAA13219; Fri, 1 Nov 1996 15:50:24 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJRTq-000DPXC at mailbox.mcs.com>; Fri, 1 Nov 96 15:50 CST
Received: (from karl at localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id PAA04316; Fri, 1 Nov 1996 15:50:22 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611012150.PAA04316 at Mercury.mcs.net>
Subject: Re: Folling the crumbling cartel - a note about thread following
To: "Louis A. Mamakos" <louie at uu.net>
Date: Fri, 1 Nov 1996 15:50:21 -0600 (CST)
Cc: karl at mcs.net, sthaug at nethelp.no, ietf at CNRI.Reston.VA.US
In-Reply-To: <QQbnzq24927.199611012139 at rodan.UU.NET> from "Louis A. Mamakos" at Nov 1, 96 04:39:25 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> > > TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes
>
> > Does someone care to tell me under what authority NSI is running COM, ORG
> > and NET on servers owned by the US Government (three of the above) and two
> > publically funded universities (2 more of the above)? :-)
>
> When I set up the root server on TERP.UMD.EDU many years ago, it was done
> as a public service with no expectation of renumeration. At the time,
> that machine was richly connected to the Internet, being one of the
> routers between the ARPANET and the then NSFNET phase-1 backbone.
>
> > 1/2 of your operating infrastructure effectively paid for (at least in part)
> > with public funds... not bad for a for-profit company!
>
> While we can decend in this rat-hole, I think that the cost is that of
> administration of the name space, and not running the servers. There are
> very likely no shortage of qualified organizations who would be happy to
> run root/TLD name servers at no cost. Certainly UUNET is willing to do
> so.
And for a private company to decide to do that (including MCSNet, which it
does) I think that is a perfectly-valid decision to make.
Its your money. Spend it as you believe to be wise. Including giving
another firm the technical means to make $20,000,000 a year (without
renumerating any part of that to you) if you wish.
Proper infrastructure is NOT cheap if you intend to provide quality root
nameservice (or any nameservice for that matter). You certainly aren't
going to do it without some kind of redundancy in your connectivity, and
even if you buy two T1s it runs into the tens of thousands of dollars a
year. Yes, it looks like chickenfeed when you look at a $20M business
annually, but frankly, lots of people have gotten in serious trouble for
converting a lot less value then that to private profit and use.
Without these nameservers NSI wouldn't have a business to run. You can
register anything you want, but if you can't publish it, the TLD is useless.
Again, I don't even have a problem with public institutions necessarily
providing root nameservers - as long as they're open on a non-discriminatory
basis (ie: no IANA "you can't list that without paying our tax" games).
When it comes to those same public institutions underwriting the operational
costs of a for-profit company, I believe there's a severe problem.
When it comes to US *government* institutions doing so, it can be more than
just a policy problem -- depending on the exact particulars of the case, of
course.
> Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
> UUNET Technologies, Inc. Voice: +1 703 206 5823
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa07351; 1 Nov 96 16:53 EST
Received: from Kitten.mcs.com by ietf.org id aa07149; 1 Nov 96 16:52 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id PAA13275; Fri, 1 Nov 1996 15:51:33 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJRUx-000D36C at mailbox.mcs.com>; Fri, 1 Nov 96 15:51 CST
Received: (from karl at localhost) by Mercury.mcs.net (8.8.Beta.6/8.8.Beta.3) id PAA04458; Fri, 1 Nov 1996 15:51:30 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611012151.PAA04458 at Mercury.mcs.net>
Subject: Re: The cartel begins to crumble?
To: perry at piermont.com
Date: Fri, 1 Nov 1996 15:51:30 -0600 (CST)
Cc: karl at mcs.net, bilse at eu.net, ietf at ietf.org, frezza at interramp.com
In-Reply-To: <199611012149.QAA03325 at jekyll.piermont.com> from "Perry E. Metzger" at Nov 1, 96 04:49:33 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>
>
> Karl Denninger writes:
> > Operational registries Per Gregers, nothing more or less.
> >
> > We have it (and had it first), you did not.
> >
> > I can declare myself emporer of the known universe, but unless I do
> > something to demonstrate that I'm serious (ie: find a way to actually govern
> > and enforce it across every person on the planet) all I get is laughed at.
>
> Karl;
>
> As it stands, your "operational registries" are invisible to most of
> the planet. By your own standards of enforceability, you are doing the
> equivalent of declaring yourself emperor of the universe.
>
> Perry
Really? They're not invisible to anyone who supports the eDNS servers.
And their existing IS published. Widely. And has been for months.
Give the straw men up Perry, and debate the issues at hand.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa08412; 1 Nov 96 17:12 EST
Received: from cnri by ietf.org id aa08315; 1 Nov 96 17:10 EST
Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa21999;
1 Nov 96 17:10 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id QAA28402; Fri, 1 Nov 1996 16:04:48 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC80E.9F53FEC0 at webster.unety.net>; Fri, 1 Nov 1996 16:06:21 -0600
Message-ID: <01BBC80E.9F53FEC0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "karl at mcs.net" <karl at mcs.net>, "'sthaug at nethelp.no'" <sthaug at nethelp.no>
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Subject: RE: Folling the crumbling cartel - a note about thread following
Date: Fri, 1 Nov 1996 16:06:19 -0600
Encoding: 78 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 2:32 PM, sthaug at nethelp.no wrote:
@ > Does someone care to tell me under what authority NSI is running COM, ORG
@ > and NET on servers owned by the US Government (three of the above) and two
@ > publically funded universities (2 more of the above)? :-)
@ >
@ > 1/2 of your operating infrastructure effectively paid for (at least in part)
@ > with public funds... not bad for a for-profit company!
@
@ I'm not the right person to comment on this - but I see that you prefer
@ to discuss other things than the claimed 'growing support'.
@
@ > > ROOT-NS.MCS.NET 192.160.127.8 YesNo route
@ >
@ > That IP address is wrong. The right one is 192.160.127.86. If you ping
@ > the right address (or dig to it) you'll find that it does work.
@
@ My fault. Note that in my table I assumed it supported the alternative
@ roots, so my count of 8 servers for the alternative roots is unchanged.
@
@ > > Quite frankly, I can't see that you have shown anything whatsoever about
@ > > growing support for your alternative roots around the world. Furthermore,
@ > > I can't see any reason why I should "take this work seriously".
@ >
@ > Well, you could start by making sure you're looking in the right place! :-)
@
@ I still can't see that anything you've said here supports the notion
@ that there is growing support for your alternative roots around the world.
@
@ Steinar Haug, Nethelp consulting, sthaug at nethelp.no
@
@
In the last two days, I have received a confirmation
from four ISPs in the United States who are not listed
above.
One of the leaders of Japan's Internet community has
asked if they can add a root name server to the list.
I continue to get interest from Australia and some
of the other "wired" places on the planet.
Also, keep in mind that I am just one reference point.
Paul Vixie indicated recently that there is no shortage
of people that want to operate root name servers.
I am not sure if he is making a list. Also, Eugene
Kashpureff mentioned having a long list of interested
parties that he is working as part of the AlterNIC.
Quite frankly, one of my major concerns is that
too many people will want to provide root name
servers. In the United States, this is probably most
easily handled with a Root 128 group, that just
includes U.S. root name servers.
The Root 64 name server grouping is intended to
focus the attention on a broader International
distribution. The Root 64 group will likely be a
harder group to fill, but could end up being viewed
as more fair in its deliberations because of the
diversity of opinions from around the world.
Only time will tell as to how these various
"roots" (or routes) evolve in cyberspace. One
thing for sure, many years from now Root 64
might be sitting next to Route 66 on a web
page as just another chapter in the history
of man's attempt to create highways to
connect people.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa09492; 1 Nov 96 17:26 EST
Received: from cnri by ietf.org id aa09366; 1 Nov 96 17:25 EST
Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa22276;
1 Nov 96 17:25 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id QAA28454; Fri, 1 Nov 1996 16:19:32 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC810.AE47E5C0 at webster.unety.net>; Fri, 1 Nov 1996 16:21:05 -0600
Message-ID: <01BBC810.AE47E5C0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: Karl Denninger <karl at mcs.net>, "'Louis A. Mamakos'" <louie at uu.net>
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
'New Newdom' <newdom at vrx.net>, "sthaug at nethelp.no" <sthaug at nethelp.no>
Subject: RE: Folling the crumbling cartel - a note about thread following
Date: Fri, 1 Nov 1996 16:21:03 -0600
Encoding: 45 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 3:39 PM, Louis A. Mamakos[SMTP:louie at uu.net] wrote:
@ > > TERP.UMD.EDU 128.8.10.90 d.root-servers.net NoYes
@
@ > Does someone care to tell me under what authority NSI is running COM, ORG
@ > and NET on servers owned by the US Government (three of the above) and two
@ > publically funded universities (2 more of the above)? :-)
@
@ When I set up the root server on TERP.UMD.EDU many years ago, it was done
@ as a public service with no expectation of renumeration. At the time,
@ that machine was richly connected to the Internet, being one of the
@ routers between the ARPANET and the then NSFNET phase-1 backbone.
@
@ > 1/2 of your operating infrastructure effectively paid for (at least in part)
@ > with public funds... not bad for a for-profit company!
@
@ While we can decend in this rat-hole, I think that the cost is that of
@ administration of the name space, and not running the servers. There are
@ very likely no shortage of qualified organizations who would be happy to
@ run root/TLD name servers at no cost. Certainly UUNET is willing to do
@ so.
@
@ --
@ Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
@ UUNET Technologies, Inc. Voice: +1 703 206 5823
@ 3060 Williams Drive Fax: +1 703 208 5390
@ Fairfax, VA 22031
@
@
At the risk of claiming that there is a "growing" group
of parties interested in running root name servers, I
would suggest that you might want to deploy a server
and join either the Root 64 collection or the Root 128
collection (for U.S. only).
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa09791; 1 Nov 96 17:30 EST
Received: from nirvana.genesyslab.com by ietf.org id aa09547; 1 Nov 96 17:29 EST
Received: from giant.genesyslab.com (giant.genesyslab.com [206.86.238.70]) by nirvana.genesyslab.com (8.7.6/8.7.6) with ESMTP id OAA22929; Fri, 1 Nov 1996 14:28:41 -0800 (PST)
Received: (from egoshin at localhost) by giant.genesyslab.com (8.7.5/8.7.3) id OAA12175; Fri, 1 Nov 1996 14:28:18 -0800 (PST)
Date: Fri, 1 Nov 1996 14:28:18 -0800 (PST)
Sender:ietf-request at ietf.org
From: Leonid Egoshin <egoshin at genesyslab.com>
Message-Id: <199611012228.OAA12175 at giant.genesyslab.com>
To: Valdis.Kletnieks at vt.edu
Subject: Re: Re[3]: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
>From: Valdis.Kletnieks at vt.edu
>
>The basic problem is that if I say "it has to be at least as fast as DNS",
>then it falls to the proponents of LDAP or X.500 or WHOIS++ or whatever,
>to demonstrate that at least in principle, it will resolve queries just as
>fast, when scaled to the size needed. And yes, I'm familiar with the
>work that the U of Michigan crew has done to speed up LDAP - it's almost
>fast enough *within an organization* but still has problems scaling...
Ok, but what about the next - we can separate all protocols which used
DNS on two groups - protocols for search and for mapping only. For exam
in first group can be whois,finger,www(during first looking attempt)
and mail (my be not real mail, but some tools for search right address);
and in second group can be other which requered distinct and speed mapping.
And both - DNS and directory service can coexist. And this division would
service like www.<company>.com and other outside of DNS (or something
another notation instead of .com).
Probably this direction can solve the problem of decentralisation of service
with correct mapping...
- Leonid Yegoshin, LY22
Received: from ietf.org by ietf.org id aa09977; 1 Nov 96 17:30 EST
Received: from bast.livingston.com by ietf.org id aa09722; 1 Nov 96 17:29 EST
Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.7.5/8.6.9) with ESMTP id OAA19719 for <ietf at ietf.org>; Fri, 1 Nov 1996 14:29:49 -0800 (PST)
Received: (from megazone at localhost) by server.livingston.com (8.7.1/8.6.9) id OAA26244 for ietf at ietf.org; Fri, 1 Nov 1996 14:28:44 -0800 (PST)
Message-Id: <199611012228.OAA26244 at server.livingston.com>
Subject: Offline lookups? No way - was Cartel et al
To: ietf at ietf.org
Date: Fri, 1 Nov 1996 14:28:44 -0800 (PST)
Sender:ietf-request at ietf.org
From: MegaZone <megazone at livingston.com>
Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Once upon a time David Gaon shaped the electrons to say...
> the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is lef
> to the user and is done offline (with respect to the communications
> infrastructure). The user, on deciding whom he wants to reach, either
That's why this will never work. Machines get renumbered ALL THE TIME.
That is why DNS is so damn useful in the first place - just remember the name,
and DNS will find the current number. The CD would be out of date before it
shipped.
-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone at livingston.com
For support requests: support at livingston.com <http://www.livingston.com/>
Snail mail: 6920 Koll Center Parkway #220, Pleasanton, CA 94566
Received: from ietf.org by ietf.org id aa10514; 1 Nov 96 17:38 EST
Received: from jekyll.piermont.com by ietf.org id aa10280; 1 Nov 96 17:36 EST
Received: from [[UNIX: localhost]] ([[UNIX: localhost]]) by jekyll.piermont.com (8.7.6/8.6.12) with SMTP id RAA03512; Fri, 1 Nov 1996 17:35:33 -0500 (EST)
Message-Id: <199611012235.RAA03512 at jekyll.piermont.com>
X-Authentication-Warning: jekyll.piermont.com: Host [[UNIX: localhost]] didn't use HELO protocol
To: Karl Denninger <karl at mcs.net>
cc: bilse at eu.net, ietf at ietf.org, frezza at interramp.com
Subject: Re: The cartel begins to crumble?
In-reply-to: Your message of "Fri, 01 Nov 1996 15:51:30 CST."
<199611012151.PAA04458 at Mercury.mcs.net>
Reply-To: perry at piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Fri, 01 Nov 1996 17:35:32 -0500
Sender:ietf-request at ietf.org
From: "Perry E. Metzger" <perry at piermont.com>
Source-Info: From (or Sender) name not authenticated.
Karl Denninger writes:
> > As it stands, your "operational registries" are invisible to most of
> > the planet. By your own standards of enforceability, you are doing the
> > equivalent of declaring yourself emperor of the universe.
>
> Really? They're not invisible to anyone who supports the eDNS servers.
Did I say that? I merely said they are invisible to virtually everyone
(that is, well over 99%) of the people using the internet.
I'm happy, however, to shift the discussion to the large issues of
TLDs and DNS management.
Perry
Received: from ietf.org by ietf.org id aa10568; 1 Nov 96 17:38 EST
Received: from servo.qualcomm.com by ietf.org id aa10458; 1 Nov 96 17:37 EST
Received: (from karn at localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id OAA09605; Fri, 1 Nov 1996 14:36:17 -0800 (PST)
Date: Fri, 1 Nov 1996 14:36:17 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at qualcomm.com>
Message-Id: <199611012236.OAA09605 at servo.qualcomm.com>
To: ERIC at vm.se.lsoft.com
CC: ietf at ietf.org
In-reply-to: <9610311326.aa10929 at ietf.org> (message from Eric Thomas on Thu, 31 Oct 1996 19:03:36 +0100)
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
Source-Info: From (or Sender) name not authenticated.
I have an extra item for your list.
Americans are among the most assertive and outspoken people in the
world, and American IETFers are among the most assertive and outspoken
Americans. Our passions can easily intimidate those of other cultures
(especially Asians) into offended silence. As a result, simple
misunderstandings can erupt into major battles or at least long-term
resentment.
The IETF is an English-speaking, US-centric organization because the
Internet originated in the US. This is likely to remain so for a long
time. So while it is certainly a good idea for American IETFers to be
more sensitive to those from non-English speaking countries, it would
also be a good idea for non-US IETF members who have honest
disagreements to try to be more assertive than they ordinarily are
back home. Sure, people may take offense from time to time, but this
is rarely fatal. More often it's an unavoidable side-effect of
clearing the air and making real progress.
Phil
Received: from ietf.org by ietf.org id aa10853; 1 Nov 96 17:43 EST
Received: from cnri by ietf.org id aa10758; 1 Nov 96 17:41 EST
Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa22608;
1 Nov 96 17:41 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id QAA16037; Fri, 1 Nov 1996 16:40:36 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJSGO-000DQMC at mailbox.mcs.com>; Fri, 1 Nov 96 16:40 CST
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.Beta.3) id QAA12841; Fri, 1 Nov 1996 16:40:31 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611012240.QAA12841 at Jupiter.Mcs.Net>
Subject: Re: Folling the crumbling cartel - a note about thread following
To: Valdis.Kletnieks at vt.edu
Date: Fri, 1 Nov 1996 16:40:31 -0600 (CST)
Cc: karl at mcs.net, ietf at CNRI.Reston.VA.US
In-Reply-To: <199611012235.RAA36628 at black-ice.cc.vt.edu> from "Valdis.Kletnieks at vt.edu" at Nov 1, 96 05:35:10 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> > response. The only reason its not a LOT better is that you still have
> > to go back to those same machines for these zones.....
>
> Are you saying that when you get as overloaded as they are, you'll be
> just as sluggish? I'll bet that if *I* ran my own root nameserver on
> my RT in my basement, I'd see a BLINDING speedup for the small section of
> things that I was root for.
>
> I'd worry if you can only get 40% faster serving a very small segment of *.BIZ
> addresses in existence, compared to having to serve *.COM. Are you sure you
> want to brag about that?
No, we're 40% faster *across the board*. Since COM, NET and ORG are the
majority of records, this is in fact remarkable.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa11906; 1 Nov 96 18:01 EST
Received: from cnri by ietf.org id aa11673; 1 Nov 96 17:59 EST
Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa23011; 1 Nov 96 17:59 EST
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQbnzv10613; Fri, 1 Nov 1996 17:57:58 -0500 (EST)
Message-Id: <QQbnzv10613.199611012257 at rodan.UU.NET>
X-Mailer: exmh version 1.6.9 8/22/96
To: Jim Fleming <JimFleming at unety.net>
cc: Karl Denninger <karl at mcs.net>,
"ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
'New Newdom' <newdom at vrx.net>, "sthaug at nethelp.no" <sthaug at nethelp.no>
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: Folling the crumbling cartel - a note about thread following
References: <01BBC810.AE47E5C0 at webster.unety.net>
In-reply-to: Your message of "Fri, 01 Nov 1996 16:21:03 CST."
<01BBC810.AE47E5C0 at webster.unety.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Nov 1996 17:57:58 -0500
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
> At the risk of claiming that there is a "growing" group
> of parties interested in running root name servers, I
> would suggest that you might want to deploy a server
> and join either the Root 64 collection or the Root 128
> collection (for U.S. only).
While I can't speak on behalf of all of UUNET, I can certainly
offer my opinion. I don't think that UUNET would be interested
in running a "rogue" root name server. The willingness of our
running a root name server is so that our customer would derive some
benifit (as well as the public at large) by having robust connectivity
to a reliably and competently operated name server.
Having a nameserver which doesn't participate in the commonly
accepted namespace is counter-productive and results in unhappy
customers and users who can't get to where they want to go (or
vice versa).
I won't expound on this further, as the pursuasive arguments have
already been made on the list. Having a disjoint namespace is just
counterproductive and creates another set of problems.
> e-mail:
> JimFleming at unety.net
> JimFleming at unety.net.s0.g0 (EDNS/IPv8)
But I guess this argument is wasted on those who have "left the fold"
as it were.. How is this EDNS/IPv8 thing useful, other than
those who've joined the private club? The success of the Internet is
that there is the underlying universal interoperability between all those
that join "The Internet."
--
Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
UUNET Technologies, Inc. Voice: +1 703 206 5823
3060 Williams Drive Fax: +1 703 208 5390
Fairfax, VA 22031
Received: from ietf.org by ietf.org id aa12078; 1 Nov 96 18:04 EST
Received: from cnri by ietf.org id aa11993; 1 Nov 96 18:03 EST
Received: from Kitten.mcs.com by CNRI.Reston.VA.US id aa23115;
1 Nov 96 18:03 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id RAA17156; Fri, 1 Nov 1996 17:02:08 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJSbG-000DQZC at mailbox.mcs.com>; Fri, 1 Nov 96 17:02 CST
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.Beta.3) id RAA13532; Fri, 1 Nov 1996 17:02:05 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611012302.RAA13532 at Jupiter.Mcs.Net>
Subject: Re: Folling the crumbling cartel - a note about thread following
To: "Louis A. Mamakos" <louie at uu.net>
Date: Fri, 1 Nov 1996 17:02:05 -0600 (CST)
Cc: JimFleming at unety.net, karl at mcs.net, ietf at CNRI.Reston.VA.US,
newdom at vrx.net, sthaug at nethelp.no
In-Reply-To: <QQbnzv10613.199611012257 at rodan.UU.NET> from "Louis A. Mamakos" at Nov 1, 96 05:57:58 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> > At the risk of claiming that there is a "growing" group
> > of parties interested in running root name servers, I
> > would suggest that you might want to deploy a server
> > and join either the Root 64 collection or the Root 128
> > collection (for U.S. only).
>
> While I can't speak on behalf of all of UUNET, I can certainly
> offer my opinion. I don't think that UUNET would be interested
> in running a "rogue" root name server. The willingness of our
> running a root name server is so that our customer would derive some
> benifit (as well as the public at large) by having robust connectivity
> to a reliably and competently operated name server.
>
> Having a nameserver which doesn't participate in the commonly
> accepted namespace is counter-productive and results in unhappy
> customers and users who can't get to where they want to go (or
> vice versa).
>
> I won't expound on this further, as the pursuasive arguments have
> already been made on the list. Having a disjoint namespace is just
> counterproductive and creates another set of problems.
>
> > e-mail:
> > JimFleming at unety.net
> > JimFleming at unety.net.s0.g0 (EDNS/IPv8)
>
> But I guess this argument is wasted on those who have "left the fold"
> as it were.. How is this EDNS/IPv8 thing useful, other than
> those who've joined the private club? The success of the Internet is
> that there is the underlying universal interoperability between all those
> that join "The Internet."
>
> --
> Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
> UUNET Technologies, Inc. Voice: +1 703 206 5823
Really?
And you get to define what the namespace of "The Internet" is, right?
Or, more correctly, the IANA gets to define it?
Why?
The nameservers you claim to be "rogue" don't corrupt the IANA information.
If they did, or if they do in the future try to delegate a domain (ie: .COM)
that is already taken by another claimant, you'll find me (along with a
bunch of other people who support eDNS now) screaming just as loudly about
that set of brokenness -- and then removing them from the cache list.
Your claim is that the other DNS root servers don't participate in the
"commonly accepted namespace". Care to verify that by providing us with an
example of a TLD which is in the IANA roots and missing from eDNS?
Or is the concept of *enhancing* service for UUNET's customers lost here?
No legacy names are broken by supporting eDNS. Not one.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa14276; 1 Nov 96 18:13 EST
Received: from cnri by ietf.org id aa14060; 1 Nov 96 18:11 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa23241;
1 Nov 96 18:11 EST
Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA15050>; Fri, 1 Nov 1996 15:09:58 -0800
Sender:ietf-request at ietf.org
From: bmanning at isi.edu
Posted-Date: Fri, 1 Nov 1996 15:09:20 -0800 (PST)
Message-Id: <199611012309.AA02894 at zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-6)
id <AA02894>; Fri, 1 Nov 1996 15:09:21 -0800
Subject: Why Jim thinks his root servers are better than the operational ones
To: sthaug at nethelp.no
Date: Fri, 1 Nov 1996 15:09:20 -0800 (PST)
Cc: karl at mcs.net, ietf at CNRI.Reston.VA.US
In-Reply-To: <9414.846882772 at verdi.nethelp.no> from "sthaug at nethelp.no" at Nov 1, 96 10:12:52 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 367
Source-Info: From (or Sender) name not authenticated.
> I agree, there have been operational problems with the IANA roots, and
> I certainly would prefer to see fewer of them. That doesn't mean that I
> agree with your way of 'solving it'. Time will show who is right.
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>
Would that be fewer operational problems or fewer IANA sactioned
roots? :)
--
--bill
Received: from ietf.org by ietf.org id aa14338; 1 Nov 96 18:14 EST
Received: from cnri by ietf.org id aa14257; 1 Nov 96 18:13 EST
Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa23306;
1 Nov 96 18:13 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA28721; Fri, 1 Nov 1996 17:07:17 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC817.59D73660 at webster.unety.net>; Fri, 1 Nov 1996 17:08:49 -0600
Message-ID: <01BBC817.59D73660 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "'Louis A. Mamakos'" <louie at uu.net>
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
Karl Denninger <karl at mcs.net>, 'New Newdom' <newdom at vrx.net>,
"sthaug at nethelp.no" <sthaug at nethelp.no>
Subject: RE: Folling the crumbling cartel - a note about thread following
Date: Fri, 1 Nov 1996 17:08:48 -0600
Encoding: 97 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 4:57 PM, Louis A. Mamakos[SMTP:louie at UU.NET] wrote:
@
@ > At the risk of claiming that there is a "growing" group
@ > of parties interested in running root name servers, I
@ > would suggest that you might want to deploy a server
@ > and join either the Root 64 collection or the Root 128
@ > collection (for U.S. only).
@
@ While I can't speak on behalf of all of UUNET, I can certainly
@ offer my opinion. I don't think that UUNET would be interested
@ in running a "rogue" root name server. The willingness of our
@ running a root name server is so that our customer would derive some
@ benifit (as well as the public at large) by having robust connectivity
@ to a reliably and competently operated name server.
@
If you define a "rogue" root name server as one that supports
all of the top level domain registries, currently operating then
I guess we have to disagree. I would call that a rich or robust
root name server, but you chose the word rogue.
If UUNET is only interested in running a name server that
supports some subset that UUNET selects, then you might
want to describe how you arrive at that subset decision and
anyone (mostly ISPs) that uses your root name server should
be informed that you are operating a limited root name server.
Limited root name servers may have merit if society really
feels that limiting access to the .XXX and .SEX top level domains
is something that people want. Unfortunately, once UUNET
starts down the road of picking and choosing top level domain
names, then you enter the world of censorship issues.
@ Having a nameserver which doesn't participate in the commonly
@ accepted namespace is counter-productive and results in unhappy
@ customers and users who can't get to where they want to go (or
@ vice versa).
@
I agree, that is why I am advocating that the group of Root 64
name server owners and operators be allowed to come to a
market consensus based in large part from the new top level
domain registries that are emerging. That process will develop
what you refer to as the "commonly accepted namespace".
@ I won't expound on this further, as the pursuasive arguments have
@ already been made on the list. Having a disjoint namespace is just
@ counterproductive and creates another set of problems.
@
I agree...except as noted above regarding potential social
benefits or desires, and I prefer not to ge there either...
@ > e-mail:
@ > JimFleming at unety.net
@ > JimFleming at unety.net.s0.g0 (EDNS/IPv8)
@
@ But I guess this argument is wasted on those who have "left the fold"
@ as it were.. How is this EDNS/IPv8 thing useful, other than
@ those who've joined the private club? The success of the Internet is
@ that there is the underlying universal interoperability between all those
@ that join "The Internet."
@
No one has left the fold. The Internet is capable of supporting many
communities and experimental efforts. That is one way it evolves.
I would hope that you do not look at people's business cards and
note their FAX number and say, "OH I see that you have left the fold"...
Also.....some people have discovered that the use of zip-codes
helps to improve the performance of their mail delivery...I would
hope that when you see a letter with a zip-code that you do not
think a person or company has "left the fold"...
@ --
@ Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
@ UUNET Technologies, Inc. Voice: +1 703 206 5823
@ 3060 Williams Drive Fax: +1 703 208 5390
@ Fairfax, VA 22031
@
....Hmmm...have you left the fold with that FAX number above...?
...what about that zip-code...
...Oh...the conclusions we could draw...;-)
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa16021; 1 Nov 96 18:35 EST
Received: from tipper.oit.unc.edu by ietf.org id aa15922; 1 Nov 96 18:33 EST
Received: from tipper.oit.unc.edu (tipper.oit.unc.edu [152.2.22.85]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id SAA10527 for <ietf at ietf.org>; Fri, 1 Nov 1996 18:33:37 -0500
Date: Fri, 1 Nov 1996 18:33:36 -0500 (EST)
Sender:ietf-request at ietf.org
From: Simon Spero <ses at tipper.oit.unc.edu>
To: ietf at ietf.org
Subject: Carpools and Cartels
In-Reply-To: <199611012106.QAA03177 at jekyll.piermont.com>
Message-ID: <Pine.SUN.3.91.961101182619.10489A-100000 at tipper.oit.unc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
[Never one to miss the opportunity for a segue, Are there any carpools
going from SF to San Jose during the IETF?]
In comp.protocols.tcp-ip.domains, Karl made an interesting claim as to
ownership of .biz based on his newgrouping of various usenet biz.*
groups. My immediate response was to ask whether that precendent would
give UNC & Duke control of the .net domain...
---
If I can get my key back, it's Key Recovery
If you can get my key back, it's Key Escrow
Received: from ietf.org by ietf.org id aa16575; 1 Nov 96 18:39 EST
Received: from cnri by ietf.org id aa16433; 1 Nov 96 18:38 EST
Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa23677; 1 Nov 96 18:38 EST
Received: from sayshell.UU.NET by rodan.UU.NET with SMTP
(peer crosschecked as: sayshell.UU.NET [153.39.251.30])
id QQbnzy17707; Fri, 1 Nov 1996 18:37:25 -0500 (EST)
Message-Id: <QQbnzy17707.199611012337 at rodan.UU.NET>
X-Mailer: exmh version 1.6.9 8/22/96
To: Jim Fleming <JimFleming at unety.net>
cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
Karl Denninger <karl at mcs.net>, 'New Newdom' <newdom at vrx.net>,
"sthaug at nethelp.no" <sthaug at nethelp.no>
Sender:ietf-request at ietf.org
From: "Louis A. Mamakos" <louie at uu.net>
Subject: Re: Folling the crumbling cartel - a note about thread following
References: <01BBC817.59D73660 at webster.unety.net>
In-reply-to: Your message of "Fri, 01 Nov 1996 17:08:48 CST."
<01BBC817.59D73660 at webster.unety.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Nov 1996 18:37:23 -0500
X-Orig-Sender: louie at uu.net
Source-Info: From (or Sender) name not authenticated.
> If you define a "rogue" root name server as one that supports
> all of the top level domain registries, currently operating then
> I guess we have to disagree. I would call that a rich or robust
> root name server, but you chose the word rogue.
Please, feel free to select any adjective you choose to describe
the "other" name servers.
> If UUNET is only interested in running a name server that
> supports some subset that UUNET selects, then you might
> want to describe how you arrive at that subset decision and
> anyone (mostly ISPs) that uses your root name server should
> be informed that you are operating a limited root name server.
As I mentioned before, UUNET has not spoken one way or the other
on this issue. As I'm not an officer of the company (just a stockholder),
I can't make unlateral statements.
But in any case, like it or not, UUNET and other organizations on the
internet get to choose which root name servers they use for their
purposes. You are just the first to come along with an alternative
name space.
> Limited root name servers may have merit if society really
> feels that limiting access to the .XXX and .SEX top level domains
> is something that people want. Unfortunately, once UUNET
> starts down the road of picking and choosing top level domain
> names, then you enter the world of censorship issues.
And when the next group of people come along that disagree with your
procedures and policies, and create their own .XXX and .SEX domain -
then what? Who's "right?"
And, please, don't start thumping on the "censorship" drum. That's
just a damn red herring, and you know it. There is nothing which
prevents any organziation from running their own caching name servers
and choosing to do what they please. That certainly includes UUNET's
customers and MCI's customers and my network at home.
Many ISP's run caching name servers as a service to their customers,
and they chose to do so in a way which provides robust service and
hopfully minimized phone calls to the customer support staff. That
an organziation chooses to recognize the "generally accepted" set of
name servers is perfectly reasonable.
> @ Having a nameserver which doesn't participate in the commonly
> @ accepted namespace is counter-productive and results in unhappy
> @ customers and users who can't get to where they want to go (or
> @ vice versa).
> @
>
> I agree, that is why I am advocating that the group of Root 64
> name server owners and operators be allowed to come to a
> market consensus based in large part from the new top level
> domain registries that are emerging. That process will develop
> what you refer to as the "commonly accepted namespace".
Feel free to beat the bush and gain supporters. Unilaterally creating
TLDs, though, is another matter. Who mediates? What if I want the
.SEX domain? Why is my claim any less valid than yours?
> No one has left the fold. The Internet is capable of supporting many
> communities and experimental efforts. That is one way it evolves.
I'm certainly not trying to stifle experiments. However, there is a
large poplulation of users on the Internet which expect it to be
run as a production service they can depend on, and experiments are
mostly incompatible with that. While we certainly are involved in
experimental projects, there is a clear distinction between them and
a production service which our engineering and operations staff are
here to support.
My personal opinion is that it would be unwise to have an alternative
namespaces to choose from as part of a production service. You might
disagree with that opinion.
Further, I think there are some good reasons not to have 64 or 128
root name servers. You'll make the packet sizes large enough to
require TCP transport as the UDP responses are too large to be
returned unfragmented. It was this issue which prompted the
re-naming of the root name servers into the "ROOT-SERVERS.NET"
domain, so that the common substring could be omitted by the
"compression" algorithm used to encode the DNS packets.
I'm guessing that you'd propose to not return the full set, and then
change the way that the DNS works?
> I would hope that you do not look at people's business cards and
> note their FAX number and say, "OH I see that you have left the fold"...
Yes, but when I see a card with "Internet: louie at UU.NET", I'd expect
to be able to use that email address on the thing which is generally
accepted to be "The Internet" and have it work.
While I also have a "uunet!louie" address listed for an older,
alternative email transport, I rarely get many messages sent to me
that way and longer.
> Also.....some people have discovered that the use of zip-codes
> helps to improve the performance of their mail delivery...I would
> hope that when you see a letter with a zip-code that you do not
> think a person or company has "left the fold"...
Now you're just being silly.
Finally, I doubt this has relevance to the IETF mailing list any longer,
and I know that I have work to do..
--
Louis A. Mamakos, Manager, Strategic Technologies louie at uu.net, uunet!louie
UUNET Technologies, Inc. Voice: +1 703 206 5823
3060 Williams Drive Fax: +1 703 208 5390
Fairfax, VA 22031
Received: from ietf.org by ietf.org id aa17793; 1 Nov 96 18:54 EST
Received: from cnri by ietf.org id aa17690; 1 Nov 96 18:52 EST
Received: from doorstep.unety.net by CNRI.Reston.VA.US id aa23938;
1 Nov 96 18:52 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id RAA28872; Fri, 1 Nov 1996 17:46:48 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBC81C.DED103A0 at webster.unety.net>; Fri, 1 Nov 1996 17:48:20 -0600
Message-ID: <01BBC81C.DED103A0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "'Louis A. Mamakos'" <louie at uu.net>
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
Karl Denninger <karl at mcs.net>, 'New Newdom' <newdom at vrx.net>,
"sthaug at nethelp.no" <sthaug at nethelp.no>
Subject: RE: Folling the crumbling cartel - a note about thread following
Date: Fri, 1 Nov 1996 17:48:19 -0600
Encoding: 28 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, November 01, 1996 5:37 PM, Louis A. Mamakos[SMTP:louie at UU.NET] wrote:
@
<snip many items which we are largely in agreement on>
@
@ Further, I think there are some good reasons not to have 64 or 128
@ root name servers. You'll make the packet sizes large enough to
@ require TCP transport as the UDP responses are too large to be
@ returned unfragmented. It was this issue which prompted the
@ re-naming of the root name servers into the "ROOT-SERVERS.NET"
@ domain, so that the common substring could be omitted by the
@ "compression" algorithm used to encode the DNS packets.
@
@ I'm guessing that you'd propose to not return the full set, and then
@ change the way that the DNS works?
@
These are common misconceptions which can be cleared up
as you get more involved in the actual nuts and bolts of the
DNS and the Internet.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa18493; 1 Nov 96 18:58 EST
Received: from sunflower.singnet.com.sg by ietf.org id aa18288;
1 Nov 96 18:57 EST
Received: from LOCALNAME (ts900-6009.singnet.com.sg [165.21.162.93]) by sunflower.singnet.com.sg (8.6.12/8.6.9) with SMTP id HAA20054; Sat, 2 Nov 1996 07:56:20 +0800
Date: Sat, 2 Nov 1996 07:56:20 +0800
Message-Id: <199611012356.HAA20054 at sunflower.singnet.com.sg>
X-Sender: kcheekai at singnet.com.sg
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: daniel at sems.co.jp, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Koo Chee Kai <kcheekai at singnet.com.sg>
Subject: Re: Sorry to intrude.
Source-Info: From (or Sender) name not authenticated.
Try sending a mail to
ietf-request at IETF.CNRI.Reston.VA.US
with the subject as "unsubscribe"
Good luck.
At 01:07 PM 10/31/96 -0800, Daniel Minoru Saito wrote:
>I hate to protrude into this nice little conversation in regards to `The
>cartel begins to crumble...` but if anyone could show me the way out of
>this listserver. It isn`t the type of conversation that I was looking
>for.
>
>I tried various times requesting the listserver to UNSUBSCRIBE me but no
>luck.
>
>So I have three options:
>
>1.) Ask politely on the listserver newsgroup in how to get out.
>2.) Be a complete ASSHOLE in my efforts and get kicked out.
>3.) Hack into the listserver and then crash the whole listserver at
>listproc at wugate.wustl.edu.
>
Received: from ietf.org by ietf.org id aa20163; 1 Nov 96 19:14 EST
Received: from ng.netgate.net by ietf.org id aa19770; 1 Nov 96 19:11 EST
Received: from [205.214.160.111] (d14.netgate.net [205.214.160.46]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA20602; Fri, 1 Nov 1996 16:20:50 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v0310060bae9fd83e85fb at [205.214.160.111]>
In-Reply-To: <199611011517.JAA08564 at Mercury.mcs.net>
References:
<c=DK%a=_%p=MAINZ%l=MOONRAKER-961101093446Z-992 at Moonraker.mainz.dk> from
"Kim Wohlert" at Nov 1, 96 10:34:46 am
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 1 Nov 1996 15:45:38 -0800
To: Karl Denninger <karl at mcs.net>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: The cartel begins to crumble?
Cc: Kim Wohlert <Kim.Wohlert at mainz.dk>, ietf at ietf.org, frezza at interramp.com
Source-Info: From (or Sender) name not authenticated.
At 7:17 AM -0800 11/1/96, Karl Denninger wrote:
>Again, the difference here is that I'm looking for consensus, not ramming
>things down people's throats. And I'm not DOING anything; the machine makes
>and enforces the rules (which we agree on) :-)
Karl,
The service/proposal that you outlined in a previous note looks
interesting. It's detailed and clear. I don't have an opinion, yet, about
its completeness, adequacy or viability but it does have meat on it and is
worth some chewing. For starters, I'd like to explore the underlying
principles. You stated some of those already but I'd like to make sure I
heard things correctly:
1. There IS a central authority. It is a machine that accepts
registrations in a strict and mechanical first-come/first-served fashion.
2. Limits would be applied to the number of "new" registrations and
organization could get within a window of time, to avoid registration
stuffing.
3. Registrations would have to go into service within a window of time or
be forfitted.
Some questions:
4. How does financial responsibility get evaluated and enforced? Do they
have the money to administer a TLD? -- yes I know that the computer
operations part can be kept trivial but what about the rest, such as
oversight and enforcement?
5. What are the operations requirements for iTLD registries? Are there
performance requirements they must meet, at the risk of having the award
taken back?
6. How is continuity of support ensured when a registry goes away? If the
unthinkable happens and the registry operator for .BIZ disappears then how
do we make sure that the unfortunate end users do not have their much
relied-upon domain name cease to function?
7. ... I know there are more, basic questions to ask, but this is a good
place to stop.
Item 1 asserts that all new registrations are acceptable to make
under only and exactly this one award policy. That leads to the question
of alternate (i.e., multiple) award policies. Is there a basis for
believing that the first-come/first-served policy is inadequate in some/all
cases? If only for some, how do we distinguish?
You say that you want the award service put in place by consensus
rather than fiat. Sounds good to me. But that leads to a question about
the consensus process. The historical award process was by fiat, in that a
single office (IANA) made the specific awards, but it was supported by a
(then) broad base of Internet organizations, so there was an important
consensus process that caused the "delegation" to the IANA. (For those not
familiar with the history, i'd say this summary is technically accurate but
misses the flavor. In the old days, none of this stuff was valuable or
desired, but it was necessary. I.e., the administrative work was at best
distasteful; IANA stepped in to do the work because it needed to be done.
It hardly covered anyone in glory. Times change, of course, except for the
continued lack of glory...)
Anyhow, the world is a different place; the Internet has grown; the
breadth of input and participation needs also to grow. We should describe
an acceptable consensus process. For starters, I'd like to see a summary
of the consensus process that is in place for the mechanism you are
describing.
This is intended as a dialogue, so I'll stop here and look for
responses.
d/
ps. Full disclusure: I'm on the newly-formed IAHC. I was named by IANA
but have no particular affiliation; i.e., I don't "represent" any
particular group other than the pure brainwashing that 25 years of working
in the Internet technical community has no doubt accomplished. My explicit
agenda is to see that the enhancement to TLD registry administration is
achieved well and soon. Period.
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa20166; 1 Nov 96 19:14 EST
Received: from ng.netgate.net by ietf.org id aa19857; 1 Nov 96 19:12 EST
Received: from [205.214.160.111] (d14.netgate.net [205.214.160.46]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA20718; Fri, 1 Nov 1996 16:21:57 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v0310061baea03dbe6367 at [205.214.160.111]>
In-Reply-To: <9610018468.AA846874750 at ncr.disa.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 1 Nov 1996 15:55:21 -0800
To: David Gaon <gaond at ncr.disa.mil>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re[3]: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 7:52 AM -0800 11/1/96, David Gaon wrote:
> I am suggesting that the determination of the ""exact network address of
> the recipient port the user wishes to reach (e.g. 162.02.34.89)"" is
>left
> to the user and is done offline (with respect to the communications
> infrastructure). The user, on deciding whom he wants to reach, either
> types in the corresponding port number in his e-mail or web access,
>or he
I believe you are confusing naming with addressing. Machines need
names that are separate from their addresses in order to allow the address
to change. imc.org changed addresses last week. The only reason this was
invisible to the many users who go through it (primarily through the
mailing lists it hosts) was because they use the string imc.org rather than
a specific IP address. Hence, the late binding of the string to the
address is an important aspect to Internet operation.
It isn't as simple as doing this "offline"; it needs to be a
performant part of the Internet active Internet. Hence, the more ambitious
requirements for a directory service, they you suggest, are not appropriate
to the task, in my view.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa21113; 1 Nov 96 19:28 EST
Received: from cnri by ietf.org id aa20980; 1 Nov 96 19:26 EST
Received: from pinky.junction.net by CNRI.Reston.VA.US id aa24566;
1 Nov 96 19:26 EST
Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id QAA24231; Fri, 1 Nov 1996 16:39:58 -0800
Received: from localhost (michael at localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id QAA15721; Fri, 1 Nov 1996 16:21:02 -0800
Date: Fri, 1 Nov 1996 16:21:00 -0800 (PST)
Sender:ietf-request at ietf.org
From: Michael Dillon <michael at memra.com>
To: "'Louis A. Mamakos'" <louie at uu.net>
cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>
Subject: RE: Folling the crumbling cartel - a note about thread following
In-Reply-To: <01BBC81C.DED103A0 at webster.unety.net>
Message-ID: <Pine.BSI.3.93.961101161255.13113N-100000 at sidhe.memra.com>
Organization: Memra Software Inc. - Internet consulting
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Fri, 1 Nov 1996, Jim Fleming wrote:
> @ I'm guessing that you'd propose to not return the full set, and then
> @ change the way that the DNS works?
> @
>
> These are common misconceptions which can be cleared up
> as you get more involved in the actual nuts and bolts of the
> DNS and the Internet.
These kind of insults are commonly used by agents provocateurs in order to
goad their opponents into doing or saying something stupid in order to
further the vested interests of the agent provocateur.
I'm not sure exactly what Fleming is up to here but it is clear that he
has an agenda. I believe this agenda is influenced by the CPSR (Computer
Professionals for Social Resposibility) and by the anti-authoritarian
sentiments that sparked much of the 60's revolutionary attitude. It
appears that Fleming believes the IETF and ISOC are a CIS-controlled
oligarchy; an old boys club that is attempting to stifle the people of the
world in using the greatest communications tool ever created.
While the IETF and ISOC are most certainly not lily-white, I don't happen
to share Fleming's sinister beliefs. But I think it fair to warn all of
you on the IETF list that prolonged and insistent attacks on Fleming will
only make him appear heroic to the uninitiated. So, don't lose your cool
and reply to him emotionally. Just say enough to correct his errors for
the large audience of lurkers and then let him be.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael at memra.com
Received: from ietf.org by ietf.org id aa22234; 1 Nov 96 19:36 EST
Received: from cs.columbia.edu by ietf.org id aa21805; 1 Nov 96 19:34 EST
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.2/8.6.6) with ESMTP id TAA08481 for <ietf at ietf.org>; Fri, 1 Nov 1996 19:31:52 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.2/8.6.6) with SMTP id TAA02029 for <ietf at ietf.org>; Fri, 1 Nov 1996 19:31:52 -0500 (EST)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <327A9678.11E2 at cs.columbia.edu>
Date: Fri, 01 Nov 1996 19:31:52 -0500
Sender:ietf-request at ietf.org
From: Henning Schulzrinne <schulzrinne at cs.columbia.edu>
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: ietf at ietf.org
Subject: Re: The cartel begins to crumble?
References: <199611012149.QAA03325 at jekyll.piermont.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Wouldn't the likely outcome of this be that almost all second-level .com
domains would simply become TLDs? Certainly makes life easier for the
CompuServe crowd - just type "go ibm"...
--
Henning Schulzrinne email: schulzrinne at cs.columbia.edu
Dept. of Computer Science phone: +1 212 939-7042
Columbia University fax: +1 212 666-0140
New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs
Received: from ietf.org by ietf.org id aa22332; 1 Nov 96 19:37 EST
Received: from Kitten.mcs.com by ietf.org id aa22101; 1 Nov 96 19:36 EST
Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.0/8.8.Beta.3) with SMTP id SAA21229; Fri, 1 Nov 1996 18:35:08 -0600 (CST)
Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15)
id <m0vJU2u-000DQSC at mailbox.mcs.com>; Fri, 1 Nov 96 18:34 CST
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.Beta.3) id SAA15592; Fri, 1 Nov 1996 18:34:44 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611020034.SAA15592 at Jupiter.Mcs.Net>
Subject: Re: The cartel begins to crumble?
To: Dave Crocker <dcrocker at brandenburg.com>
Date: Fri, 1 Nov 1996 18:34:43 -0600 (CST)
Cc: karl at mcs.net, Kim.Wohlert at mainz.dk, ietf at ietf.org, frezza at interramp.com
In-Reply-To: <v0310060bae9fd83e85fb at [205.214.160.111]> from "Dave Crocker" at Nov 1, 96 03:45:38 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> Karl,
>
>The service/proposal that you outlined in a previous note looks
> interesting. It's detailed and clear. I don't have an opinion, yet, about
> its completeness, adequacy or viability but it does have meat on it and is
> worth some chewing. For starters, I'd like to explore the underlying
> principles. You stated some of those already but I'd like to make sure I
> heard things correctly:
>
> 1. There IS a central authority. It is a machine that accepts
> registrations in a strict and mechanical first-come/first-served fashion.
Correct.
> 2. Limits would be applied to the number of "new" registrations and
> organization could get within a window of time, to avoid registration
> stuffing.
Correct. "Registration stuffing" is an interesting phrase; I like it.
Basically we're trying to prevent ballot-box-stuffing games and the like;
the intent here is that if you want to really run a registry that's fine,
but denying someone else the same ability is not.
> 3. Registrations would have to go into service within a window of time or
> be forfitted.
Correct. You don't want to have too long of a period (to prevent stuffing
again) nor do you want an organization to be able to reclaim a name they
try to get and then forfeit (again, prevention of denial-of-service attack
games)
> Some questions:
>
> 4. How does financial responsibility get evaluated and enforced? Do they
> have the money to administer a TLD? -- yes I know that the computer
> operations part can be kept trivial but what about the rest, such as
> oversight and enforcement?
I don't know how you CAN do that. And why is it relavent? My argument
has been all along that this is a customer <> registry issue. You're not
protected *now* if your provider dies, and in fact the disruption that can
cause could be, in some cases, severely damaging or even terminal to your
business (non-portable addresses made THAT a reality.) But we live with
it today, don't we?
The non-portable address problem has caused some of our incoming customers
REAL headaches. We have had people who just can't change providers BECAUSE
we can't route those addresses from 207.x.x.x, and nothing we can do fixes
this problem for them. They're screwed, absolutely and completely, and some
of them went out and did really crazy things (like embedding some of these
addresses into remote devices which are then shipped to offices around the
US, etc).
Changing providers could be a $100,000+ event for these people. Yet we, as
providers, are asked to "accept" this tying arrangement (frankly, I think it
stinks -- but that's another thread.)
There are people who will only buy computers from IBM. There will be people
who won't speculate here either. And they'll likely pay for it. So be it;
that's the nature of a free market.
If I buy a computer and it breaks, and I bought from Joe's Clones, and he's
gone, I eat the hardware in many if not most cases. That's the nature of
business risk.
As long as people aren't practicing fraud (and if they are, there are laws
about this already) I just don't understand the problem here. I believe in
full disclosure. Given that, let people do their own evaluations of the
risk/reward equation.
The solution to ignorance is education.
> 5. What are the operations requirements for iTLD registries? Are there
> performance requirements they must meet, at the risk of having the award
> taken back?
I believe it has been agreed-upon that registries should be able to
demonstrate multi-homed connectivity. You can meet this requirement in
many ways; you can have it yourself, OR one of your servers could be on
someone else's network. I believe its also reasonable to require at
least DS-1 speeds on external connections to these machines.
I don't believe we can reasonably go beyond that. Even today's DNS root
servers frequently suck through no fault of the owners (backbone fun and
games within some of the nationals cause a good part of it).
> 6. How is continuity of support ensured when a registry goes away? If the
> unthinkable happens and the registry operator for .BIZ disappears then how
> do we make sure that the unfortunate end users do not have their much
> relied-upon domain name cease to function?
Zones are transferrable. Its easily arguable that this is a self-healing
problem to a large extent. A dead registry is going to be a tangible, and
valuable, asset (assuming it has registrants in it -- if not the entire
discussion is moot and irrelavent).
If it has value, it'll be auctioned. In the meantime, how difficult is
it for anyone to pull the zone on a somewhat-regular basis and stash it?
named-xfer works just fine..... so a simple operational requirement is
that you have *someone* who does this on the network *somewhere*, and in
the event you disappear the zone can be published on someone else's
servers until the status of that asset is determined (see below).
Changing the delegations in the root is reasonably trivial in this event.
This is basically what I had said in my draft; the contents of the zone file
are deemed PD information. REGISTRANT data is another matter; I doubt very
much if anyone would approve of their credit-card number being public
domain! However, the NS lines are simple and tough to argue as not being
public information.
In the case of failure and a needed update during the interim, the guy who
has the NSs pointed to calls the shots (since he's obviously the one who is
actually providing the DNS service for that SLD).
>Item 1 asserts that all new registrations are acceptable to make
> under only and exactly this one award policy. That leads to the question
> of alternate (i.e., multiple) award policies. Is there a basis for
> believing that the first-come/first-served policy is inadequate in some/all
> cases? If only for some, how do we distinguish?
I don't see how it can be. It can be argued that someone will try to grab
.IBM (other than IBM corporation, of course). The problem is that as soon
as you set up ANYTHING that looks like a tribunal, you're asking for all the
problems that NSI has now.
You just can't DO that without the consent and delegation from *ALL* the
national governments involved. There ARE cases where administrative law is
delegated to agencies, but that's US-centric (or some country-centric).
Moving the thing to Switzerland doesn't fix this, any more than moving it
to Japan or the UAE!
Stay the dickens away from the legalities. The cleaner your hands, the
less likelihood that someone will sue the people who maintain the
mutual-exclusion server operator.
If someone REALLY thinks they've been wronged, there are the same solutions
available to them that there are for anyone else who believes that the issue
is serious enough to go chase the "guilty" party. If you get involved in
this then the whole issue of jurisdiction comes into play instantly,
differing laws, etc.
I believe the only defensible path here is to not play at all.
>You say that you want the award service put in place by consensus
> rather than fiat. Sounds good to me. But that leads to a question about
> the consensus process. The historical award process was by fiat, in that a
> single office (IANA) made the specific awards, but it was supported by a
> (then) broad base of Internet organizations, so there was an important
> consensus process that caused the "delegation" to the IANA.
The problem was that at that time it was agreed that the IANA was working in
the public trust and no money was changing hands. Its easy to argue for
public trusteeship (and consensus) in that event.
>Anyhow, the world is a different place; the Internet has grown; the
> breadth of input and participation needs also to grow. We should describe
> an acceptable consensus process. For starters, I'd like to see a summary
> of the consensus process that is in place for the mechanism you are
> describing.
See above! And let's continue talking; I'm nowhere near out of ideas :-)
> ps. Full disclusure: I'm on the newly-formed IAHC. I was named by IANA
> but have no particular affiliation; i.e., I don't "represent" any
> particular group other than the pure brainwashing that 25 years of working
> in the Internet technical community has no doubt accomplished. My explicit
> agenda is to see that the enhancement to TLD registry administration is
> achieved well and soon. Period.
Good. That's an open, and up-front start.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa23234; 1 Nov 96 19:48 EST
Received: from cnri by ietf.org id aa23053; 1 Nov 96 19:47 EST
Received: from ng.netgate.net by CNRI.Reston.VA.US id aa24937;
1 Nov 96 19:47 EST
Received: from [205.214.160.111] (d17.netgate.net [205.214.160.49]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA22845; Fri, 1 Nov 1996 16:56:21 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100620aea046736f92 at [205.214.160.111]>
In-Reply-To: <01BBC81C.DED103A0 at webster.unety.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 1 Nov 1996 16:31:32 -0800
To: Jim Fleming <JimFleming at unety.net>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: RE: Folling the crumbling cartel - a note about thread following
Cc: "ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
'New Newdom' <newdom at vrx.net>
Source-Info: From (or Sender) name not authenticated.
At 3:48 PM -0800 11/1/96, Jim Fleming wrote:
>These are common misconceptions which can be cleared up
>as you get more involved in the actual nuts and bolts of the
>DNS and the Internet.
Wow.
Jim, you are suggesting that things will become clearer to Louis as
he becomes more involved in the DNS and the Internet? Forgive me, but
Louis has been involved in the direct operation of the Internet for many,
many years. Longer than, say, yourself, I suspect.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa23214; 1 Nov 96 19:48 EST
Received: from ng.netgate.net by ietf.org id aa23067; 1 Nov 96 19:47 EST
Received: from [205.214.160.111] (d17.netgate.net [205.214.160.49]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id QAA22888; Fri, 1 Nov 1996 16:56:29 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100621aea04786b030 at [205.214.160.111]>
In-Reply-To: <01BBC7E4.B54E5060 at webster.unety.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Fri, 1 Nov 1996 16:37:02 -0800
To: Jim Fleming <JimFleming at unety.net>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: RE: Re[2]: The cartel begins to crumble?
Cc: David Gaon <gaond at ncr.disa.mil>, "ietf at ietf.org" <ietf at ietf.org>
Source-Info: From (or Sender) name not authenticated.
At 9:06 AM -0800 11/1/96, Jim Fleming wrote:
>The DNS "mapping" system is evolving. As noted in my notes
>below, there are new features being developed like the SRV
>records which may not be "completely deterministic", thus
>things like PRIORITY and WEIGHT are being proposed.
Jim, et al,
The DNS has been 'evolving' ever since its inception.
Interestingly, almost none of that evolution has ever succeeded. Many,
many enhancements have been proposed. Perhaps the most ambitious was
Hessiod as part of Project Athena at MIT, 10 years ago.
One can be frustrated by this lack of infrastructure enhancement,
or one can be thankful. Frustrated because most of the suggestions over
the years have been for obviously and significantly useful features and
it's a darn shame we don't have them available. Thankful because the DNS
has remained pretty stable...
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa24445; 1 Nov 96 19:57 EST
Received: from zephyr.isi.edu by ietf.org id aa24037; 1 Nov 96 19:56 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA27922>; Fri, 1 Nov 1996 16:55:07 -0800
Message-Id: <199611020055.AA27922 at zephyr.isi.edu>
To: ietf at ietf.org, imr at isi.edu
Subject: Internet Monthly Report for July, 1996
Cc: imr-ed at isi.edu
Date: Fri, 01 Nov 96 16:55:07 PST
Sender:ietf-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
Source-Info: From (or Sender) name not authenticated.
July 1996
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to "IMR at ISI.EDU".
`````````````````````````````````````````````````````````````````````
The Internet Monthly Report mailing list is now managed by MajorDomo at
ISI.EDU. The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be ADDED or DELETED from the Internet Monthly report list
should be sent to "majordomo at isi.edu" with the message body either
"subscribe imr" or "unsubscribe imr".
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
or URL: http://www.isi.edu/in-notes/imr/
IMR Editor [Page 1]
Internet Monthly Report July 1996
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 11
Registration Services . . . . . . . . . . . . . . . . . page 11
Directory Services. . . . . . . . . . . . . . . . . . . page 13
US Domain Registry. . . . . . . . . . . . . . . . . . . page 13
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 16
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 20
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 24
IMR Editor [Page 2]
Internet Monthly Report July 1996
INTERNET ARCHITECTURE BOARD
The minutes of the IAB back to 1990 are available for anonymous ftp
access on host ftp.isi.edu, directory /pub/IAB, or via the IAB
World-Wide Web page with URL http://www.iab.org/iab/.
Brian Carpenter IAB Chair
INTERNET ENGINEERING REPORTS
----------------------------
IETF Monthly Report for July, 1996
1. The IETF met in Montreal, Quebec, Canada from June 24-28, 1996.
While we're still working on the numbers, this was the best
attended meeting in the IETF's history with over 1200 registrants.
Closing out the year, the IETF will be returning to San Jose,
California from December 9-13, 1996. Following that, the IETF
travels to Memphis, Tennessee where Federal Express will be the
host. This meeting will be held April 7-11, 1997. We are currently
working on returning to Europe in August, 1997.
Once all the arrangements have been made, notifications will be
sent to the IETF Announcement list. Remember that information on
future IETF meetings can be always be found in the file 0mtg-
sites.txt which is located on the IETF shadow directories. This
information can also be viewed from the IETF Home Page on the Web.
The URL is:
http://www.ietf.org
2. The minutes of the IESG teleconferences have been publicly
available on the IETF Shadow directories since 1991. These files
are placed in the /ftp/iesg directory.
The following IESG minutes have been added:
June 13, 1996 (iesg.96-06-13)
July 11, 1996 (iesg.96-07-11)
3. The IESG approved or recommended the following 16 Protocol
Actions during the month of July, 1996:
o Definitions of Managed Objects for IEEE 802.12 Interfaces be
published as a Proposed Standard.
IMR Editor [Page 3]
Internet Monthly Report July 1996
o OSI NSAPs and IPv6 be published as an Experimental Protocol.
o The Simple Public-Key GSS-API Mechanism (SPKM) be published
as a Proposed Standard.
o Uniform Resource Agents (URAs) be published as an
Experimental Protocol.
o A Method for the Transmission of IPv6 Packets over FDDI
Networks be published as a Proposed Standard.
o Definitions of Managed Objects for Data Link Switching using
SNMPv2 be published as a Proposed Standard.
o Support for Multicast over UNI 3.0/3.1 based ATM Networks.
be published as a Proposed Standard.
o RTP Payload Format of Sun's CellB Video Encoding be published
as a Proposed Standard.
o RTP Payload Format for JPEG-compressed Video be published as
a Proposed Standard.
o RTP payload format for H.261 video streams be published as
a Proposed Standard.
o RTP Payload Format for MPEG1/MPEG2 Video be published as a
Proposed Standard.
o PPP Stac LZS Compression Protocol be published as an
Informational RFC.
o TCP Selective Acknowledgment Options be published as a
Proposed Standard.
o IP Version 6 over PPP be published as a Proposed Standard.
o Remote Network Monitoring Management Information Base version
2 be published as a Proposed Standard.
o Remote Network Monitoring MIB Protocol Identifiers be
published as a Proposed Standard.
4. The IESG issued 21 Last Calls to the IETF during the month of
July, 1996:
o Interoperation Between DHCP and BOOTP <RFC1534> for
consideration as a Draft Standard.
IMR Editor [Page 4]
Internet Monthly Report July 1996
o Clarifications and Extensions for the Bootstrap Protocol
<RFC1542> for consideration as a Draft Standard.
o The PPP SNA Control Protocol (SNACP)
<draft-ietf-pppext-snacp-01> for consideration as a Proposed
Standard.
o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
<draft-crispin-imap-base-04> for consideration as a Proposed
Standard.
o INTERNET MESSAGE ACCESS PROTOCOL - OBSOLETE SYNTAX
<draft-crispin-imap-obsolete-00> for consideration as an
Informational RFC.
o IMAP4 COMPATIBILITY WITH IMAP2BIS
<draft-crispin-imap-compat-00> for consideration as an
Informational RFC.
o IMAP/POP AUTHorize Extension for Simple Challenge/Response
<draft-klensin-cram-01> for consideration as a Proposed
Standard.
o Service Location Protocol <draft-ietf-svrloc-protocol-14>
for consideration as a Proposed Standard.
o TCP Slow Start, Congestion Avoidance, Fast Retransmit, and
Fast Recovery Algorithms <draft-stevens-tcpca-spec-01> for
consideration as a Proposed Standard.
o Entity MIB <draft-ietf-entmib-entmib-06> for consideration
as a Proposed Standard.
o SMTP Service Extension for Returning Enhanced Error Codes
<draft-freed-smtperror-01> for consideration as a Proposed
Standard.
o Multipurpose Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies <draft-ietf-822ext-mime-imb-07>
for consideration as a Draft Standard.
o Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types <draft-ietf-822ext-mime-imt-05> for consideration as
a Draft Standard.
IMR Editor [Page 5]
Internet Monthly Report July 1996
o MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text
<draft-ietf-822ext-mime-hdrs-00> for consideration as a Draft
Standard.
o Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures <draft-ietf-822ext-mime-reg-04> for
consideration as a Best Current Practices RFC.
o Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples
<draft-ietf-822ext-mime-conf-06> for consideration as a Draft
Standard.
o A Proposed Extension to HTTP : Digest Access Authentication
<draft-ietf-http-digest-aa-04> for consideration as a
Proposed Standard.
o "Data: URL scheme" <draft-masinter-url-data-01> for
consideration as a Proposed Standard.
o The PPP Internetwork Packet Exchange Control Protocol (IPXCP)
<RFC1552> for consideration as a Draft Standard.
o Remote Authentication Dial In User Service (RADIUS)
<draft-ietf-radius-radius-05> for consideration as a Proposed
Standard.
o RADIUS Accounting <draft-ietf-radius-accounting-05> for
consideration as an Informational RFC.
5. A total of 99 Internet-Draft actions were taken during the month
of July, 1996:
(Revised draft (o), New Draft (+) )
(avt) o RTP payload format for H.261 video streams
<draft-ietf-avt-h261-02.txt>
(ion) o NBMA Next Hop Resolution Protocol (NHRP)
<draft-ietf-rolc-nhrp-09.txt>
(pppext) o PPP Stac LZS Compression Protocol
<draft-ietf-pppext-stacker-10.txt>
(avt) o RTP Payload Format of Sun's CellB Video Encoding
<draft-ietf-avt-cellb-08.txt>
(822ext) o Multipurpose Internet Mail Extensions (MIME) Part
One: Format of Internet Message Bodies
<draft-ietf-822ext-mime-imb-07.txt>
IMR Editor [Page 6]
Internet Monthly Report July 1996
(avt) o RTP Payload Format for JPEG-compressed Video
<draft-ietf-avt-jpeg-03.txt>
(mailext) o Common Internet Message Headers
<draft-ietf-mailext-mail-attributes-05.txt>
(mailext) o The Supersedes and Expires e-mail headers
<draft-ietf-mailext-new-fields-05.txt>
(intserv) o Specification of Guaranteed Quality of Service
<draft-ietf-intserv-guaranteed-svc-05.txt>
(pppext) o PPP Extensible Authentication Protocol (EAP)
<draft-ietf-pppext-eap-auth-02.txt>
(822ext) o Multipurpose Internet Mail Extensions (MIME) Part
Two: Media Types <draft-ietf-822ext-mime-imt-05.txt>
(822ext) o Multipurpose Internet Mail Extensions (MIME) Part
Five: Conformance Criteria and Examples
<draft-ietf-822ext-mime-conf-06.txt>
(822ext) o Multipurpose Internet Mail Extensions (MIME) Part
Four: Registration Procedures
<draft-ietf-822ext-mime-reg-04.txt>
(rmonmib) o Remote Network Monitoring Management Information
Base version 2
<draft-ietf-rmonmib-rmonmib-v2-03.txt>
(entmib) o Entity MIB <draft-ietf-entmib-entmib-06.txt>
(none) o Common NNTP Extensions
<draft-barber-nntp-imp-05.txt>
(none) o TELNET CHARSET Option
<draft-gellens-telnet-char-option-03.txt, .ps>
(vgmib) o Definitions of Managed Objects for IEEE 802.12
Repeater Devices
<draft-ietf-vgmib-repeater-dev-02.txt>
(atommib) o Definitions of Textual Conventions and
OBJECT-IDENTITIES for ATM Management
<draft-ietf-atommib-atm2TC-04.txt>
(radius) o RADIUS Accounting
<draft-ietf-radius-accounting-05.txt>
(radius) o Remote Authentication Dial In User Service (RADIUS)
<draft-ietf-radius-radius-05.txt>
(asid) o A MIME Content-Type for Directory Information
<draft-ietf-asid-mime-direct-02.txt>
(none) o Simple Authentication and Session Layer
<draft-myers-auth-sasl-04.txt>
(idmr) o Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification
<draft-ietf-idmr-pim-sm-spec-04.txt, .ps>
(rip) o Protocol Analysis for Triggered RIP
<draft-ietf-rip-trigger-analysis-01.txt>
(none) o The Model Primary Content Type for Multipurpose
Internet Mail Extensions
<draft-nelson-model-mail-ext-04.txt>
IMR Editor [Page 7]
Internet Monthly Report July 1996
(none) o INTERNET REGISTRY IP ALLOCATION GUIDELINES
<draft-hubbard-registry-guidelines-03.txt>
(cat) o Extended Generic Security Service APIs: XGSS-APIs
Access control and delegation extensions
<draft-ietf-cat-xgssapi-acc-cntrl-01.txt>
(rsvp) o RSVP Management Information Base
<draft-ietf-rsvp-mib-02.txt>
(http) o Hypertext Transfer Protocol -- HTTP/1.1
<draft-ietf-http-v11-spec-06.txt, .ps>
(intserv) o Intgrated Services Management Information Base
<draft-ietf-intserv-mib-02.txt>
(none) + Local Mail Transfer Protocol
<draft-myers-lmtp-00.txt>
(none) o IMAP4 QUOTA extension
<draft-myers-imap-quota-01.txt>
(none) o IMAP4 ACL extension <draft-myers-imap-acl-03.txt>
(pppext) o The PPP Bandwidth Allocation Protocol (BAP) The PPP
Bandwidth Allocation Control Protocol (BACP)
<draft-ietf-pppext-bacp-04.txt>
(idmr) o Protocol Independent Multicast-Dense Mode (PIM-DM):
Protocol Specification
<draft-ietf-idmr-pim-dm-spec-02.txt, .ps>
(ids) o X.500 Implementations Catalog-96
<draft-ietf-ids-x500-imps-02.txt>
(dhc) o Interaction between DHCP and DNS
<draft-ietf-dhc-dhcp-dns-01.txt>
(none) o "Data: URL scheme" <draft-masinter-url-data-01.txt>
(asid) + WHOIS++ URL Specification
<draft-ietf-asid-whois-url-00.txt>
(idmr) o Distance Vector Multicast Routing Protocol
<draft-ietf-idmr-dvmrp-v3-02.txt, .ps>
(none) o Server Cache Synchronization Protocol (SCSP) - NBMA
<draft-luciani-rolc-scsp-03.txt>
(ion) + Multicast Server Architectures for MARS-based ATM
multicasting. <draft-ietf-ion-marsmcs-00.txt, .ps>
(none) o IMAP/POP AUTHorize Extension for Simple
Challenge/Response <draft-klensin-cram-01.txt>
(http) o Proposed HTTP State Management Mechanism
<draft-ietf-http-state-mgmt-03.txt, .ps>
(rsvp) o RSVP Diagnostic Messages
<draft-ietf-rsvp-diagnostic-msgs-01.txt>
(none) o SMTP Service Extension for Returning Enhanced Error
Codes <draft-freed-smtperror-01.txt>
(none) o UTF-8, a transformation format of Unicode and ISO
10646 <draft-yergeau-utf8-01.txt>
(none) o Top Level Domain Classification and Catagorization
<draft-higgs-tld-cat-02.txt>
IMR Editor [Page 8]
Internet Monthly Report July 1996
(none) o Source directed access control on the Internet.
<draft-bradner-access-control-01.txt>
(mhtml) o MIME E-mail Encapsulation of Aggregate Documents,
such as HTML (MHTML) <draft-ietf-mhtml-spec-02.txt>
(ipsec) o HMAC-MD5 IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-md5-01.txt>
(ipsec) o HMAC-SHA IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-sha-01.txt>
(mhtml) o Sending HTML in E-mail, an informational supplement
to RFC ???: MIME E-mail Encapsulation of Aggregate
HTML Documents (MHTML)
<draft-ietf-mhtml-info-02.txt>
(oncrpc) o RPC: Remote Procedure Call Protocol Specification
Version 2 <draft-ietf-oncrpc-remote-01.txt>
(none) o Payload Format Issues for Redundant Encodings in RTP
<draft-perkins-rtp-redundancy-01.txt, .ps>
(none) o YAAP: Yet Another Authentication Protocol
<draft-zorn-yaap-01.txt>
(none) o Dialup Roaming Requirements
<draft-zorn-dial-roam-req-01.txt>
(none) + Proposal for establishing the IETF as an independent
organization
<draft-rutkowski-ietf-poised95-orgs-00.txt>
(none) + Scheduling Wide-area Transport Protocol SWTP
<draft-spencer-swtp-00.txt>
(none) o Large Responses to DNS Queries (DNS MORE)
<draft-andrews-dns-more-02.txt>
(none) + Management Information Base for Frame Relay DTE
Extensions for SVC's and Data Compression over Frame
Relay <draft-cochrane-frmib-dte-00.txt>
(none) + GPS^IP <draft-mangione-ipv6-gps-alt-00.txt>
(ion) + Definitions of Managed Objects for the NBMA Next Hop
Resolution Protocol (NHRP)
<draft-ietf-ion-nhrp-mib-00.txt>
(none) + SMTP Service Extension for Command Pipelining
<draft-freed-smtp-pipeline-00.txt>
(none) + Enhanced Remote Authentication Dial In User Service
(RADIUS) Dynamic Filter Change
<draft-calhoun-enh-radius-filter-00.txt>
(none) + Enhanced Remote Authentication Dial In User Service
(RADIUS) Resource Management Extension
<draft-calhoun-enh-radius-res-mgmt-00.txt>
(none) + Framework for IP Provider Metrics
<draft-almes-ippm-framework-00.txt>
(find) + The Common Indexing Protocol (CIP)
<draft-ietf-find-new-cip-00.txt>
(none) o Adopt MacBinary II Mac File Encoding for FTP
Transfers <draft-mityok-macbin1-01.txt>
IMR Editor [Page 9]
Internet Monthly Report July 1996
(none) o IMAP4 non-synchroniziong literals
<draft-myers-imap-literal-01.txt>
(none) o IMAP4 OPTIMIZE-1 extension
<draft-myers-imap-optimize-01.txt>
(none) + A Professional Profile for Audio and Video over RTP?
<draft-harris-rtp-pro-av-00.txt>
(ion) + Multiprotocol Interconnect over Frame Relay
<draft-ietf-ion-fr-update-00.txt>
(none) + SBM (Subnet Bandwidth Manager): A Proposal for
Admission Control over Ethernet
<draft-yavatkar-sbm-ethernet-00.txt>
(intserv) + Integrated Services Management Information Base
Guaranteed Service Extensions
<draft-ietf-intserv-guaranteed-mib-00.txt>
(none) + Simple Scheduling Transfer Protocol
<draft-hanna-sstp-00.txt>
(none) + A Proposal for an IETF "Problems To Be Solved"
Database <draft-richardson-database-resolve-00.txt>
(none) + MacBinary and Binhex 4.0 considered harmful
<draft-newman-macbin-binhex-harmful-00.txt>
(none) + Vertical Aggregation: A Strategy for FIB Reduction
<draft-richardson-fib-reduction-00.txt>
(none) + Issues affecting MARS Cluster Size
<draft-armitage-ion-cluster-size-00.txt>
(svrloc) + Service Location Modifications for IPv6
<draft-ietf-svrloc-IPv6-00.txt>
(none) + Making Postscript and Acrobat Files International
<draft-palme-int-print-00.txt>
(none) + Compression Payload for Use with IP Security
<draft-thayer-seccomp-00.txt>
(none) + Internet Calendar Access Protocol (ICAP)
<draft-oleary-icap-00.txt>
(none) + Requirements for IETF Mailing Lists
<draft-moore-maillist-req-00.txt>
(none) + An Application/Properties Profile for Calendar
Information <draft-ferrell-prop-cal-00.txt>
(none) + OnOff Switch Input Object Widget for HTML Forms
<draft-robinson-tdr-html-onoff-00.txt>
(none) + A MIME Content-Type for Tagged Property Value
Storage <draft-shakib-mime-prop-00.txt>
(none) + VENUS - Very Extensive Non-Unicast Service
<draft-armitage-ion-venus-00.txt>
(oncrpc) + RPCSEC_GSS Protocol Specification
<draft-ietf-oncrpc-rpcsec_gss-00.txt>
(pppext) + Microsoft Point-To-Point Compression (MPPC) Protocol
<draft-ietf-pppext-mppc-00.txt>
(none) + A Clarification of SMIv2
<draft-perkins-smi-clarification-00.txt>
IMR Editor [Page 10]
Internet Monthly Report July 1996
(none) + A Lexical Specification for the SNMPv2 MIB Module
Language <draft-perkins-snmpv2-lex-spec-00.txt>
(none) + Internet Discussion Forum Protocol (IDFP)
<draft-martins-forums-00.txt>
(none) + Dedicated Token Ring Interface MIB
<draft-warwick-tokenring-00.txt>
(none) + Multicast pruning a necessity
<draft-hawkinson-mboned-pruning-00.txt>
(none) + Reducing the ISDN costs of Network Applications that
use TCP/IP. <draft-waters-reduce-isdn-costs-00.txt>
(none) + Virtual Tunnel Protocol Layer 2 Protocol Extension
<draft-calhoun-vtp-ext-l2-00.txt>
Steve Coya <scoya at cnri.reston.va.us>
INTERNET PROJECTS
-----------------
INTERNIC
--------
REGISTRATION SERVICES
The Following report covers the months of July, August, and
September:
I. Significant Events
* HostReg and CReg templates are now being processed automatically;
previously they had to be processed manually; now about 50% are
being processed automatically.
* The auto-registration software now sorts requests into six
groups: (1) COM, (2) ORG, (3) NET, (4) GOV, (5) EDU and (6) TLD;
this eliminates a manual step in the process and allows the ability
to put an increased priority on GOV, EDU and TLD requests.
* Plans to initiate a night shift are under development to assist
in reducing the manual processing backlog.
* Informal training was provided for Billing CSRs regarding how to
register as a contact.
IMR Editor [Page 11]
Internet Monthly Report July 1996
* Selection and training of a second shift for processing support
was completed; a full day training class was held on Saturday,
September 10th; final staffing arrangements were completed for a
night shift with a start date of September 30th.
* A "SWAT Team" of existing staff was used to reduce the backlog.
* Fax processing has become an overwhelming problem, requiring over
four full-time equivalent employees.
* Duane Stone and Carley Johnson represented the InterNIC DomReg
Section at Network World Interop.
* Testing of a share-ware Fax Server solution is going very well;
it would make faxes available as e-mail; the fax viewer works very
well on Sparc 5s and also supports sending faxes out; the MTS and
Ack/Nak interfaces still need to be completed.
* DomReg software enhancements have reduced the number of requests
that need to be processed manually from about 1,000 to 700 (30%
improvement).
* A method for gathering performance measurements was finalized and
documented.
II. Current Status
July: Email: 198,486
Postal/Fax: 4,930
Phone: 56,166
Gopher connections: 11,514 retrievals: 39,979
WAIS connections: 57,972 retrievals: 34,246
FTP connections: 61,089 retrievals: 129,768
Mailserv: 4,128
Telnet: 87,392
Http: 3,626,502
Whois client: 576,170
Whois server: 6,183,846
Rich Landers <richl at internic.net>
IMR Editor [Page 12]
Internet Monthly Report July 1996
INTERNIC DIRECTORY AND DATABASE SERVICES
The new Netfind Seed database is up on our machines. In addition,
InterNIC Directory and Database Services will become the new home
of the netfind-servers mailing list.
We have set up a Web page giving starting points for browsing
information on the US government. While most of the entries are
related to the Federal government, there is also a pointer to some
information on state and local governments.
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories. If you prefer, you can enter information
about your resource in our WWW suggestion form. The form can be
reached through our Directory of Directories Web page at:
http://ds.internic.net:80/ds/dsdirofdirs.html
by Rick Huber <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The US Domain now has an online line registration form.
Some of the processing of the requests to the third level domain
name is now automated. In particular, most requests to register
names in localities already delegated are automatically forwarded
to the administrator for that locality.
The US Domain administrator no longer makes direct registrations of
hosts, and only makes delegations of third or fourth level domain
names (such as localities).
A new policy has been added to the criteria for delegating domain
names under the US Domain:
It is the intention that the delegation of third level (for
example, locality) domain names be wide spread to many
registries. It is undesirable for one person or organization to
manage a large part of the third level names in any particular
geographic or logical area.
IMR Editor [Page 13]
Internet Monthly Report July 1996
No individual or organization shall have more than 500
delegations total in the US Domain as a whole, or more than 50
delegation in any particuilar second level (for example, a
state).
To obtain a copy of the list of other delegated localities and
subdomains not administered by the US Domain Registrar, get the
file "us-domain-delegated.txt".
URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt
For further information about the US Domain, send a message to:
US-DOMAIN at ISI.EDU, or see our WEB page:
http://www.isi.edu/us-domain
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 2899
PHONE 560
----------------------------
Total Contacts 3459
DELEGATIONS 84
FORWARDED DELEGATIONS:1373
OTHER US DOMAIN MSGS: 2002
---------------------------
Total 3459
OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or
to/from the InterNic, phone calls, modifications, application
requests, discussion and clarification of the requests, questions
about names, resolving technical problems with zone files and name
servers, and whois listings.
In addition, and not listed below, another 226 localities have been
delegated in Arizona, Arkansas, California, Colorado, Connecticut,
Delaware, Hawaii, Massachusetts, Maryland, Missouri, Montana,
Michigan Mississippi, North Carolina, New Jersey, New York,
Virginia, Vermont, Washington this month.
IMR Editor [Page 14]
Internet Monthly Report July 1996
MAJOR SUBDOMAINS DELEGATED
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
51 35 33 47 38 23 23 9 4
===================================================================
-----------------------
THIRD LEVEL DELEGATIONS
-----------------------
LOCALITIES
==========
DRAPER.UT.US WINCHESTER.KY.US
BRYN-ATHYN.PA.US SULLIGENT.AL.US
EL-PASO.CO.US SAN-FRANCISCO.CA.US
SAN-JOSE.CA.US DERRY.NH.US
WHEATON.IL.US BOLTON.MA.US
STIGLER.OK.US DEERING.NH.US
DOUGLAS.CO.US NEWBURGH.IN.US
YELM.WA.US TUMWATER.WA.US
THURSTON.WA.US LACEY.WA.US
DELHI.OH.US MUSTANG.OK.US
RICHMOND-HEIGHTS.MO.US LOS-ANGELES.CA.US
SPOKANE.WA.US GUTHRIE.OK.US
LANSING.KS.US HUNTINGDON-VALLEY.PA.US
BETHAYRES.PA.US
OTHER US DOMAIN DELEGATIONS THIS MONTH
--------------------------------------
AMHA.SHELBURNE.VT.US SEBAGOLAKEASSC.GEN.ME.US
JENKSUSA.K12.OK.US PC2ASSCS.RAYMOND.ME.US
CI.PINOLE.CA.US CITY.PEARL.MS.US
CI.HARTINGTON.NE.US CI.ROCKY-MOUNT.NC.US
GALLIVAN.BOSTON.MA.US LEXTECH.LEXINTON.MA.US
CI.CARBONDALE.IL.US CI.PASCO.WA.US
NET.BOSTON.MA.US MITRGIRLSCTS.GEN.MI.US
GRAM.MUS.MI.US CI.QUINCY.MA.US
CHAOS.GEN.CA.US HEALTH.CO.COLUMBIA.NY.US
BAPS.K12.OK.US CI.JOHNSBURG.IL.US
CI.ELLENSBURG.WA.US CLINTON.I099.K12.OK.US
CI.ANTIOCH.CA.US CI.LA-VERNE.CA.US
INWAYNET.ATLANTA.GA.US AMERISOFT.SEEKONK.MA.US
CALHOUN.CC.AL.US SNUGGLEBUNNY.WAHOO.NE.US
IMR Editor [Page 15]
Internet Monthly Report July 1996
CI.MARYSVILLE.WA.US RCID.DST.FL.US
CO.STOKES.NC.US WWW.CI.WEBSTER.NY.US
CI.HOPKINSVILLE.KY.US MCALESTER.K12.OK.US
CI.BEDFORD.TX.US TOWN.BEL-AIR.MD.US
CO.SCHOHARIE.NY.US CO.GLOUCESTER.NJ.US
SPL.LIB.AL.US CI.HUNTERSVILLE.NC.US
CI.STAYTON.OR.US CI.LOS-ALTOS.CA.US
CI.SIGNAL-HILL.CA.US CO.CALHOUN.MI.US
KIB.CO.KODIAK.AK.US JSCC.CC.AL.US
CO.BRANCH.MI.US AASR.GEN.MI.US
YRC.GEN.MI.US KT.GEN.MI.US
RAM.GEN.MI.US CI.SONARA.CA.US
THETA.BOSTON.MA.US CI.LONGVIEW.WA.US
-----------------------------------------------------------
URL: http://www.isi.edu/us-domain/
Shanthi Ranganathan (US-Domain at ISI.EDU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MERIT INTERNET ENGINEERING
--------------------------
This report summarizes July 1996 activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service and
other projects.
The Routing Arbiter project has updated its packet loss and latency
measurement code to correct recently discovered measurement biases
(see http://www.ra.net/statistics/rs.html). Previously, the packet
loss and latency measurements were carried out using the standard
Sun ping, which sent five ICMP echo request packets to each of the
Route Servers' BGP peers every fifteen minutes. The response time
(or lack of response) was logged in a file and later downloaded and
processed. Periodically, aberrant measures were seen. For
example, there was often packet loss/or and high latency when the
machine ping'd its own interface. Packet loss data indicated
higher loss and latency results than did other measures.
IMR Editor [Page 16]
Internet Monthly Report July 1996
Because Merit did not have the source code for the Sun ping, the
engineering staff could not perform a detailed analysis to
determine the cause of the problem. Staff did find, however, that
the Cornell ping, to which they did have source code, did not
display the same anomalies and provided much more credible
measurements. As a result, a new data collection methodology has
been implemented using the Cornell ping as a basis for the
measurements. The data from all the Route Servers now shows
improved Internet performance in comparison with the previous
months' data. To provide data for further study, the primary Route
Server at the Washington, D.C. NAP (MAE-East) is running the old
and new pings in parallel. Comparing the two sets of results
should shed additional light on the source of bias between the two
measurement methodologies, and potentially permit an adjustment to
deflate the previous measurements.
Merit has been exploring options for resolving an important
operational problem of the Route Servers, i.e., how to detect
whether or not peers of the Route Servers have direct layer-2
reachability to each other. Though this issue was raised at one of
the ATM NAPs, it would be problematic for any non-broadcast-media
NAP, and is an important issue with respect to the reliability of
both routing and the Route Servers. Currently, Merit and the
Information Sciences Institute, its partner in the RA project, are
evaluating the feasibility of obtaining layer-2 reachability
information directly from Route Server peers via ICMP-level queries
(traceroute with strict source routing). This is ultimately the
source of the desired information and can be initiated by the Route
Server without requiring SNMP access coordination and community
string dissemination.
Merit has implemented an incremental update client for the copies
it maintains of the databases in the Internet Routing Registry.
This client will poll primary IRR sites for updates on a regular
basis (most likely every ten minutes). Currently, these sites only
provide updated copies of the registries on a daily basis, so this
technology will significantly improve the timeliness of the IRR
data provided by RAWhoisd, the whois.ra.net whois server.
The incremental update client has been in final test for the last
weeks of July and will be deployed in early August. Initially,
only the RIPE registry will provide incremental updates. However,
we hope that all IRR registries will eventually adopt this
technology.
IMR Editor [Page 17]
Internet Monthly Report July 1996
A new RA tool prototype, known as NetNow, combines a variety of
real- time network statistics to provide an easy-to-use, graphical
display of ongoing core Internet network conditions. See:
http://www.ra.net/tools/
A map of the United States shows the four Network Access Points,
and a menu bar lists the major U.S. Internet Service Providers.
Names on the map and provider list are color-coded to indicate
whether conditions are normal at the NAP or on the provider's
backbone, or whether there are problems such as high packet loss or
latency, excessive route flapping, unreachable networks, or
scheduled maintenance outages. Information about the NAPs is
collected by ICMP pings to Route Server peers and SNMP queries to
the Route Servers. The ISP backbones are monitored by sending ICMP
pings from each NAP across each provider backbone to every other
NAP (creating a mesh). In the near future, pings will also be sent
across the major ISP backbones to popular end sites. This process
will test inter-provider connectivity and provide some statistics
on the performance of provider tail circuits.
A new software package called "Scion" is being developed by Merit's
NetSCARF (Network Statistics Collection And Reporting Facility)
project. Scion can be used by ISPs to collect network statistics
and automatically display performance reports on the World Wide
Web. Version 1.2 of the code is available from:
http://www.merit.edu/~netscarf
The Scion code, derived from the initial NSFNET project's
statistics collection and reporting activities, is easy to install
and runs automatically. Every fifteen minutes, Scion's optimized
SNMP library queries ISP routers for the values of variables such
as sysUpTim and ifLastChange. The library uses SNMP Version 1, and
can be configured to use SNMPv2u, the User-based Security model for
SNMPv2. Scion's SNMP API is unique, in that it allows the
developer to specify a list of nodes, a community string (or
userid/authentication password/privacy password in the case of
SNMPv2u), and a list of management objects to retrieve. All queries
are then transmitted back-to-back, without waiting for any replies.
The data collection activity is thus very fast, and the results
highly synchronized. Other publicly available SNMP libraries force
applications to wait for a response (or timeout) for a given query
before the next query can be issued to a different node.
IMR Editor [Page 18]
Internet Monthly Report July 1996
The raw SNMP statistics are pre-processed each evening, and the
processed data delivered to CGI scripts, using what the developers
believe to be the first public domain implementation of the OpStats
(RFC 1856) client/server model. Finally, ISP performance reports
based on the 'cooked' data are displayed on the Web via the CGI
scripts.
ISPs can use the Scion code to automatically produce HTML graphs
showing system uptime, interface uptime, and total network traffic
measured in packets. An advanced statistics Web page allows users
to specify customized graphing parameters.
The source and pre-compiled executables are available for the BSDi
and SunOS platforms. Release 2, scheduled for October 1996, will
include ports to Windows NT, AIX, and perhaps Solaris and LINUX.
A technical overview of the software package has been written by
project manager Bill Norton and lead architect Andy Adams, and
appears in the July ConneXions (Vol. 10 No. 7). Norton gave a talk
about NetSCARF and Scion at the Network Management Area Open
Meeting at the Montreal IETF (June '96) and at a network statistics
BOF following the May NANOG meeting. A new mailing list,
netscarf at merit.edu, is a forum for community discussion and input
to the project. Further information is available at the URL above.
Susan R. Harris (srh at merit.edu)
IMR Editor [Page 19]
Internet Monthly Report July 1996
CALENDAR
--------
Last update 07/9/96
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at cnri.reston.va.us>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
FYI - The EMail World & Internet World originally scheduled for
Sept. 10-12, 1996 has been moved to Oct. 15-17, 1996. Boston, MA.
A copy of this calendar is available as follows:
VIA FTP
- -------
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
Africa Address: ftp.is.co.za (196.4.160.8)
cd ietf
ls *0mtg*
Gopher
- -------
Available on the Gopher Server running on IETF.CNRI.RESTON.VA.US
(132.151.1.35) under "Internet Engineering Task Force (IETF) / IETF
Meetings / Scheduling Calendar".
WWW
- -------
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link
for "meetings" and you should find an entry "listing of other Internet
related events".
************************************************************************
IMR Editor [Page 20]
Internet Monthly Report July 1996
1996
- -----------
Oct. 1-3 Email World & Internet Expo Toronto, Ontario, CA
Oct. 2-4 Object World Tokyo Tokyo, Japan
Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL
Oct. 7-11 ATM Forum Montreux, Switzerland
Oct. 7-11 NetWorld+Interop Paris, France
Oct. 7-11 Performance 96 Conference Lausanne, Switzerland
Oct. 9-11 Object World Frankfurt Frankfurt, Germany
Oct. 15 Commercenet New Orleans, LA
Oct. 15-17 EMail World & Internet Expo Boston, MA
Oct. 17-20 IEEE Symposium on Planning & Design
of Broadband Networks Quebec, Canada
Oct. 21-25 ICECCS'96 (held jointly with
6th CSESAW, 4th IEEE RTAW) Montreal, Canada
Oct. 28-31 2nd USENIX Seattle, WA
Oct. 28-Nov. 1 NetWorld+Interop London, England
Oct. 29-Nov. 1 ICNP-96 Int'l Conf. on
Network Protocols Columbus, Ohio
Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys.
Design & Implement. (OSIDI II) Seattle, WA
Nov. 1996 OMG TC (Groupe Bull) Nice, France
Nov. 4-7 APPN Implementers Workshop Raleigh, NC
Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA
Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York
Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada
Nov. 12-15 3rd Int'l Conf.
on Multimedia Modeling Toulouse, France
Nov. 13 Commercenet Santa Clara, CA
Nov. 18-20 2nd USENIX Workshop on
Electronic Commerce Oakland, CA
Nov. 18-22 ACM Multimedia '96 Boston, MA
Nov. 18-22 IEEE Globecom 96 London, England
Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA
Nov. 25-29 NetWorld+Interop Sydney, Australia
Dec. 2-4 Web World San Diego, CA
Dec. 2-6 ANSI X3T11 Rochester, MN
Dec. 2-6 ATM Forum Vancover, BC
Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA
Dec. 9-12 Internet World '96 Baltimore, MD
Dec. 9-13 37th IETF San Jose, CA
Dec. 9-13 OIW (Firm)
Dec. 10-13 Fall Internet World '96 New York, NY
Dec. 13 Commercenet Albuquerque, NM
IMR Editor [Page 21]
Internet Monthly Report July 1996
1997
- -----------
Jan. 6-10 ANSI X3T10 '97
Jan. 6-10 USENIX '97
Annual Technical Conf. Anaheim, CA
Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA
Jan. 7-10 13th Annual Hawaii Int'l Conf
on Systems Sciences Maui, Hawaii
Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL
Feb. 3-7 ANSI X3T11 TBA
Feb. 10-11 ISOC Symposium on Network and
Distributed System Security San Diego, CA
Feb. 17-19 Internet Expo & EMail World San Jose, CA
Mar. 1-5 ACM '97: The Next 50 yrs. of Computing
San Jose, CA
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque
Mar. 11-15 ANSI X3T10 '97
Apr. 7-11 38th IETF Memphis, TN
Apr. 7-11 ANSI X3T11 TBA
Apr. 7-11 IEEE Infocom '97 Kobe, Japan
Apr. 9-11 ISADS 97 - 3rd Intl Symposium on
Autonmous Decentralized Sys. Berlin, Germany
Apr. 22-24 Internet Expo & EMail World Chicago, IL
May 5-9 ANSI X3T10 '97
Jun. 8-12 ICC '97 Montreal
Jun. 9-13 OIW (Firm)
Jun. 9-13 ANSI X3T11 TBA
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 14-18 ANSI X3T10 '97
Aug. 11-15 ANSI X3T11 TBA
Aug. 11-15 (tenative) 39th IETF Munich, Germany
Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France
Oct. 6-10 ANSI X3T11 TBA
Nov. 3-7 ANSI X3T10 '97
Dec. 8-12 OIW (Firm)
TELECOM '97 Asia (Venue and Dates to be Determined)
IMR Editor [Page 22]
Internet Monthly Report July 1996
1998
- -----------
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
1999
- -----
Oct. 8-14 TELECOM '99 Geneva, Switzerland
IMR Editor [Page 23]
Internet Monthly Report July 1996
TERENA List of Meetings
=======================
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact
the chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail <secretariat at terena.nl>.
**********************************************************************
MEETING/DATE LOCATION
============ ========
TERENA General Assembly
-----------------------
GA6
24-25 October Bled
GA7
15-16 May 1997 Edinburgh
TERENA Executive Committee
--------------------------
17 December Amsterdam
TERENA Technical Committee
--------------------------
13 November Brussels
22 January 1997 Amsterdam
TERENA Office Meeting
---------------------
16 October Amsterdam
JENC8
-----
Conference Committee
8 November (provisional) Edinburgh
Programme Committee
4 December Amsterdam
IMR Editor [Page 24]
Internet Monthly Report July 1996
INSIGHT Training Workshop
-------
28-29 October Bled
CEEnet
------
26 October Bled
PHARE Research Networking
------
25 October Bled
-----------------------------------------------------------------
=================================================================
EEMA
----
Electronic Commerce '96 Wembley, London
15-17 October
Regional Conference
29 November - 1 December Malta
Electronic Communications Olympia, London
10-12 December
EWOS
----
TA35, 3-4 December Brussels
TA36, 25-26 February 1997 "
TA37, 13-14 May 1997 "
TA38, 16-17 September 1997 "
TA39, 2-3 December 1997 "
SC - 24 September "
SC - 17 December "
Workshops
35: 21-25 October Brussels
36: 20-24 January 1997 "
37: 7-11 April 1997 "
38: 16-20 June 1997 "
39: 27-31 October 1997 "
IMR Editor [Page 25]
Internet Monthly Report July 1996
ETSI
----
Seminar/Workshop
1-3 October Nice, France
GA24 10-11 December Nice, France
TA25 23-25 October "
IETF
----
9-13 December San Jose, CA
7-11 April 1997 Memphis, Tenn.
11-15 August 1997 Munich, Germany
RIPE
----
RIPE26
20-22 January 1997 Amsterdam
RIPE27
May 1997 Dublin
NATO Workshop
-------------
5-9 May 1997 Edinburgh
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
------------------
Call for Papers
JENC8 - 8th Joint European Networking Conference
------------------------------------------------
"Diversity and Integration: The New European Networking Landscape"
12-15 May 1997
Edinburgh, Scotland
This conference will be the European Forum to get up-to-date
information, to debate and assess the new deregulated tele-
communication environment in Europe, new leading-edge applications,
and the network/internetwork support infrastructure which is
currently being developed
IMR Editor [Page 26]
Internet Monthly Report July 1996
Subject Areas:
* Emerging Network Technologies and Network Engineering
* User Support, Training and Education
* Security and Management Issues
* Information Systems and Distributed Applications
* Economic and Political Issues
Deadline for paper submission 10 November 1996 to:
<jen8-submit at terena.nl>
For information please contact the JENC8 Secretariat at:
TERENA Secretariat
Singel 466-468
1017 AW Amsterdam, The Netherlands
tel: +31 20 6391131 fax: +31 20 6393289
email: <jenc8-sec at terena.nl>
http://www.terena.nl/jenc8
or
JENC8 Local Organization
c/o Concorde Services Ltd
Unit 5, SECC
Glasgow, G3 8YW, Scotland
email: <jenc8 at ed.ac.uk>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OTHER CONFERENCES:
-----------------
Performance '96
---------------
International Conference on Performance Theory, Measurement and
Evaluation of Computer and Communications Systems
Organized by IFIPWG7.3
7-11 October
Ecole Polytechnique Federal de Lausanne, Lausanne, Switzerland
Deadline paper submission 15 March 1996
Further information on WWW Page: http://lrcwww.epfl.ch/perf96/
IMR Editor [Page 27]
Internet Monthly Report July 1996
PROMS'96
Third International Workshop on Protocols for Multimedia Systems
----------------------------------------------------------------
15-18 October
Madrid, Spain
This workshop is intended to contribute to scientific, strategical
and practical cooperation between research institutes and industrial
companies in the area of distributed multimedia applications, protocols,
and intelligent management tools, with emphasis on their usage on
broadband networks.
Papers to be submitted by 7 June.
For information contact Arturo Azcorra at <aazcorra at dit.upm.es>
6th CEN/CENELEC/ETSI Conference 1996
--------------------------------
5-6 November
Sheraton Brussels Hotel, Brussels, Belgium
Theme of this conference is "Standards on Trial: Case Studies in
European Standardization"
Deadline for abstracts is 13 Sept. For further information:
c/o CENELAC, Tel: +32 2 519 6871 Fax: +32 2 519 6919
IDATE96
18th International Conference of IDATE
--------------------------------------
6-8 November
Montpellier, France
An opportunity for professional contacts with major industrial
group leaders, users and clients, researchers and academics,
administrators and politians.
Full details of the conference available on the Web:
http://www.idate.fr
CEN/TC304 - Character Set Technology Workshop
---------------------------------------------
11-12 November
Bled, Slovenia
Providing multilingual support in middleware: Implementing the
Universal Character Set ISO 10646 in the European Information Society
For information look up URL: http://www.e5.ijs.si/i18n/ws-bled.html
IMR Editor [Page 28]
Internet Monthly Report July 1996
"The Telematics Revolution,
Consequences for Individuals and Organisations"
----------------------------------------------
13 November
University of Technology, Eindhoven, the Netherlands
Theme of the conference is that progress of information and
telecommunication technologies do create a huge number of questions,
be it social, jurisdictional, economic or technical.
Parallel sessions will deal with: interactive scientific visual-
isation, tele-learning, user aspects of multimedia, distant
consultation and using of laboratories.
For all information and to receive brochure, contact
Mr. Marc Fleskens at email address <telematics at tue.nl>
IEEE Global Internet 1996
-------------------------
20-21 November
Queen Elizabeth II Conference Centre, London
This mini-conference will provide an open forum for the communications
and computer networking communities to review the state-of-the-art
technologies and applications of the evolving Global Internet.
Deadline paper submissions 15 May to:
http://gaia.cs.umass.edu:80/tccc/internet96/
or email Jon Crowcroft <jon at cs.ucl.ac.uk>
WEB INTERNATIONALIZATION & MULTILINGUISM SYMPOSIUM
--------------------------------------------------
20-22 November
Sevilla, Spain
Organized by Sadiel and the WWW Consortium, with the support of the
European Commission. The object of this symposium is the advancement
of the internationalization and multilingualism of the Web, as well
as to seek agreement on the relevant standards.
Registration from 15 September.
For further information see:
http://www.w3.org/pub/WWW/International/Sevilla-96
IMR Editor [Page 29]
Internet Monthly Report July 1996
EITC'96 - European IT Conference
--------------------------------
25-27 November
Congress Centre, Brussels, Belgium
"Doing Business in the Information Society"
Electronic commerce, provides the focus for sessions on IT
applications, enabling technologies and international initiatives.
Post-Conference Workshops to be held on 28 November.
For information contact European Commission, DGIII or
WWW: http://www.cordis.lu/esprit/src/eitc96.htm
ASIAN'96 - Asian Computing Science Conference
---------------------------------------------
2-5 December
Singapore
Themes of this conference is:
- Programming (sematics, languages, systems, ...)
- Concurrency & Parallelism (algorithms, formalisms, systems ...)
- Networking & Security (algorithms, protocols, formalisms, ...)
Additional information available from:
http://www.escs.nus.sg/~asian96
Multimedia Computing and Networking 1997
----------------------------------------
10-12 February 1997
San Jose, CA, USA
The object of this conference is to bring together researchers,
developers, and practitioners working in all facets of multimedia
computing and networking.
Paper submission by 16 July 1996.
For further information email <mmcn at cs.utexas.edu>
COREC -"Interregional Cooperation in RTD - Challenges and
Opportunities for Regions in Economic Conversion"
---------------------------------------------------------
16-17 December
Bremen, Germany
Background is the experience of the community initiative STRIDE and
other programmes of the European Commission.The conference will deal
questions of RTD-programmes and policies, their European Dimension
and impact on regional development.
For information contact Mr. Wolfgang Petzold at:
email <wmte at uni-bremen.de>
IMR Editor [Page 30]
Internet Monthly Report July 1996
IEEE INFOCOM '97
16th Annual Joint Conference of the IEEE
Computer & Communications Societies
----------------------------------------
7-11 April 1997
Kobe, Japan
Paper submissions by 14 June 1997.
For further information contact
http://www.ics.uci.edu/~infocom/
http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html
ISADS 97
3rd International Symposium on Autonomous Decentralized Systems
---------------------------------------------------------------
9-11 April 1997
Berlin, Germany
Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS,
Hewlett Packard, IBM.
The focus will be on advancements and innovations in ADS platforms
and applications. Integration of telecommunication and computing
aspects into a uniform concept for providing an open distributed
processing environment.
For information see WWW: http://www.fokus.gmd.de/ws/isads97/
EEMA'97
10th Annual Conference of European Electronic Messaging Association
-------------------------------------------------------------------
16-19 June 1997
Maastricht Exhibition and Congress Centre, Maastricht, Netherlands
Issues of the conference will be:
Global Security; Corporate Directories; Messaging Products & Services;
Electronic Commerce; Global Messaging Enterprise; European Initiatives;
Mobile Messaging Technology; Messaging Technology & Management
Strategy; Intranet; World Wide Web & Infobots.
For information contact WWW: http://www.eema.org/
IMR Editor [Page 31]
Internet Monthly Report July 1996
INET'97
The Internet: The Global Frontiers
----------------------------------
24-27 June 1997
Kuala Lumpur, Malaysia
The conference will address the traditional and evolving frontiers
of the Internet as well as its significant impact on education,
commerce and societies throughout the world.
Abstracts of papers to be submitted by 10 October.
-for details of submission procedure
email <inet-program-interest at isoc.org>
-for program information email <inet-program-chair at isoc.org
-for general information email <inet'97 at isoc.org>
====================================================
This meeting list is also available on our WWW page:
http://www.terena.nl/news/
====================================================
IMR Editor [Page 32]
Received: from ietf.org by ietf.org id aa24478; 1 Nov 96 19:58 EST
Received: from zephyr.isi.edu by ietf.org id aa23916; 1 Nov 96 19:53 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA27805>; Fri, 1 Nov 1996 16:52:43 -0800
Message-Id: <199611020052.AA27805 at zephyr.isi.edu>
To: IETF-Announce: ;
To: Internet-Monthly-Report-People: ;
Subject: Internet Monthly Report for July, 1996
Cc: imr-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 01 Nov 96 16:52:43 PST
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
--NextPart
The Internet Monthly Report for July, 1996 is now available
at the following location:
URL= ftp://ftp.isi.edu/in-notes/imr/imr9607.txt
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
Requests to be added or deleted from the IMR report list:
The Internet Monthly Report list is managed by MajorDomo atISI.EDU.
The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be added or deleted from the Internet Monthly report list
should be sent to majordomo at isi.edu with the message body either
subscribe imr or unsubscribe imr.
Requests to be added or deleted from the IETF list should be sent to
ietf-request at ietf.org.
Internet Monthly Report availability via WWW, FTP and EMAIL:
IMR Retrieval using WWW
-----------------------
The URL below may be used in web browsers to access the IMRs. You
will see a list of names in the form IMR9607.TXT. For example,
IMR9607.TXT is the report for July 1996.
URL: ftp://ftp.isi.edu/in-notes/imr
IMR Retrieval using EMAIL via the RFC-INFO Service
--------------------------------------------------
The EMail retrieval system RFC-Info will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to rfc-info at ISI.EDU with
the message body help: ways_to_get_imrs. For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from FTP.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of
the IMR.
For example IMR9607.TXT is the report for July 1996).
Login with FTP username anonymous and password ftp.
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the current IMR.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9607
--OtherAccess
Content-Type: Message/External-body;
name="imr9607.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa27459; 1 Nov 96 20:16 EST
Received: from zephyr.isi.edu by ietf.org id aa27194; 1 Nov 96 20:14 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA29508>; Fri, 1 Nov 1996 17:13:50 -0800
Message-Id: <199611020113.AA29508 at zephyr.isi.edu>
To: ietf at ietf.org, imr at isi.edu
Subject: Internet Monthly Report for August, 1996
Cc: imr-ed at isi.edu
Date: Fri, 01 Nov 96 17:13:50 PST
Sender:ietf-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
Source-Info: From (or Sender) name not authenticated.
August 1996
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to "IMR at ISI.EDU".
`````````````````````````````````````````````````````````````````````
The Internet Monthly Report mailing list is now managed by MajorDomo at
ISI.EDU. The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be ADDED or DELETED from the Internet Monthly report list
should be sent to "majordomo at isi.edu" with the message body either
"subscribe imr" or "unsubscribe imr".
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
or URL: http://www.isi.edu/in-notes/imr/
IMR Editor [Page 1]
Internet Monthly Report August 1996
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 13
Registration Services . . . . . . . . . . . . . . . . . page 13
Directory Services. . . . . . . . . . . . . . . . . . . page 14
US Domain Registry. . . . . . . . . . . . . . . . . . . page 15
MERIT INTERNET ENGINEERING. . . . . . . . . . . . . . . . page 19
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 20
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 21
TERENA List of Meetings. . . . . . . . . . . . . . . . . . page 25
IMR Editor [Page 2]
Internet Monthly Report August 1996
INTERNET ARCHITECTURE BOARD
The minutes of the IAB back to 1990 are available for anonymous ftp
access on host ftp.isi.edu, directory /pub/IAB, or via the IAB
World-Wide Web page with URL http://www.iab.org/iab/.
Brian Carpenter IAB Chair
INTERNET ENGINEERING REPORTS
----------------------------
IETF Monthly Report for August, 1996
1. The IETF met in Montreal, Quebec, Canada from June 24-28, 1996.
It was another record setter as over 1200 attendees registered.
Much of this was probably due to the IETF meeting along side INET
'96.
The IETF returns to San Jose, California on December 9-13, 1996.
Our local host will be cisco Systems. The Secretariat will open for
registrations the first part of October. The IETF opens 1997
Memphis, Tennessee where Federal Express will be the host. This
meeting will be held April 7-11, 1997. Following Memphis, the IETF
is we returning to Europe and will met in Munich, Germany August
11-15, 1997, hosted by Digi/ISOC.DE. The Secretariat is still
working on the final meeting of 1997.
Once all the arrangements have been made, notifications will be
sent to the IETF Announcement list. Remember that information on
future IETF meetings can be always be found in the file 0mtg-
sites.txt which is located on the IETF shadow directories. This
information can also be viewed from the IETF Home Page on the Web.
The URL is:
http://www.ietf.org
2. The minutes of the IESG teleconferences have been publicly
available on the IETF Shadow directories since 1991. These files
are placed in the /ftp/iesg directory.
The following IESG minutes have been added:
July 25, 1996 (iesg.96-07-25)
August 8, 1996 (iesg.96-08-08)
IMR Editor [Page 3]
Internet Monthly Report August 1996
3. The IESG approved or recommended the following 26 Protocol
Actions during the month of August, 1996:
o UTF-8, a transformation format of Unicode and ISO 10646 be
published as an Informational RFC.
o Observations on the use of Components of the Class A Address
Space within the Internet be published as an Informational
RFC.
o The PPP Internetwork Packet Exchange Control Protocol (IPXCP)
be published as a Draft Standard.
o Domain Name System Security Extensions be published as a
Proposed Standard.
o Hypertext Transfer Protocol -- HTTP/1.1 be published as a
Proposed Standard.
o A Proposed Extension to HTTP : Digest Access Authentication
be published as a Proposed Standard.
o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 be published
as a Proposed Standard.
o IMAP4 COMPATIBILITY WITH IMAP2BIS be published as an
Informational RFC.
o INTERNET MESSAGE ACCESS PROTOCOL - OBSOLETE SYNTAX be
published as an Informational RFC.
o IMAP4 COMPATIBILITY WITH IMAP2BIS be published as an
Informational RFC. oThe PPP SNA Control Protocol (SNACP) be
published as a Proposed Standard.
o Source directed access control on the Internet be published
as an Informational RFC.
o Local Mail Transfer Protocol be published as an Informational
RFC.
o TELNET CHARSET Option be published as an Experimental
Protocol.
o IP over HIPPI be published as a Draft Standard.
o Traffic Flow Measurement: Architecture be published as an
Experimental Protocol.
IMR Editor [Page 4]
Internet Monthly Report August 1996
o Traffic Flow Measurement: Meter MIB be published as an
Experimental Protocol.
o Service Location Protocol be published as a Proposed
Standard.
o Entity MIB be published as a Proposed Standard.
o SMTP Service Extension for Returning Enhanced Error Codes be
published as a Proposed Standard.
o Multipurpose Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies be published as a Draft Standard.
o Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types be published as a Draft Standard.
o MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text be published as
a Draft Standard.
o Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures be published as a Best Current
Practices RFC.
o Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples be published as a Draft
Standard.
o Remote Authentication Dial In User Service (RADIUS) be
published as a Proposed Standard.
o RADIUS Accounting be published as an Informational RFC.
4. The IESG issued six Last Calls to the IETF during the month of
August, 1996:
o HTTP State Management Mechanism
<draft-ietf-http-state-mgmt-03> for consideration as a
Proposed Standard.
o IMAP4 QUOTA extension <draft-myers-imap-quota-01> for
consideration as a Proposed Standard.
o IMAP4 non-synchroniziong literals
<draft-myers-imap-literal-01> for consideration as a Proposed
Standard.
IMR Editor [Page 5]
Internet Monthly Report August 1996
o IMAP4 ACL extension <draft-myers-imap-acl-03> for
consideration as a Proposed Standard.
o HMAC-MD5 IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-md5-01> for consideration as a
Proposed Standard.
o HMAC-SHA IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-sha-01> for consideration as a
Proposed Standard.
5. One new Working Group was formed this period.
MBONE Deployment (mboned)
and one Working Group was concluded:
Internet User Glossary (userglos)
6. A total of 117 Internet-Draft actions were taken during the
month of August, 1996:
(Revised draft (o), New Draft (+) )
(rsvp) o Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification
<draft-ietf-rsvp-spec-13.txt, .ps>
(dnssec) o Domain Name System Security Extensions
<draft-ietf-dnssec-secext-10.txt>
(none) o Definitions of Managed Objects for the Fabric
Element in Fibre Channel Standard
<draft-teow-fabric-mib-01.txt>
(oncrpc) o Authentication Mechanisms for ONC RPC
<draft-ietf-oncrpc-auth-03.txt>
(none) o Group Key Management Protocol (GKMP) Architecture
<draft-harney-gkmp-arch-01.txt>
(none) o Group Key Management Protocol (GKMP) Specification
<draft-harney-gkmp-spec-01.txt>
(cat) o Generic Security Service Application Program
Interface, Version 2 <draft-ietf-cat-gssv2-08.txt>
(wts) o The Secure HyperText Transfer Protocol
<draft-ietf-wts-shttp-03.txt>
(idr) o A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-idr-bgp4-03.txt>
(dhc) o Dynamic Host Configuration Protocol for IPv6
(DHCPv6) <draft-ietf-dhc-dhcpv6-07.txt>
(cat) o Generic Security Service API Version 2 : C-bindings
<draft-ietf-cat-gssv2-cbind-02.txt>
IMR Editor [Page 6]
Internet Monthly Report August 1996
(intserv) o Specification of Guaranteed Quality of Service
<draft-ietf-intserv-guaranteed-svc-06.txt>
(rip) o RIPng for IPv6 <draft-ietf-rip-ripng-04.txt>
(ion) + IP Broadcast over ATM Networks.
<draft-ietf-ion-bcast-00.txt>
(entmib) o Entity MIB <draft-ietf-entmib-entmib-07.txt>
(isdnmib) o ISDN Management Information Base
<draft-ietf-isdnmib-snmp-isdn-mib-07.txt>
(uri) + The Handle System
<draft-ietf-uri-urn-handles-00.txt>
(none) o TELNET CHARSET Option
<draft-gellens-telnet-char-option-04.txt, .ps>
(mixer) o Mapping between X.400 and RFC-822/MIME Message
Bodies <draft-ietf-mixer-bodymap-06.txt>
(none) o Application Level Internet Payment Syntax
<draft-eastlake-internet-payment-02.txt>
(html) o Internationalization of the Hypertext Markup
Language <draft-ietf-html-i18n-05.txt>
(ipsec) o Simple Key-Management For Internet Protocols (SKIP)
<draft-ietf-ipsec-skip-07.txt>
(none) o INTERNET REGISTRY IP ALLOCATION GUIDELINES
<draft-hubbard-registry-guidelines-05.txt>
(madman) o Mail Monitoring MIB
<draft-ietf-madman-mail-monitor-mib-02.txt>
(madman) o Network Services Monitoring MIB
<draft-ietf-madman-nsm-mib-02.txt>
(mixer) o A MIME body part for FAX
<draft-ietf-mixer-fax-01.txt>
(mixer) o A MIME body part for ODA
<draft-ietf-mixer-oda-01.txt>
(http) o Hypertext Transfer Protocol -- HTTP/1.1
<draft-ietf-http-v11-spec-07.txt, .ps>
(http) + HTTP/1.2 EXTENSION PROTOCOL (PEP)
<draft-ietf-http-pep-00.txt>
(intserv) o Specification of the Controlled-Load Network Element
Service <draft-ietf-intserv-ctrl-load-svc-03.txt>
(hubmib) o Definitions of Managed Objects for IEEE 802.3 Medium
Attachment Units (MAUs)
<draft-ietf-hubmib-mau-mib-03.txt>
(none) + PEM Compression Encryption Module
<draft-woodward-encryption-module-00.txt>
(ipsec) o Encoding of an Unsigned Diffie-Hellman Public Value
<draft-ietf-ipsec-skip-udh-01.txt>
(ipsec) o X.509 Encoding of Diffie-Hellman Public Values
<draft-ietf-ipsec-skip-x509-01.txt>
(ipsec) o SKIP Algorithm Discovery Protocol
<draft-ietf-ipsec-skip-adp-01.txt>
IMR Editor [Page 7]
Internet Monthly Report August 1996
(ipsec) o SKIP Extensions for IP Multicast
<draft-ietf-ipsec-skip-mc-01.txt>
(mixer) o Carrying PostScript in X.400 and MIME
<draft-ietf-mixer-postscript-01.txt>
(none) o Extending NAT <draft-rfced-info-hurn-01.txt>
(none) o INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
<draft-crispin-imap-base-05.txt>
(wts) o Security Extensions For HTML
<draft-ietf-wts-shtml-02.txt>
(dhc) o Extensions for DHCPv6 <draft-ietf-dhc-v6exts-02.txt>
(dnsind) o Selection and Operation of Secondary DNS Servers
<draft-ietf-dnsind-2ndry-03.txt>
(ipsec) o SKIP extension for Perfect Forward Secrecy (PFS)
<draft-ietf-ipsec-skip-pfs-01.txt>
(dnssec) o Secure Domain Name System Dynamic Update
<draft-ietf-dnssec-update-01.txt>
(dnssec) o Detached Domain Name System Information
<draft-ietf-dnssec-ddi-01.txt>
(none) o VEMMI URL Specification
<draft-mavrakis-vemmi-url-spec-01.txt>
(http) o Transparent Content Negotiation in HTTP
<draft-holtman-http-negotiation-02.txt>
(atommib) o Managed Objects for Controlling the Collection and
Storage of Accounting Information for
Connection-Oriented Networks
<draft-ietf-atommib-acct-03.txt>
(asid) o Lightweight Directory Access Protocol: Standard and
Pilot Attribute Definitions
<draft-ietf-asid-ldapv3-attributes-02.txt>
(fddimib) o FDDI Management Information Base
<draft-ietf-fddimib-objects-v2-01.txt>
(asid) o Lightweight Directory Access Protocol (v3)
<draft-ietf-asid-ldapv3-protocol-02.txt>
(none) o Tools in the War on Mail Loops
<draft-bernstein-mail-loops-war-01.txt>
(none) o Public Information Retrieval Protocol (PIRP)
<draft-bernstein-pirp-01.txt>
(none) o Notice-Requested-Upon-Delivery-To (NRUDT)
<draft-bernstein-nrudt-01.txt>
(none) o The qmail-send Bounce Message Format (QSBMF)
<draft-bernstein-qsbmf-01.txt>
(none) o Easily Parsed LIST Format (EPLF)
<draft-bernstein-eplf-01.txt>
(none) o Netstrings <draft-bernstein-netstrings-01.txt>
(none) o The Hash Convention For Mail System Status Codes
(HCMSSC) <draft-bernstein-hcmssc-01.txt>
(atommib) o Definitions of Managed Objects for ATM Management
<draft-ietf-atommib-atm1ng-01.txt>
IMR Editor [Page 8]
Internet Monthly Report August 1996
(atommib) o Definitions of Managed Objects for the SONET/SDH
Interface Type <draft-ietf-atommib-sonetng-01.txt>
(pier) o Router Renumbering Guide <draft-ietf-pier-rr-02.txt>
(none) o Source directed access control on the Internet.
<draft-bradner-access-control-02.txt>
(mhtml) o MIME E-mail Encapsulation of Aggregate Documents,
such as HTML (MHTML) <draft-ietf-mhtml-spec-03.txt>
(ipsec) o HMAC-MD5 IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-md5-02.txt>
(ipsec) o HMAC-SHA IP Authentication with Replay Prevention
<draft-ietf-ipsec-ah-hmac-sha-02.txt>
(mhtml) o Sending HTML in E-mail, an informational supplement
to RFC ???: MIME E-mail Encapsulation of Aggregate
HTML Documents (MHTML)
<draft-ietf-mhtml-info-03.txt>
(none) o New Registries and the Delegation of International
Top Level Domains
<draft-postel-iana-itld-admin-02.txt>
(rtfm) o Traffic Flow Measurement: Experiences with NeTraMet
<draft-ietf-rtfm-acct-experiences-01.txt>
(ids) o Use of DNS Aliases for Network Services
<draft-ietf-ids-dnsnames-01.txt>
(ids) o Finding Stuff (Providing information to support
service discovery) <draft-ietf-ids-discovery-01.txt>
(pier) o Network Renumbering Overview: Why would I want it
and what is it anyway?
<draft-ietf-pier-renum-ovrvw-01.txt>
(none) o SMTP Extension for Message Submission/Relay
<draft-gellens-smtp-submit-01.txt>
(oncrpc) o Binding Protocols for ONC RPC Version 2
<draft-ietf-oncrpc-rpcbind-01.txt>
(oncrpc) o RPC: Remote Procedure Call Protocol Specification
Version 2 <draft-ietf-oncrpc-remote-02.txt>
(none) o The Public Key Login Protocol
<draft-kemp-auth-pklogin-01.txt, .ps>
(none) o User-Agent Display Attributes
<draft-mutz-http-attributes-01.txt>
(none) o IPv6 Router Alert Option
<draft-cisco-ipv6-router-alert-01.txt>
(none) o Resolution of Uniform Resource Identifiers using the
Domain Name System <draft-daniel-naptr-01.txt>
(none) o Redundant MARS architectures and SCSP
<draft-armitage-ion-mars-scsp-01.txt>
(ion) o Multiprotocol Interconnect over Frame Relay
<draft-ietf-ion-fr-update-01.txt>
(none) o Reducing the ISDN costs of Network Applications that
use TCP/IP. <draft-waters-reduce-isdn-costs-01.txt>
IMR Editor [Page 9]
Internet Monthly Report August 1996
(mboned) + Multicast pruning a necessity
<draft-ietf-mboned-pruning-00.txt>
(none) + S/Ident: Security Extensions for the Ident Protocol
<draft-morgan-ident-ext-00.txt>
(asid) + Lightweight Directory Access Protocol (v3): UTF-8
String Representation of Distinguished Names
<draft-ietf-asid-ldapv3-dn-00.txt>
(asid) + An Approach for Using Domains in LDAP Distinguished
Names <draft-ietf-asid-ldap-domains-00.txt>
(ediint) + Requirements for Inter-operable Internet EDI
<draft-ietf-ediint-req-00.txt>
(rip) + RIPng Protocol Applicability Statement
<draft-ietf-rip-ripng-applic-00.txt>
(none) + Virtual Tunneling Protocol (VTP)
<draft-calhoun-vtp-protocol-00.txt>
(atommib) + Accounting Information for ATM Networks
<draft-ietf-atommib-atmacct-00.txt>
(fddimib) + FDDI Management Information Base in the SNMPv2 SMI
<draft-ietf-fddimib-smiv2-object-v2-00.txt>
(none) + Interworking Between CDPD and Mobile IP Networks
<draft-ruth-cdpd-networks-00.txt>
(none) o TCP and UDP over IPv6 Jumbograms
<draft-borman-jumbograms-01.txt>
(none) + Dedicated Token Ring Concentrator MIB
<draft-warwick-tokenring-arch-00.txt>
(none) + RTP Payload Format for Bundled MPEG
<draft-civanlar-bmpeg-00.txt>
(none) + Quick Mail Transfer Protocol (QMTP)
<draft-bernstein-qmtp-00.txt>
(none) + The Owner Hack <draft-bernstein-owner-hack-00.txt>
(none) o Key words for use in RFCs to Indicate Requirement
Levels <draft-bradner-key-words-02.txt>
(intserv) + The Use of RSVP with IETF Integrated Services
<draft-ietf-intserv-rsvp-use-00.txt>
(mhtml) + Content-ID and Message-ID Uniform Resource Locators
<draft-ietf-mhtml-cid-00.txt>
(none) + IP Cluster <draft-chu-ip-cluster-00.txt>
(stdguide) + Guide for Internet Standards Writers
<draft-ietf-stdguide-ops-00.txt>
(none) + Political Disclosure Transmission Protocol
(DISCLOSE) <draft-rfced-info-dixon-00.txt>
(bmwg) + Benchmarking Terminology for Local Area Switching
Devices <draft-ietf-bmwg-lanswitch-00.txt>
(none) + Sink-Assisted Routing Protocol (SARP) For General
IP Multicasting <draft-yong-sarp-00.txt>
(none) + SELECTING PAYMENT MECHANISMS OVER HTTP Or, Seven
Examples of UPP Over PEP (as used in JEPI)
<draft-khare-jepi-uppflow-00.txt>
IMR Editor [Page 10]
Internet Monthly Report August 1996
(none) o "irc: URL scheme" <draft-mirashi-url-irc-01.txt>
(none) + New Registries assignment, new iTLD formats and
implementation of International Top Level Domains
<draft-masek-itld-admin-00.txt>
(none) + Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI <draft-rfced-info-mills-00.txt>
(none) + Proposed Mechanism for Self-Labeling of Content
<draft-rfced-info-molitor-00.txt>
(dhc) + DHCP Options for Service Location Protocol
<draft-ietf-dhc-slp-00.txt>
(none) + Creation of and Registration in the ".NUM" Top Level
Domain <draft-rfced-info-schultz-00.txt>
(none) + Application/Directory Profile for LDAP and X.500
Knowledge <draft-wahl-know-mime-00.txt>
(none) + WebNFS Server Specification
<draft-rfced-info-callaghan2-00.txt>
(none) + The PORT Resource Record
<draft-rfced-exp-maginnis-00.txt>
(none) + Mobile Network Tracing
<draft-rfced-info-noble-00.txt>
(none) + Ruby in the Hypertext Markup Language
<draft-duerst-ruby-00.txt>
(none) + WebNFS Client Specification
<draft-rfced-info-callaghan1-00.txt>
7. There were 30 RFCs published during the month of August, 1996:
RFC St WG Title
------- -- -------- -------------------------------------
RFC1888 E (ipngwg) OSI NSAPs and IPv6
RFC1963 I (pppext) PPP Serial Data Transport Protocol (SDTP)
RFC1967 I (pppext) PPP LZS-DCP Compression Protocol
(LZS-DCP)
RFC1970 PS (ipngwg) Neighbor Discovery for IP Version 6
(IPv6)
RFC1971 PS (addrconf) IPv6 Stateless Address Autoconfiguration
RFC1972 PS (ipngwg) A Method for the Transmission of IPv6
Packets over Ethernet Networks
RFC1974 I (pppext) PPP Stac LZS Compression Protocol
RFC1975 I (pppext) PPP Magnalink Variable Resource
Compression
RFC1976 I (pppext) PPP for Data Compression in Data
Circuit-Terminating Equipment (DCE)
RFC1977 I (pppext) PPP BSD Compression Protocol
RFC1978 I (pppext) PPP Predictor Compression Protocol
RFC1979 I (pppext) PPP Deflate Protocol
RFC1980 I (none) A Proposed Extension to HTML: Client-Side
Image Maps
IMR Editor [Page 11]
Internet Monthly Report August 1996
RFC1981 PS (ipngwg) Path MTU Discovery for IP version 6
RFC1983 I (userglos) Internet Users' Glossary
RFC1984 I (none) IAB and IESG Statement on Cryptographic
Technology and the Internet
RFC1985 PS (none) SMTP Service Extension for Remote Message
Queue Starting
RFC1986 E (none) Experiments with a Simple File Transfer
Protocol for Radio Links using Enhanced
Trivial File Transfer Protocol (ETFTP)
RFC1987 I (none) Ipsilon's General Switch Management
Protocol Specification Version 1.1
RFC1988 I (none) Conditional Grant of Rights to Specific
Hewlett-Packard Patents In Conjunction
With the Internet Engineering Task
Force's Internet-Standard Network
Management Framework
RFC1989 DS (pppext) PPP Link Quality Monitoring
RFC1990 DS (pppext) The PPP Multilink Protocol (MP)
RFC1991 I (none) PGP Message Exchange Formats
RFC1992 I (nimrod) The Nimrod Routing Architecture
RFC1993 I (pppext) PPP Gandalf FZA Compression Protocol
RFC1994 DS (pppext) PPP Challenge Handshake Authentication
Protocol (CHAP)
RFC1995 PS (dnsind) Incremental Zone Transfer in DNS
RFC1996 PS (dnsind) A Mechanism for Prompt Notification of
Zone Changes (DNS NOTIFY)
RFC1997 PS (idr) BGP Communities Attribute
RFC1998 I (idr) An Application of the BGP Community
Attribute in Multi-home Routing
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( B) Best Current Practice
( E) Experimental
( I) Informational
Steve Coya <scoya at cnri.reston.va.us>
IMR Editor [Page 12]
Internet Monthly Report August 1996
INTERNET PROJECTS
-----------------
INTERNIC
--------
REGISTRATION SERVICES
The following report covers the months of July, August, and
September:
I. Significant Events
* HostReg and CReg templates are now being processed automatically;
previously they had to be processed manually; now about 50% are
being processed automatically.
* The auto-registration software now sorts requests into six
groups: (1) COM, (2) ORG, (3) NET, (4) GOV, (5) EDU and (6) TLD;
this eliminates a manual step in the process and allows the ability
to put an increased priority on GOV, EDU and TLD requests.
* Plans to initiate a night shift are under development to assist
in reducing the manual processing backlog.
* Informal training was provided for Billing CSRs regarding how to
register as a contact.
* Selection and training of a second shift for processing support
was completed; a full day training class was held on Saturday,
September 10th; final staffing arrangements were completed for a
night shift with a start date of September 30th.
* A "SWAT Team" of existing staff was used to reduce the backlog.
* Fax processing has become an overwhelming problem, requiring over
four full-time equivalent employees.
* Duane Stone and Carley Johnson represented the InterNIC DomReg
Section at Network World Interop.
* Testing of a share-ware Fax Server solution is going very well;
it would make faxes available as e-mail; the fax viewer works very
well on Sparc 5s and also supports sending faxes out; the MTS and
Ack/Nak interfaces still need to be completed.
IMR Editor [Page 13]
Internet Monthly Report August 1996
* DomReg software enhancements have reduced the number of requests
that need to be processed manually from about 1,000 to 700 (30%
improvement).
* A method for gathering performance measurements was finalized and
documented.
II. Current Status
August: Email: 221,961
Postal/Fax: 2,475
Phone: 33,497
Gopher connections: 9,684 retrievals: 27,815
WAIS connections: 48,124 retrievals: 29,125
FTP connections: 66,003 retrievals: 132,917
Mailserv: 1,338
Telnet: 103,564
Http: 3,742,911
Whois client: 1,245,005
Whois server: 7,275,885
Rich Landers <richl at internic.net>
INTERNIC DIRECTORY AND DATABASE SERVICES
InterNIC Directory and Database Services is now the "official"
source for the Netfind seed database and the Netfind source code.
The seed database is updated monthly and is available at:
http://ds.internic.net/wp/netfind-seeddb.html
The Netfind source code is available at:
http://ds.internic.net/wp/netfind-src.html
The latest version is 5.0.1.
The netfind code comes with version 1.60 beta5 of MIT's pthreads
for building pthread support if pthreads are not native. GNU make
and gcc (both available from the GNU software FTP archive) are
necessary to build MIT's pthreads.
Netfind 5.0.1 is not currently backward compatible with SunOS 4.*
and lightweight process threads (LWP). For those still wishing to
IMR Editor [Page 14]
Internet Monthly Report August 1996
provide netfind servers on SunOS platforms, v4.7 of the netfind
code has been modified to use the new seed database. The modified
version 4.7 is also available from the above web page.
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories. If you prefer, you can enter information
about your resource in our WWW suggestion form. The form can be
reached through our Directory of Directories Web page at:
http://ds.internic.net:80/ds/dsdirofdirs.html
by Rick Huber <rvh at ds.internic.net>
THE US DOMAIN REGISTRY
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The US Domain now has an online line registration form.
Some of the processing of the requests to the third level domain
name is now automated. In particular, most requests to register
names in localities already delegated are automatically forwarded
to the administrator for that locality.
The US Domain administrator no longer makes direct registrations of
hosts, and only makes delegations of third or fourth level domain
names (such as localities).
A new policy has been added to the criteria for delegating domain
names under the US Domain:
It is the intention that the delegation of third level (for
example, locality) domain names be wide spread to many
registries. It is undesirable for one person or organization
to manage a large part of the third level names in any
particular geographic or logical area.
No individual or organization shall have more than 500
delegations total in the US Domain as a whole, or more than 50
delegation in any particuilar second level (for example, a
state).
About the special domains under the state codes.
The K12, CC, TEC, LIB, STATE, DST, COG and GEN domain under
each state are established for special purposes (see RFC 1480).
IMR Editor [Page 15]
Internet Monthly Report August 1996
In addition to the constaint to use them only for the defined
purpose, each of these special domains is also to delegated
only to a manager within the state, and the operation of the
delegated registry should be non-profit.
The LIB domain should be managed by a govermental or
educational library organization.
Further, it is most appropriate for the K12, CC, and TEC,
domains to be managed by an educational organization (for
example, a university or a department of education).
The STATE domain is most appropriately managed by an agency of
the state government. DST and COG should be managed by a
goverment agency.
The GEN domain may be delegated to any organization that will
provide the registration service for free (and remember the
purpose of the GEN domain is to register statewide non-profit
organizations).
To obtain a copy of the list of other delegated localities and
subdomains not administered by the US Domain Registrar, get the
file "us-domain-delegated.txt".
URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt
For further information about the US Domain, send a message to:
US-DOMAIN at ISI.EDU, or see our WEB page:
http://www.isi.edu/us-domain
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 2975
PHONE 525
----------------------------
Total Contacts 3500
DELEGATIONS 122
FORWARDED DELEGATIONS:1014
OTHER US DOMAIN MSGS: 2364
---------------------------
Total 3500
IMR Editor [Page 16]
Internet Monthly Report August 1996
OTHER US DOMAIN MESSAGES INCLUDE: referrals to other subdomains or
to/from the InterNic, phone calls, modifications, application
requests, discussion and clarification of the requests, questions
about names, resolving technical problems with zone files and name
servers, and whois listings.
In addition, and not listed below, another 315 localities have been
delegated in Arizona, Arkansas, California, Colorado, Connecticut,
Massachusetts, Maryland, Missouri, Montana, Michigan , Mississippi,
North Carolina, New Jersey, New York, Virginia, Vermont, this
month.
MAJOR SUBDOMAINS DELEGATED
K12 CC TEC STATE LIB MUS GEN DST COG
===================================================================
51 35 33 47 38 23 23 9 4
===================================================================
-----------------------
THIRD LEVEL DELEGATIONS
-----------------------
LOCALITIES
==========
CLOVERDALE.IN.US MARINETTE.WI.US
CAPE-FEAR.NC.US PARK-RIDGE.IL.US
PENDLETON.OR.US PURGATORY.CO.US
STOW.OH.US KEWAUNEE.WI.US
OAK-LAWN.IL.US COLORADO-CITY.AZ.US
MOHAVE-VALLEY.AZ.US SHERIDAN.IN.US
PICAYUNE.MS.US CLARK.KY.US
MANCHESTER.MO.US CLEARLAKE.CA.US
PICO-RIVERA.CA.US DOWNEY.CA.US
PINE-BLUFF.AR.US MONTICELLO.AR.US
STAFFORD.VA.US NOVATO.CA.US
GOLDEN.CO.US PAWHUSKA.OK.US
URBANA.IL.US ELIZEBETH-CITY.NC.US
FAYETTEVILLE.AR.US COLUMBUS.IN.US
HAZEN.AR.US DES-ARC.AR.US
CARLISLE.AR.US BEEBE.AR.US
TROUTDALE.OR.US ASHLEY-FALLS.MA.US
HYANNIS-PORT.MA.US EDGARTOWN.MA.US
SOUTH-EGREMONT.MA.US LANESBORO.MA.US
NEW-BERN.NC.US LINDSAY.CA.US
IMR Editor [Page 17]
Internet Monthly Report August 1996
OFALLON.MO.US ELDON.MO.US
FARMINGTON.MO.US SIKESTON.MO.US
WEST-LOS-ANGELES.CA.US WLA.CA.US
GREENCASTLE.IN.US COUNCIL-BLUFFS.IA.US
BEAVER-DAM.WI.US BOSTON.MA.US
OTHER US DOMAIN DELEGATIONS THIS MONTH
--------------------------------------
CI.SPRINGBORO.OH.US CI.OGALLALA.NE.US
CI.COLUMBUS.NE.US CI.TOMAHAWK.WI.US
CI.MERRILL.WI.US CO.LINCOLN.WI.US
CO.CHATHAM.NC.US CI.WESTMINSTER.MD.US
CI.GARLAND.TX.US CI.FOUNTAIN-HILLS.AZ.US
CI.MUSKEGO.WI.US CO.WAYNE.MI.US
CO.WAYNE.NY.US CI.MCMINNVILLE.OR.US
CI.SHOW-LOW.AZ.US CO.JACKSON.OR.US
CI.GREENVILLE.NC.US CI.FORTUNA.CA.US
CI.FOUNTAIN-VALLEY.CA.US CI.DALY-CITY.CA.US
TWP.BURLINGTON.NJ.US CO.LINCOLN.NC.US
CI.ST-JOSEPH.MO.US CO.EATON.MI.US
CI.TAUNTON.MA.US CI.MARION.IN.US
CO.DELAWARE.NY.US CI.WASHINGTON.PA.US
KUWAIT.INFO.NW.DC.US CORONER.CO.FRANKLIN.OH.US
CHESAPEAKE.LIB.VA.US ABE.APALACHIN.NY.US
WIDOMAKER.WILLIAMSBURG.VA.US TMOK.GEN.RI.US
CUG.COLUMBIA.IL.US QZ.LITTLE-NECK.NY.US
BEIGE.AFFTON.MO.US PALMER.LIB.MA.US
HCSOT.TEC.NJ.US BHSALUM.BELLEFONTAINE.OH.US
LIVERMORE.LIB.CA.US MPWMD.DST.CA.US
WFRPC.DST.FL.US 43RD.CI.CHICAGO.IL.US
GREECEFEST.GREECE.NY.US HEALTH.CO.CHENANGO.NY.US
BPC.COLUMBIA.IL.US STERLINGCOLLEGE.CRAFTSBURY.VT.US
TOWNSHIP.ORION.MI.US LAMAN.LIB.AR.US
SHERRIF.CO.PULASKI.AR.US IASI.TEC.AL.US
WWCC.CC.WY.US NOCK.WASHINGTON.DC.US
MARC.WASHINGTON.DC.US MBEVILL.CC.AL.US
HEALTH.CO.ONONDAGA.NY.US STA.DST.CA.US
CRRL.LIB.VA.US ACID.WATERLOO.IL.US
WWW.CHICAGO.IL.US INFO.CHICAGO.IL.US
IMR Editor [Page 18]
Internet Monthly Report August 1996
METRO.CHICAGO.IL.US BLUERIDGESCHOOL.DYKE.VA.US
KTI.BIRMINGHAM.MI.US COLUMBUS.MARSHFIELD.WI.US
GEORGETOWN.NW.DC.US GEORGETOWN.WASHINGTON.DC.US
MARC.NW.DC.US WMR-SCCA.GEN.MI.US
GRMUSEUM.MUS.MI.US SCHULTE.JEFFERSONTOWN.KY.US
-----------------------------------------------------------
URL: http://www.isi.edu/us-domain/
Shanthi Ranganathan (US-Domain at ISI.EDU)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MERIT INTERNET ENGINEERING
--------------------------
This report summarizes August 1996 activities of Merit's Internet
Engineering group on behalf of the Routing Arbiter (RA) service and
other projects.
An incremental update client has recently been implemented for the
Routing Arbiter Database by Jerry Winters of the RADB staff. The
new client polls the RIPE registry's mirroring site every 30
minutes for database updates; previously, updates were only
provided once each day. The technology thus significantly improves
the timeliness of the Internet Routing Registry (IRR) data provided
by RAWhoisd, the whois.ra.net whois server. Winters has been
testing a server that will allow Merit to support its own database
mirroring site, much like RIPE's. This would mean that other IRR
organizations, such as MCI, CA*net, and RIPE, could update their
database copies with new RADB data as frequently as every five
minutes, rather than every 24 hours. The Merit mirroring site
would also support a hot backup system for the production RADB
database system.
As part of Merit's ongoing research on routing technologies and
protocols, IPv6 routing support has been added to the Multi-
Threaded Routing Toolkit (MRT). The development work is being
carried out by Masaki Hirabaru, an Associate Professor of
Information Science at Japan's Nara Institute of Science and
Technology, who is working at Merit for part of the 1996 academic
year. Hirabaru is developing a wide-area IPv6 testing environment
for MRT using the 6bone, a virtual network that links sites in
North America, Europe, and Japan. The 6bone is layered on top of
portions of the physical, IPv4-based Internet to support routing of
IPv6 packets, as that function has not yet been integrated into
IMR Editor [Page 19]
Internet Monthly Report August 1996
many production routers. The 6bone comprises islands of IPv6 hosts
connected by virtual point-to-point links, called tunnels. The
tunnel endpoints are typically workstation-class machines with
operating system support for IPv6. Support for RIPng and the IPv6
policy language has also been implemented in MRT, including
implementation of IPv6 access-lists and router descriptions. In
addition, Hirabaru and MRT developer Craig Labovitz have been
working with IPv6 operating system development groups to fix
several bugs in the IPv6 kernel software.
Susan R. Harris (srh at merit.edu)
UCL
----
Mark Handley and Jon Crowcroft attended SIGCOMM 96 and ran a
tworkshop day on future multicast research problems (see
http://www.cs.ucl.ac.uk/staff/jon/sigbone.html for further
information)
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
IMR Editor [Page 20]
Internet Monthly Report August 1996
CALENDAR
--------
Last update 07/9/96
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at ietf.org>
Please note: The Secretariat does not maintain on-line information
for the events listed below.
FYI - The EMail World & Internet World originally scheduled for
Sept. 10-12, 1996 has been moved to Oct. 15-17, 1996.
Boston, MA.
A copy of this calendar is available as follows:
VIA FTP
- -------
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: ftp.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
Africa Address: ftp.is.co.za (196.4.160.8)
cd ietf
ls *0mtg*
Gopher
- -------
Available on the Gopher Server running on IETF.CNRI.RESTON.VA.US
(132.151.1.35) under "Internet Engineering Task Force (IETF) / IETF
Meetings / Scheduling Calendar".
WWW
- -------
<http://www.ietf.cnri.reston.va.us/home.html> Click on the link
for "meetings" and you should find an entry "listing of other Internet
related events".
************************************************************************
IMR Editor [Page 21]
Internet Monthly Report August 1996
1996
- -----------
Oct. 1-3 Email World & Internet Expo Toronto, Ontario, CA
Oct. 2-4 Object World Tokyo Tokyo, Japan
Oct. 6-9 Asia Pacific Distributed
Solutions Event Queensland, Australia
Oct. 7-11 ANSI X3T11 St. Petersburg Bch, FL
Oct. 7-11 ATM Forum Montreux, Switzerland
Oct. 7-11 NetWorld+Interop Paris, France
Oct. 7-11 Performance 96 Conference Lausanne, Switzerland
Oct. 9-11 Object World Frankfurt Frankfurt, Germany
Oct. 13-16 IEEE Local Computer Ntwrks (LCN) Minneapolis, MN
Oct. 14-17 MEDNET '96 European Congress
of the Internet in Medicine Brighton, UK
Oct. 15 Commercenet New Orleans, LA
Oct. 15-17 EMail World & Internet Expo Boston, MA
Oct. 15-18 3rd Int'l on Protocols for
Multimedia Systems Madrid, Spain
Oct. 16-18 Internet World Monterrey '96 Monterrey, Mexico
Oct. 16-19 5th Int'l Conference on
Computer Communications & Ntwrks Rockville, MD
Oct. 17-20 IEEE Symposium on Planning & Design
of Broadband Networks Quebec, Canada
Oct. 21-25 ICECCS'96 (held jointly with
6th CSESAW, 4th IEEE RTAW) Montreal, Canada
Oct. 28-31 2nd USENIX Seattle, WA
Oct. 28-Nov. 1 NetWorld+Interop London, England
Oct. 29-31 Internet Professional '96 Paris, France
Oct. 29-Nov. 1 ICNP-96 Int'l Conf. on
Network Protocols Columbus, Ohio
Oct. 29-Nov. 1 2nd USENIX Symp. Operating Sys.
Design & Implement. (OSIDI II) Seattle, WA
Nov. 1996 OMG TC (Groupe Bull) Nice, France
Nov. 4-7 APPN Implementers Workshop Raleigh, NC
Nov. 4-8 ANSI X3T10 '96 Western Digital Palm Springs, CA
Nov. 6-8 Web Developer Mexico '96 Mexico Ciy, Mexico
Nov. 10-12 2nd annual of ACM's MobiCom '96 Rye, New York
Nov. 11-15 IEEE 802 '96 Hotel Vancouver Vancouver, BC Canada
Nov. 12-15 3rd Int'l Conf.
on Multimedia Modeling Toulouse, France
Nov. 13 Commercenet Santa Clara, CA
Nov. 18-20 2nd USENIX Workshop on
Electronic Commerce Oakland, CA
Nov. 18-22 ACM Multimedia '96 Boston, MA
Nov. 18-22 IEEE Globecom 96 London, England
Nov. 18-22 Supercomputing '96 (Firm) Pittsburgh, PA
Nov. 20-21 IEEE Global Internet '96 London, UK
Nov. 25-29 NetWorld+Interop Sydney, Australia
IMR Editor [Page 22]
Internet Monthly Report August 1996
Dec. 2-4 Web World San Diego, CA
Dec. 2-6 ANSI X3T11 Rochester, MN
Dec. 2-6 ATM Forum Vancover, BC
Dec. 4-6 Vir. Reality & VRML World '96 Boston, MA
Dec. 9-12 Internet World '96 Baltimore, MD
Dec. 9-13 37th IETF San Jose, CA
Dec. 9-13 OIW (Firm)
Dec. 10-13 Fall Internet World '96 New York, NY
Dec. 12 Internet Security for System
& Network Administrators Pittsburgh, PA
Dec. 13 Commercenet Albuquerque, NM
1997
- -----------
Jan. 6-10 ANSI X3T10 '97
Jan. 6-10 USENIX '97
Annual Technical Conf. Anaheim, CA
Jan. 6-10 USELINUX: Linux Appl. Dev. Anaheim, CA
Jan. 7-10 13th Annual Hawaii Int'l Conf
on Systems Sciences Maui, Hawaii
Jan. 7-10 Internet World Canada '97 Toronto, Canada
Jan. 21-23 Internet World Shanghai-China Shanghai, China
Jan. 21-25 Internet World Singapore Intl Singapore
Jan. 28-30 IEEE 802.10 Interim meeting Orlando, FL
Feb. 3-7 ANSI X3T11 TBA
Feb. 10-11 ISOC Symposium on Network and
Distributed System Security San Diego, CA
Feb. 17-19 Internet Expo & EMail World San Jose, CA
Mar. 1-5 ACM '97: The Next 50 yrs. of Computing
San Jose, CA
Mar. 10-13 UniForum San Francisco, CA
Mar. 10-14 OIW (Firm)
Mar. 10-14 IEEE 802 '97 Irvine?/Albuguerque
Mar. 11-14 Spring Internet World '97 Los Angeles, CA
Mar. 11-15 ANSI X3T10 '97
Mar. 17-19 1st Euromicro Working Conf. on
Software Maintenance & Reengineering
Berlin, Germany
Mar. 19-21 Internet World Asia '97 Kuala Lumpur, Malaysia
Apr. 7-11 38th IETF Memphis, TN
Apr. 7-11 ANSI X3T11 TBA
Apr. 7-11 IEEE Infocom '97 Kobe, Japan
Apr. 9-11 ISADS 97 - 3rd Intl Symposium on
Autonmous Decentralized Sys. Berlin, Germany
Apr. 22-24 Internet Expo & EMail World Chicago, IL
May 5-9 ANSI X3T10 '97
May 12-16 IFIP/IEEE San Diego, CA
May 28-30 Web Developer '97 Chicago, IL
IMR Editor [Page 23]
Internet Monthly Report August 1996
Jun. 3-5 Internet World Mexico '97 Mexico City, Mexico
Jun. 8-12 ICC '97 Montreal
Jun. 9-13 OIW (Firm)
Jun. 9-13 ANSI X3T11 TBA
Jul. 7-11 IEEE 802 '97 Hyatt Regency Maui, Lahaina HI
Jul. 14-18 ANSI X3T10 '97
Aug. 11-15 ANSI X3T11 TBA
Aug. 11-15 (tenative) 39th IETF Munich, Germany
Aug. 12-14 (tenative) Internet Expo & EMail World Boston, MA
Sep. 8-12 ANSI X3T10 '97
Sep. 8-12 OIW (Firm)
Sep. 8-14 TELECOM Interactive 97 Geneva, Switzerland
Sep. 14-18 ACM SIGCOMM '97 Cannes, French Riviera, France
Oct. 6-10 ANSI X3T11 TBA
Nov. 3-7 ANSI X3T10 '97
Dec. 8-12 OIW (Firm)
TELECOM '97 Asia (Venue and Dates to be Determined)
1998
- -----------
SPRING 1998 TELECOM '97 Africa Midrand, South Africa
Aug. 23-29 15th IFIP World. Com. Conf. Vienna, Austria and
Budapest, Hungary
1999
- -----
Oct. 8-14 TELECOM '99 Geneva, Switzerland
IMR Editor [Page 24]
Internet Monthly Report August 1996
TERENA List of Meetings
=======================
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact
the chair of the meeting or the TERENA Secretariat. If you have
additions/corrections/comments, please mail <secretariat at terena.nl>.
**********************************************************************
MEETING/DATE LOCATION
============ ========
TERENA General Assembly
-----------------------
GA6
24-25 October Bled
GA7
15-16 May 1997 Edinburgh
TERENA Executive Committee
--------------------------
17 December Amsterdam
TERENA Technical Committee
--------------------------
13 November Brussels
22 January 1997 Amsterdam
TERENA Office Meeting
---------------------
16 October Amsterdam
JENC8
-----
Conference Committee
8 November (provisional) Edinburgh
Programme Committee
4 December Amsterdam
IMR Editor [Page 25]
Internet Monthly Report August 1996
INSIGHT Training Workshop
-------
28-29 October Bled
CEEnet
------
26 October Bled
PHARE Research Networking
------
25 October Bled
-----------------------------------------------------------------
=================================================================
EEMA
----
Electronic Commerce '96 Wembley, London
15-17 October
Regional Conference
29 November - 1 December Malta
Electronic Communications Olympia, London
10-12 December
EWOS
----
TA35, 3-4 December Brussels
TA36, 25-26 February 1997 "
TA37, 13-14 May 1997 "
TA38, 16-17 September 1997 "
TA39, 2-3 December 1997 "
SC - 24 September "
SC - 17 December "
Workshops
35: 21-25 October Brussels
36: 20-24 January 1997 "
37: 7-11 April 1997 "
38: 16-20 June 1997 "
39: 27-31 October 1997 "
IMR Editor [Page 26]
Internet Monthly Report August 1996
ETSI
----
Seminar/Workshop
1-3 October Nice, France
GA24 10-11 December Nice, France
TA25 23-25 October "
IETF
----
9-13 December San Jose, CA
7-11 April 1997 Memphis, Tenn.
11-15 August 1997 Munich, Germany
RIPE
----
RIPE26
20-22 January 1997 Amsterdam
RIPE27
May 1997 Dublin
NATO Workshop
-------------
5-9 May 1997 Edinburgh
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TERENA CONFERENCES
------------------
Call for Papers
JENC8 - 8th Joint European Networking Conference
------------------------------------------------
"Diversity and Integration: The New European Networking Landscape"
12-15 May 1997
Edinburgh, Scotland
This conference will be the European Forum to get up-to-date
information, to debate and assess the new deregulated tele-
communication environment in Europe, new leading-edge applications,
and the network/internetwork support infrastructure which is
currently being developed
IMR Editor [Page 27]
Internet Monthly Report August 1996
Subject Areas:
* Emerging Network Technologies and Network Engineering
* User Support, Training and Education
* Security and Management Issues
* Information Systems and Distributed Applications
* Economic and Political Issues
Deadline for paper submission 10 November 1996 to:
<jen8-submit at terena.nl>
For information please contact the JENC8 Secretariat at:
TERENA Secretariat
Singel 466-468
1017 AW Amsterdam, The Netherlands
tel: +31 20 6391131 fax: +31 20 6393289
email: <jenc8-sec at terena.nl>
http://www.terena.nl/jenc8
or
JENC8 Local Organization
c/o Concorde Services Ltd
Unit 5, SECC
Glasgow, G3 8YW, Scotland
email: <jenc8 at ed.ac.uk>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
OTHER CONFERENCES:
-----------------
Performance '96
---------------
International Conference on Performance Theory, Measurement and
Evaluation of Computer and Communications Systems
Organized by IFIPWG7.3
7-11 October
Ecole Polytechnique Federal de Lausanne, Lausanne, Switzerland
Deadline paper submission 15 March 1996
Further information on WWW Page: http://lrcwww.epfl.ch/perf96/
IMR Editor [Page 28]
Internet Monthly Report August 1996
PROMS'96
Third International Workshop on Protocols for Multimedia Systems
----------------------------------------------------------------
15-18 October
Madrid, Spain
This workshop is intended to contribute to scientific, strategical and
practical cooperation between research institutes and industrial
companies in the area of distributed multimedia applications, protocols,
and intelligent management tools, with emphasis on their usage on
broadband networks. Papers to be submitted by 7 June. For information
contact Arturo Azcorra at <aazcorra at dit.upm.es>
6th CEN/CENELEC/ETSI Conference 1996
--------------------------------
5-6 November
Sheraton Brussels Hotel, Brussels, Belgium
Theme of this conference is "Standards on Trial: Case Studies in
European Standardization"
Deadline for abstracts is 13 Sept. For further information:
c/o CENELAC, Tel: +32 2 519 6871 Fax: +32 2 519 6919
IDATE96
18th International Conference of IDATE
--------------------------------------
6-8 November
Montpellier, France
An opportunity for professional contacts with major industrial
group leaders, users and clients, researchers and academics,
administrators and politians.
Full details of the conference available on the Web:
http://www.idate.fr
CEN/TC304 - Character Set Technology Workshop
---------------------------------------------
11-12 November
Bled, Slovenia
Providing multilingual support in middleware: Implementing the
Universal Character Set ISO 10646 in the European Information Society
For information look up URL: http://www.e5.ijs.si/i18n/ws-bled.html
IMR Editor [Page 29]
Internet Monthly Report August 1996
"The Telematics Revolution,
Consequences for Individuals and Organisations"
----------------------------------------------
13 November
University of Technology, Eindhoven, the Netherlands
Theme of the conference is that progress of information and
telecommunication technologies do create a huge number of questions,
be it social, jurisdictional, economic or technical.
Parallel sessions will deal with: interactive scientific visual-
isation, tele-learning, user aspects of multimedia, distant
consultation and using of laboratories.
For all information and to receive brochure, contact
Mr. Marc Fleskens at email address <telematics at tue.nl>
IEEE Global Internet 1996
-------------------------
20-21 November
Queen Elizabeth II Conference Centre, London
This mini-conference will provide an open forum for the communications
and computer networking communities to review the state-of-the-art
technologies and applications of the evolving Global Internet.
Deadline paper submissions 15 May to:
http://gaia.cs.umass.edu:80/tccc/internet96/
or email Jon Crowcroft <jon at cs.ucl.ac.uk>
WEB INTERNATIONALIZATION & MULTILINGUISM SYMPOSIUM
--------------------------------------------------
20-22 November
Sevilla, Spain
Organized by Sadiel and the WWW Consortium, with the support of the
European Commission. The object of this symposium is the advancement
of the internationalization and multilingualism of the Web, as well
as to seek agreement on the relevant standards.
Registration from 15 September.
For further information see:
http://www.w3.org/pub/WWW/International/Sevilla-96
IMR Editor [Page 30]
Internet Monthly Report August 1996
EITC'96 - European IT Conference
--------------------------------
25-27 November
Congress Centre, Brussels, Belgium
"Doing Business in the Information Society"
Electronic commerce, provides the focus for sessions on IT
applications, enabling technologies and international initiatives.
Post-Conference Workshops to be held on 28 November.
For information contact European Commission, DGIII or
WWW: http://www.cordis.lu/esprit/src/eitc96.htm
ASIAN'96 - Asian Computing Science Conference
---------------------------------------------
2-5 December
Singapore
Themes of this conference is:
- Programming (sematics, languages, systems, ...)
- Concurrency & Parallelism (algorithms, formalisms, systems ...)
- Networking & Security (algorithms, protocols, formalisms, ...)
Additional information available from:
http://www.escs.nus.sg/~asian96
Multimedia Computing and Networking 1997
----------------------------------------
10-12 February 1997
San Jose, CA, USA
The object of this conference is to bring together researchers,
developers, and practitioners working in all facets of multimedia
computing and networking.
Paper submission by 16 July 1996.
For further information email <mmcn at cs.utexas.edu>
COREC -"Interregional Cooperation in RTD - Challenges and
Opportunities for Regions in Economic Conversion"
---------------------------------------------------------
16-17 December
Bremen, Germany
Background is the experience of the community initiative STRIDE and
other programmes of the European Commission.The conference will deal
questions of RTD-programmes and policies, their European Dimension
and impact on regional development.
For information contact Mr. Wolfgang Petzold at:
email <wmte at uni-bremen.de>
IMR Editor [Page 31]
Internet Monthly Report August 1996
IEEE INFOCOM '97
16th Annual Joint Conference of the IEEE Computer & Communications Societies
----------------------------------------------------------------------------
7-11 April 1997
Kobe, Japan
Paper submissions by 14 June 1997.
For further information contact
http://www.ics.uci.edu/~infocom/
http:// arpeggio.ics.es.osaka-u.ac.jp/infocom.html
ISADS 97
3rd International Symposium on Autonomous Decentralized Systems
---------------------------------------------------------------
9-11 April 1997
Berlin, Germany
Supported by Hitachi, DeTeBerkom, NEC, Digital, GMD-FOCUS,
Hewlett Packard, IBM.
The focus will be on advancements and innovations in ADS platforms
and applications. Integration of telecommunication and computing
aspects into a uniform concept for providing an open distributed
processing environment.
For information see WWW: http://www.fokus.gmd.de/ws/isads97/
EEMA'97
10th Annual Conference of European Electronic Messaging Association
-------------------------------------------------------------------
16-19 June 1997
Maastricht Exhibition and Congress Centre, Maastricht, Netherlands
Issues of the conference will be:
Global Security; Corporate Directories; Messaging Products & Services;
Electronic Commerce; Global Messaging Enterprise; European Initiatives;
Mobile Messaging Technology; Messaging Technology & Management
Strategy; Intranet; World Wide Web & Infobots.
For information contact WWW: http://www.eema.org/
IMR Editor [Page 32]
Internet Monthly Report August 1996
INET'97
The Internet: The Global Frontiers
----------------------------------
24-27 June 1997
Kuala Lumpur, Malaysia
The conference will address the traditional and evolving frontiers of
the Internet as well as its significant impact on education, commerce
and societies throughout the world. Abstracts of papers to be submitted
by 10 October. -for details of submission procedure email <inet-
program-interest at isoc.org> -for program information email <inet-
program-chair at isoc.org -for general information email <inet'97 at isoc.org>
====================================================
This meeting list is also available on our WWW page:
http://www.terena.nl/news/
====================================================
IMR Editor [Page 33]
Received: from ietf.org by ietf.org id aa27444; 1 Nov 96 20:16 EST
Received: from zephyr.isi.edu by ietf.org id aa27137; 1 Nov 96 20:13 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA29438>; Fri, 1 Nov 1996 17:12:23 -0800
Message-Id: <199611020112.AA29438 at zephyr.isi.edu>
To: IETF-Announce: ;
To: Internet-Monthly-Report-People: ;
Subject: Internet Monthly Report for August, 1996
Cc: imr-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 01 Nov 96 17:12:23 PST
Sender:ietf-announce-request at ietf.org
From: IMR Editor <imr-ed at isi.edu>
--NextPart
The Internet Monthly Report for August, 1996 is now available
at the following location:
URL= ftp://ftp.isi.edu/in-notes/imr/imr9608.txt
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
Requests to be added or deleted from the IMR report list:
The Internet Monthly Report list is managed by MajorDomo atISI.EDU.
The announcements of new issues on the Internet Monthly Report
are sent to the IETF-Announce list and to this IMR list.
Requests to be added or deleted from the Internet Monthly report list
should be sent to majordomo at isi.edu with the message body either
subscribe imr or unsubscribe imr.
Requests to be added or deleted from the IETF list should be sent to
ietf-request at ietf.org.
Internet Monthly Report availability via WWW, FTP and EMAIL:
IMR Retrieval using WWW
-----------------------
The URL below may be used in web browsers to access the IMRs. You
will see a list of names in the form IMR9608.TXT. For example,
IMR9608.TXT is the report for August 1996.
URL: ftp://ftp.isi.edu/in-notes/imr
IMR Retrieval using EMAIL via the RFC-INFO Service
--------------------------------------------------
The EMail retrieval system RFC-Info will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to rfc-info at ISI.EDU with
the message body help: ways_to_get_imrs. For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from FTP.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where yymm refers to the date of
the IMR.
For example IMR9608.TXT is the report for August 1996).
Login with FTP username anonymous and password ftp.
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the current IMR.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9608
--OtherAccess
Content-Type: Message/External-body;
name="imr9608.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29530; 2 Nov 96 0:36 EST
Received: from merit.edu by ietf.org id aa29396; 2 Nov 96 0:33 EST
Received: from LapTop.Simpson.DialUp.Mich.Net (pm036-11.dialip.mich.net [141.211.7.53]) by merit.edu (8.7.6/merit-2.0) with SMTP id WAA02447 for <ietf at ietf.org>; Fri, 1 Nov 1996 22:51:02 -0500 (EST)
Date: Sat, 2 Nov 96 03:19:20 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <2159.wsimpson at greendragon.com>
To: ietf at ietf.org
Subject: Evaluating TLD proposal
Source-Info: From (or Sender) name not authenticated.
I had gotten rather far behind, and just read Sep thru Oct IETF list.
But at least this way, I am reasonably assured of not duplicating anyone
else's comments....
Having actually read many/most of the TLD proposals in the past, and
written one myself, I have a few comments that might focus this
discussion, which has gone rather far afield:
I think that Denninger has some valid points. I just wish that he would
have tried to resolve the issues _within_ the IETF, rather than
attempting a go-around. OTOH, the IANA didn't use IETF process, either!
I particularly object to some of the language in the current
draft-postel-iana-itld-admin-02.txt:
3.2 The Board of Trustees acts for the ISOC, the IAB for the IETF,
and the IANA for itself.
While the organizations RFC is fresh as we speak, and I have not yet
checked it, historically the IANA reports to the IAB, not unto itself.
And the IESG (rather than the IAB) speaks for the IETF.
Many of the objections to the Postel draft probably arise from this
attempt to shrug off oversight. The IANA needs oversight, just like
everything else. Checks and Balances!
Denninger also raises the valid point that the proposed fees and such
for the new registries do not apply to the existing registries. That is
excrable. If the IANA is to be supported by fees, then the largest
existing load should start right out by paying its fair share!
I also have raised the issue in the past that this fee structure is not
the best we could devise. What is the purpose of an "application fee"?
Why have both a quarterly/yearly fee, and a percentage fee?
Instead, I have recommended that the applicant post a "performance
bond". As in other corporate contracts, this bond would be used to pay
for rebidding and conversion to another contractor in the event that the
initial contractor defaults. It could earn interest. It could be
refundable at the termination of a successful contract.
And I would make the quarterly fee entirely based on the number of
domain registrants. As noted, this is relatively simple to verify. It
makes more sense than administering 2 fees, one fixed and one variable,
or worrying about percentages.
This fee would be changed yearly to reflect the needed funds for the
IANA and IETF Secretariate. I would not use any fee to directly fund
root name servers, which for engineering reasons should be located at
(and funded by) the major topological exchanges as they are built.
Oh, and I find the draft (for a third revision) to have rather a lot of
English problems for a native speaker ;-)
WSimpson at UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson at MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Received: from ietf.org by ietf.org id aa19130; 2 Nov 96 2:18 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa17629;
2 Nov 96 2:14 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199611020712.QAA01510 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id QAA01510; Sat, 2 Nov 1996 16:12:14 +0900
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: Phil Karn <karn at qualcomm.com>
Date: Sat, 2 Nov 96 16:12:13 JST
Cc: ERIC at vm.se.lsoft.com, ietf at ietf.org
In-Reply-To: <199611012236.OAA09605 at servo.qualcomm.com>; from "Phil Karn" at Nov 1, 96 2:36 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
Phil;
> Americans are among the most assertive and outspoken people in the
> world, and American IETFers are among the most assertive and outspoken
> Americans. Our passions can easily intimidate those of other cultures
> (especially Asians) into offended silence. As a result, simple
> misunderstandings can erupt into major battles or at least long-term
> resentment.
Sorry for my insufficient effort to be as assertive and outspoken as
people in US. I'll try harder.
But, to confirm your statement, let's have an experiment to use
Japanese for the discussion and compare who are more assertive
and outspoken, you or me. Note that your misspelling and
grammatical errors are tolerated.
Are you ready?
Now, let's begin. Deha, hajimemashou.
Watasiha Azia jin ga tokuni otonasii toha omoimasenyo. Tanni
amerika jin ya youroppa jin yori eigoga dekinai hitoga ooito
iu dakeno kotodeha?
Nihon no nyuusu guruupu demo, kappatu ni ikenwo iu hitoha
ikurademo imasu.
Masataka Ohta
Received: from ietf.org by ietf.org id aa27082; 2 Nov 96 3:25 EST
Received: from cnri by ietf.org id aa26985; 2 Nov 96 3:22 EST
Received: from [204.250.49.77] by CNRI.Reston.VA.US id aa04022;
2 Nov 96 3:22 EST
Received: from [204.250.49.20] by mail.coupon.net
with ESMTP (Apple Internet Mail Server 1.1.1); Sat, 2 Nov 1996 00:20:48 -0800
Message-Id: <v03007803aea0b25a2618 at [204.250.49.20]>
In-Reply-To: <QQbnzv10613.199611012257 at rodan.UU.NET>
References: Your message of "Fri, 01 Nov 1996 16:21:03 CST."
<01BBC810.AE47E5C0 at webster.unety.net>
<01BBC810.AE47E5C0 at webster.unety.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 2 Nov 1996 00:20:24 -0800
To: "Louis A. Mamakos" <louie at uu.net>, Jim Fleming <JimFleming at unety.net>
Sender:ietf-request at ietf.org
From: Simon Higgs <simon at higgs.com>
Subject: Re: Folling the crumbling cartel - a note about thread
following
Cc: Karl Denninger <karl at mcs.net>,
"ietf at CNRI.Reston.VA.US" <ietf at CNRI.Reston.VA.US>,
'New Newdom' <newdom at vrx.net>, "sthaug at nethelp.no" <sthaug at nethelp.no>
Source-Info: From (or Sender) name not authenticated.
At 5:57 PM -0500 11/1/96, Louis A. Mamakos wrote:
> While I can't speak on behalf of all of UUNET, I can certainly
> offer my opinion. I don't think that UUNET would be interested
> in running a "rogue" root name server.
Didn't Rick Adams... nah... must've been a dream.
Simon
--
"The only thing to prevent what's past is to put a stop to it before it
happens."
-- attributed to Sir Boyle Roche, eighteenth-century member of
Parliament from Tralee, famed for his word-mangling
Received: from ietf.org by ietf.org id aa29685; 2 Nov 96 4:11 EST
Received: from nic.hq.cic.net by ietf.org id aa29592; 2 Nov 96 4:09 EST
Received: from localhost (dorian at localhost) by nic.hq.cic.net (8.8.2/CICNet) with SMTP id EAA08433; Sat, 2 Nov 1996 04:08:22 -0500 (EST)
Date: Sat, 2 Nov 1996 04:08:22 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Dorian R. Kim" <dorian at cic.net>
X-Orig-Sender: dorian at cic.net
Reply-To: "Dorian R. Kim" <dorian at cic.net>
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
cc: ietf at ietf.org
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
In-Reply-To: <199611020712.QAA01510 at necom830.hpcl.titech.ac.jp>
Message-ID: <Pine.SOL.3.95.961102040234.24074F-100000 at nic.hq.cic.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 2 Nov 1996, Masataka Ohta wrote:
> Sorry for my insufficient effort to be as assertive and outspoken as
> people in US. I'll try harder.
Mr. Ohta, please permit me to observe that you don't seem to one of those to
whom Mr. Karn was referring to.
While tentativeness because of unfamiliar language is part of the reason,
differences across cultures of the mode and tone of formal exchange is one of
possible reason why some people might feel less inclined to step up to the mic
at meetings.
-dorian, a non-native speaker of English or American.
Received: from ietf.org by ietf.org id aa00212; 2 Nov 96 4:15 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa00135;
2 Nov 96 4:14 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199611020912.SAA01892 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id SAA01892; Sat, 2 Nov 1996 18:11:53 +0859
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: dorian at cic.net
Date: Sat, 2 Nov 96 18:11:52 JST
Cc: mohta at necom830.hpcl.titech.ac.jp, ietf at ietf.org
In-Reply-To: <Pine.SOL.3.95.961102040234.24074F-100000 at nic.hq.cic.net>; from "Dorian R. Kim" at Nov 2, 96 4:08 am
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
dorian;
> While tentativeness because of unfamiliar language is part of the reason,
> differences across cultures of the mode and tone of formal exchange is one of
> possible reason why some people might feel less inclined to step up to the mic
> at meetings.
>
> -dorian, a non-native speaker of English or American.
dakara, chanto youroppa jintono chigaimo nobete arudeshouga.
nihongo no bubun yondekara forou site hosiin desukedo?
anata nihon no nyuusu guruupu deno ronchou, mitakoto arimasu?
Masataka Ohta
Received: from ietf.org by ietf.org id aa25963; 2 Nov 96 17:04 EST
Received: from aun.uninett.no by ietf.org id aa23649; 2 Nov 96 16:54 EST
Received: from dale.uninett.no (actually trhm8.or.uninett.no) by aun.uninett.no
with SMTP (PP); Sat, 2 Nov 1996 22:52:41 +0100
Received: from dale.uninett.no (localhost [127.0.0.1])
by dale.uninett.no (8.6.9/8.6.12) with ESMTP id WAA02315
for <ietf at ietf.org>; Sat, 2 Nov 1996 22:33:18 +0100
Sender:ietf-request at ietf.org
From: Harald.T.Alvestrand at uninett.no
To: ietf at ietf.org
Subject: Directories, names and addresses (Re: Re[3]: The cartel begins to
crumble?)
In-reply-to: Your message of "Fri, 01 Nov 1996 12:08:10 PST." <199611012008.MAA09393 at giant.genesyslab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2311.846970398.1 at dale.uninett.no>
Date: Sat, 02 Nov 1996 22:33:18 +0100
Message-ID: <2313.846970398 at dale.uninett.no>
X-Orig-Sender: hta at dale.uninett.no
Source-Info: From (or Sender) name not authenticated.
Someone is losing their sense of reality if they're talking as if
we could insert directory lookups in the middle of a mail forward
path.
Get real.
A NAME is not an ADDRESS.
SEARCH CRITERIA are not NAMES.
The DNS is for NAME to ADDRESS lookup (plus some auxillary functions).
A directory service is for SEARCH CRITERIA to NAME lookup.
Having a real directory MIGHT help the NAME ALLOCATION problem because
it's not so important that my NAME is "the only one of its kind".
But E-mail addresses and URLs are NAMES, NOT search critera; the
reason why we want them to be strings, not numbers, is because they
are easier to REMEMBER (IMHO, of course).
Harald A
Received: from ietf.org by ietf.org id aa27464; 3 Nov 96 7:20 EST
Received: from mail.u-net.net by ietf.org id aa27269; 3 Nov 96 7:16 EST
Received: from sgml.u-net.com ([193.119.188.188]) by mail.u-net.net with SMTP id <40581-18389>; Sun, 3 Nov 1996 12:11:45 +0000
X-Sender: mtbryan-sgml at mail.u-net.com
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To:Misha Wolf <MISHA.WOLF at reuters.com>, ietf <ietf at ietf.org>
Sender:ietf-request at ietf.org
From:Martin Bryan <mtbryan at sgml.u-net.com>
Subject: Re: Tenth Int'l Unicode Conference - Call for Papers - Final
Reminder
Message-Id: <96Nov3.121145+0000_gmt.40581-18389+467 at mail.u-net.net>
Date:Sun, 3 Nov 1996 12:11:45 +0000
Source-Info: From (or Sender) name not authenticated.
Gerhard
At 20:41 1/11/96 -0500, Man-Sze wrote:
>Character sets are becoming ubiquitous - the Icelanders should be pleased.
>Man-Sze
>
> Tenth International Unicode Conference
> and
> Global Computing Showcase
>
> Europe, Software + the Internet: Going Global with Unicode**
>
> March 10-11, 1997
>
> Mainz, Germany
>
I have had a couple of mailings re this conference, but had written it off
due to the budget limitations, but now that Man-Sze has flagged it wonder
whether you feel it is a conference we should be reporting on next year?
Martin
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK
Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/
Received: from ietf.org by ietf.org id aa20337; 4 Nov 96 4:14 EST
Received: from josef.ifi.unizh.ch by ietf.org id aa20071; 4 Nov 96 4:03 EST
Received: from ifi.unizh.ch by josef.ifi.unizh.ch
id <00455-0 at josef.ifi.unizh.ch>; Mon, 4 Nov 1996 10:01:50 +0100
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: Phil Karn <karn at qualcomm.com>
Date: Mon, 4 Nov 1996 10:01:47 +0100 (MET)
Cc: ERIC at vm.se.lsoft.com, ietf at ietf.org
In-Reply-To: <199611012236.OAA09605 at servo.qualcomm.com> from "Phil Karn" at Nov 1, 96 02:36:17 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 650
Sender:ietf-request at ietf.org
From: Martin J Duerst <mduerst at ifi.unizh.ch>
X-Orig-Sender: mduerst at ifi.unizh.ch
Message-ID: <"josef.ifi..123:04.10.96.09.01.51"@ifi.unizh.ch>
Source-Info: From (or Sender) name not authenticated.
Phil Karn wrote:
>The IETF is an English-speaking, US-centric organization because the
>Internet originated in the US.
Definitely not so for "English-speaking"! English is the major language
in business, in science, in diplomacy, and so on. The Internet is no
exception at all.
Regards,Martin.
----
Dr.sc. Martin J. Du"rst ' , . p y f g c R l / =
Institut fu"r Informatik a o e U i D h T n S -
der Universita"t Zu"rich ; q j k x b m w v z
Winterthurerstrasse 190 (the Dvorak keyboard)
CH-8057 Zu"rich-Irchel Tel: +41 1 257 43 16
S w i t z e r l a n d Fax: +41 1 363 00 35 Email: mduerst at ifi.unizh.ch
----
Received: from ietf.org by ietf.org id aa22289; 4 Nov 96 6:14 EST
Received: from dxmint.cern.ch by ietf.org id aa22201; 4 Nov 96 6:11 EST
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch
with SMTP id MAA10858; Mon, 4 Nov 1996 12:10:16 +0100 (MET)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM)
id AA01706; Mon, 4 Nov 1996 12:10:15 +0100
Message-Id: <9611041110.AA01706 at dxcoms.cern.ch>
Subject: Re: Evaluating TLD proposal
To: William Allen Simpson <wsimpson at greendragon.com>
Date: Mon, 4 Nov 1996 12:10:15 +0100 (MET)
Sender:ietf-request at ietf.org
From: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Cc: ietf at ietf.org
In-Reply-To: <2159.wsimpson at greendragon.com> from "William Allen Simpson" at Nov 2, 96 03:19:20 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Bill,
> I particularly object to some of the language in the current
> draft-postel-iana-itld-admin-02.txt:
>
> 3.2 The Board of Trustees acts for the ISOC, the IAB for the IETF,
> and the IANA for itself.
>
> While the organizations RFC is fresh as we speak, and I have not yet
> checked it, historically the IANA reports to the IAB, not unto itself.
Correct, which is why the IAB is in the appeals chain defined by the
draft.
> And the IESG (rather than the IAB) speaks for the IETF.
Well, both the IESG and the IAB are appointed by the IETF NomCom,
so I don't think you can really complain here. The IAB specifically
decided not to appoint any of its own members to the IAHC,
to avoid conflict of interest. However, we also had some feeling
that next time around (if there is a next time) an open nomination
process would be better.
>
> Many of the objections to the Postel draft probably arise from this
> attempt to shrug off oversight. The IANA needs oversight, just like
> everything else. Checks and Balances!
I think this is generally agreed, and the IAHC is a first attempt
at broadening the scope of the oversight outside the geek community.
We are certainly not done with this topic yet.
>
> Denninger also raises the valid point that the proposed fees and such
> for the new registries do not apply to the existing registries. That is
> excrable. If the IANA is to be supported by fees, then the largest
> existing load should start right out by paying its fair share!
I think many people would agree to that, but how do you retro-fit
it into existing contracts and business plans?
Brian Carpenter
Received: from ietf.org by ietf.org id aa23082; 4 Nov 96 6:47 EST
Received: from josef.ifi.unizh.ch by ietf.org id aa23014; 4 Nov 96 6:46 EST
Received: from ifi.unizh.ch by josef.ifi.unizh.ch
id <00993-0 at josef.ifi.unizh.ch>; Mon, 4 Nov 1996 12:43:10 +0100
Subject: Re: The cartel begins to crumble? - .com crowding
To: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Mon, 4 Nov 1996 12:43:09 +0100 (MET)
Cc: jed at llnl.gov, ietf at ietf.org
In-Reply-To: <18153.9611011536 at huey.xylogics.com> from "Gary Scott Malkin" at Nov 1, 96 10:36:25 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2221
Sender:ietf-request at ietf.org
From: Martin J Duerst <mduerst at ifi.unizh.ch>
X-Orig-Sender: mduerst at ifi.unizh.ch
Message-ID: <"josef.ifi..396:04.10.96.11.43.20"@ifi.unizh.ch>
Source-Info: From (or Sender) name not authenticated.
Gary Malkin wrote:
>> >The *.COM TLD is crowded, but only because everyone seems to want to
>> >crowd into it ... probably exactly because it is so crowded.
>>
>> I think this is about right. A specific angle on this is that
>> I (and I suspect I am not alone) often will try
>
>Actually, I think that most people register under .com because they
>don't know that anything else exists. I don't think I've ever seen
>any URL advertised on TV that wasn't a .com.
Well, advertisements on TV are called COMmercialls, aren't they :-?
>I think we could solve
>some of the crowding simply by insisting that a .com name truely be
>a company/corporation (i.e., not the name of a movie, or someones
>pet project).
I guess the main reason for somebody registering (as a compay) under
.com is that if e.g. you are looking for IBM, you will look at
ibm.com. If we have .biz (which I assume stands for business),
I would have to try with ibm.com and ibm.biz. That may be good
for some higher "equal opportunity" aim, but it's a pain for
everyday use. And in case IBM also registers ibm.biz, that only
shows how unnecessary .biz actually is. Also, if registration
on TLDs is opened on a first-come-first-served base, .ibm will
soon be reserved, even if there are quite heavy requirements
on TLD registration. Companies such as IBM certanily have
no problem finding out how they already meet the requirements.
This would be the equivalent to just abolishing the concept of
TLDs altogether.
Also, most of the current TLDs are country TLDs. All around the
world, except for the US, this works well. The traditional
.com, .mil, .edu,... domains are there for backwards compatibility.
Ideally, they would be .com.us, .mil.us, .edu.us, as there is
.co.jp and .ac.jp (don't know for .mil.jp :-) in Japan.
.com and .org might have some justification for multinational
companies and international organizations, and there might
be other cases where a deviation from the rule TLD==country
can be justified, but the idea of creating additional junk TLDs
for commercial US interests (whoever gets the money) is only
justifying the prejudices people elsewhere in the world have
about the US and some of its inhabitants..
Regards,Martin.
Received: from ietf.org by ietf.org id aa24869; 4 Nov 96 8:13 EST
Received: from relay5.UU.NET by ietf.org id aa24672; 4 Nov 96 8:09 EST
Received: from uucp5.UU.NET by relay5.UU.NET with SMTP
(peer crosschecked as: uucp5.UU.NET [192.48.96.36])
id QQbojk06407; Mon, 4 Nov 1996 08:03:55 -0500 (EST)
Received: from excel.UUCP by uucp5.UU.NET with UUCP/RMAIL
; Mon, 4 Nov 1996 08:03:55 -0500
Received: from cc:Mail by excel.xl.com
id AA847123737 Mon, 04 Nov 96 08:08:57
Date: Mon, 04 Nov 96 08:08:57
Sender:ietf-request at ietf.org
From: sholland <sholland at xl.com>
Encoding: 2286 Text
Message-Id: <9610048471.AA847123737 at excel.xl.com>
To: daniel at sems.co.jp, ietf at ietf.org, Koo Chee Kai <kcheekai at singnet.com.sg>
Subject: Re[2]: Sorry to intrude.
Source-Info: From (or Sender) name not authenticated.
Count me in on that action too. I want outta this listserver. I already tried
the normal way and it didn't work. So kick me off please!!!!!!!
Sue
______________________________ Reply Separator _________________________________
Subject: Re: Sorry to intrude.
Author: Koo Chee Kai <kcheekai at singnet.com.sg> at Internet
Date: 11/2/96 8:30 AM
Received: by ccmail
Received: from uunet by xl.com (UUPC/extended 1.11) with UUCP;
Sat, 02 Nov 1996 08:28:29 EST
Received: from ietf.org by relay1.UU.NET with SMTP
(peer crosschecked as: ietf.org [132.151.1.19])
id QQboam04663; Fri, 1 Nov 1996 22:05:48 -0500 (EST)
Received: from ietf.org by ietf.org id aa18339; 1 Nov 96 18:58 EST
Received: from sunflower.singnet.com.sg by ietf.org id aa18288;
1 Nov 96 18:57 EST
Received: from LOCALNAME (ts900-6009.singnet.com.sg [165.21.162.93]) by
sunflower .singnet.com.sg (8.6.12/8.6.9) with SMTP id HAA20054; Sat, 2 Nov 1996
07:56:20 +0 800
Date: Sat, 2 Nov 1996 07:56:20 +0800
Message-Id: <199611012356.HAA20054 at sunflower.singnet.com.sg>
X-Sender: kcheekai at singnet.com.sg
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: daniel at sems.co.jp, ietf at ietf.org
Sender: ietf-request at ietf.org
From: Koo Chee Kai <kcheekai at singnet.com.sg>
X-ccAdmin: NOBODY at uunet
Subject: Re: Sorry to intrude.
Source-Info: From (or Sender) name not authenticated.
Try sending a mail to
ietf-request at IETF.CNRI.Reston.VA.US
with the subject as "unsubscribe"
Good luck.
At 01:07 PM 10/31/96 -0800, Daniel Minoru Saito wrote:
>I hate to protrude into this nice little conversation in regards to `The
>cartel begins to crumble...` but if anyone could show me the way out of
>this listserver. It isn`t the type of conversation that I was looking
>for.
>
>I tried various times requesting the listserver to UNSUBSCRIBE me but no
>luck.
>
>So I have three options:
>
>1.) Ask politely on the listserver newsgroup in how to get out.
>2.) Be a complete ASSHOLE in my efforts and get kicked out.
>3.) Hack into the listserver and then crash the whole listserver at
>listproc at wugate.wustl.edu.
>
Received: from ietf.org by ietf.org id aa25496; 4 Nov 96 8:30 EST
Received: from dfw-ix12.ix.netcom.com by ietf.org id aa25411; 4 Nov 96 8:28 EST
Received: from wdenton.Columbiasc.NCR.COM ([153.78.216.140]) by dfw-ix12.ix.netcom.com (8.6.13/8.6.12) with SMTP id FAA16986; Mon, 4 Nov 1996 05:27:19 -0800
Message-ID: <327DEF50.25A3 at columbiasc.ncr.com>
Date: Mon, 04 Nov 1996 08:27:44 -0500
Sender:ietf-request at ietf.org
From: Neil Denton <neil.denton at columbiasc.ncr.com>
Organization: NCR Corporation
X-Mailer: Mozilla 2.02 (Win95; I)
MIME-Version: 1.0
To: ietf at ietf.org
CC: daniel at sems.co.jp, Koo Chee Kai <kcheekai at singnet.com.sg>
Subject: Re: Re[2]: Sorry to intrude.
References: <9610048471.AA847123737 at excel.xl.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
KICK ME TOO! PLEASE. I'm NOT GETTING PERSONAL MAIL.
I Speak english.....but this is outrageous.
KICK ME! KICK ME!
Neil
sholland wrote:
>
>
>
> Count me in on that action too. I want outta this listserver. I already tried
> the normal way and it didn't work. So kick me off please!!!!!!!
>
> Sue
>
> ______________________________ Reply Separator _________________________________
> Subject: Re: Sorry to intrude.
> Author: Koo Chee Kai <kcheekai at singnet.com.sg> at Internet
> Date: 11/2/96 8:30 AM
>
> Received: by ccmail
> Received: from uunet by xl.com (UUPC/extended 1.11) with UUCP;
> Sat, 02 Nov 1996 08:28:29 EST
> Received: from ietf.org by relay1.UU.NET with SMTP
> (peer crosschecked as: ietf.org [132.151.1.19])
> id QQboam04663; Fri, 1 Nov 1996 22:05:48 -0500 (EST)
> Received: from ietf.org by ietf.org id aa18339; 1 Nov 96 18:58 EST
> Received: from sunflower.singnet.com.sg by ietf.org id aa18288;
> 1 Nov 96 18:57 EST
> Received: from LOCALNAME (ts900-6009.singnet.com.sg [165.21.162.93]) by
> sunflower .singnet.com.sg (8.6.12/8.6.9) with SMTP id HAA20054; Sat, 2 Nov 1996
> 07:56:20 +0 800
> Date: Sat, 2 Nov 1996 07:56:20 +0800
> Message-Id: <199611012356.HAA20054 at sunflower.singnet.com.sg>
> X-Sender: kcheekai at singnet.com.sg
> X-Mailer: Windows Eudora Light Version 1.5.2
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"
> To: daniel at sems.co.jp, ietf at ietf.org
> Sender: ietf-request at ietf.org
> From: Koo Chee Kai <kcheekai at singnet.com.sg>
> X-ccAdmin: NOBODY at uunet
> Subject: Re: Sorry to intrude.
> Source-Info: From (or Sender) name not authenticated.
>
> Try sending a mail to
>
> ietf-request at IETF.CNRI.Reston.VA.US
>
> with the subject as "unsubscribe"
>
> Good luck.
>
>
> At 01:07 PM 10/31/96 -0800, Daniel Minoru Saito wrote:
> >I hate to protrude into this nice little conversation in regards to `The
> >cartel begins to crumble...` but if anyone could show me the way out of
> >this listserver. It isn`t the type of conversation that I was looking
> >for.
> >
> >I tried various times requesting the listserver to UNSUBSCRIBE me but no
> >luck.
> >
> >So I have three options:
> >
> >1.) Ask politely on the listserver newsgroup in how to get out.
> >2.) Be a complete ASSHOLE in my efforts and get kicked out.
> >3.) Hack into the listserver and then crash the whole listserver at
> >listproc at wugate.wustl.edu.
> >
>
Received: from cnri by ietf.org id aa26554; 4 Nov 96 8:53 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09408;
4 Nov 96 8:53 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA14663 at pad-thai.cam.ov.com>; Mon, 4 Nov 1996 13:15:34 GMT
Received: from clbull.frcl.bull.fr by MIT.EDU with SMTP
id AA24807; Mon, 4 Nov 96 08:15:26 EST
Received: from emsc.frcl.bull.fr (emsc.frcl.bull.fr [129.182.42.100]) by clbull.frcl.bull.fr (8.7.5/8.7.3) with SMTP id OAA16138 for <cat-ietf at MIT.EDU>; Mon, 4 Nov 1996 14:14:45 +0100
Received: by emsc.frcl.bull.fr (AIX 3.2/UCB 5.64/4.03)
id AA28133; Mon, 4 Nov 1996 14:04:12 +0100
From: Denis Pinkas <D.Pinkas at frcl.bull.fr>
Message-Id: <9611041304.AA28133 at emsc.frcl.bull.fr>
Subject: INFOSEC'COM 97
To: IETF CAT WG <cat-ietf at mit.edu>
Date: Mon, 4 Nov 1996 14:04:11 +0100 (NFT)
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 2.4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
INFOSEC'COM
International Congress on=20
Information Systems and Telecommunications Security
12 . 13 June 1997 - CNIT Paris-La Defense - FRANCE
Invitation to submit Presentations
The International Congress on Information Systems and Telecommunications=20
Security presents the state of the art, innovations, prospects and new=20
openings in the fields of information systems and telecommunications=20
security. The information presented is novel and the presentations by the=
=20
speakers are both diversified and of a high standard. As such, they are=20
mostly intended for specialists in the field (information systems securit=
y=20
managers, computer manufacturers, software publishers, consultants, ...).
This Congress will take place in Paris (CNIT La Defense) alongside the=20
INFOSEC trade fair (from June 11 to June 13) where the exhibitors will=20
demonstrate their know-how in the area of information systems security=20
products and services.
To make things even more attractive, June happens to be the most pleasant=
=20
period of the year to visit Paris.=20
The Programmes Committee will carefully study all submitted proposals for=
=20
lectures and select those that will be included in the programme.=20
Selection is based on the following criteria: originality and novelty of=20
the lecture, relevance of the topic, quality of the speaker, the=20
scientific contents of the presentation, ...=20
The Congress focuses on the latest breakthroughs and prospects for the=20
various security techniques, both in terms of theory and practice.
For 1997, the Programmes Committee will essentially, though not=20
exclusively, emphasise the following themes:
* Security organisation and engineering
* Security issues in the area of information outsourcing
* Cryptographic technologies update
* Practical implementation of trusted third parties, their missions=20
guarantees, relationships between trusted third parties, ...
* Internet and information superhighways: "firewalls", integrated=20
offerings by network operators and software publishers, the role of=20
access suppliers, the war against viruses, ...
* Electronic commerce security
* Radiocommunications security
* Sector-specific issues (banking, health services, ...)
* Legal trends in the field of security, for instance on Internet,=20
copyrights, intellectual property, protection of youth, taxes, ...
* Etc.
Programme s Committee
Walter FUMY - SIEMENS AG (D)
Marc GIRAULT - SEPT (F)
Hans GLISS - DATENSCHUTZ-BERATER (D)
Andr=E9 GRISSONNANCHE - AGC (F)
Fr=E9d=E9ric HUYNH - CLUSIF (F)
Jean-Philippe JOUAS - CSC (F)
Jean-Marc LAMERE - FFSA (F)
Jo=EBl LEBIDOIS - THOMSON CSF (F)
Jean MENTHONNEX - EPI Conseil (CH)
Christopher MITCHELL - UNIVERSITY OF LONDON (UK)
Denis PINKAS - BULL (F)
Philippe ROSE - LE MONDE INFORMATIQUE (F)
Gilles RUGGIU - BERTIN ET CIE (F)
Pieter VAN DIJKEN - SHELL INT. PETROLEUM (NL)
Michael WALKER - VODAFONE (UK)
GENERAL INFORMATION
DATES=09
- Congress: 12.13 June 1997
- Exhibition: 11.12.13 June 1997
SITE
C.N.I.T. Paris-La Defense - 4 Place de la Defense -=20
92090 PARIS LA DEFENSE - France
OFFICIAL LANGUAGES
French and English - Simultaneous interpretation.
ACCOMMODATION=20
CIP Hotel will help you to book a room.
Tel : 33 (0)1 44 70 29 36 or 33 (0)1 44 70 25 02
Fax : 33 (0)1 44 70 24 48
ASSISTANCE
M.C.I. could help you in organizing your stay in Paris.
TRAVEL DISCOUNTS
AIR INTER, AIR LIBERTE, TAT EUROPEAN AIRLINES and SNCF.
HOW TO GET THERE
Information will be given in: Programme and Participant's Card.
REGISTRATION FEE (participant) : FF 4.980 (taxes incl.)
Price will include: access to conference-rooms, participant's file,=20
proceedings, 2 lunches, 4 coffee-breaks, visit and catalogue of the=20
INFOSEC exhibition.
REGULATION
HOW TO SUBMIT A PROPOSAL
Send the "Project for Paper" by December 3, 1996
Or use Electronic mail: clusif at clusif.asso.fr
Overtly "commercial" presentations are inappropriate.
ACCEPTANCE
Authors will be notified of rejection or acceptance by December 31 . But=20
the Programmes Committee reserves the right to reconsider its decision=20
upon presentation of the full paper due no later than February 28 :=20
paper in French or English + 2 abstracts (French and English) + biography=
=20
+ photo.
Authors will have to certify their paper will not be published prior to=20
June 12, 1997.=20
PRESENTATION PROPOSAL
Approximately 25 minutes.
BENEFITS FOR SPEAKERS
Free admission offered (congress and exhibition).
PATRONAGE
CLUSIF - Club de la Securite Informatique Francais
ORGANISATION=20
MCI - Manifestations & Communications Internationales
19 Rue d'Athenes - 75009 PARIS - FRANCE
T=E9l : 33 (0)1 44 53 72 20 - Fax : 33 (0)1 44 53 72 22
Received: from cnri by ietf.org id aa27055; 4 Nov 96 9:01 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa09579;
4 Nov 96 9:01 EST
Received: from MIT.EDU by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA15259 at pad-thai.cam.ov.com>; Mon, 4 Nov 1996 13:33:25 GMT
Received: from pad-thai.cam.ov.com by MIT.EDU with SMTP
id AA23387; Mon, 4 Nov 96 08:33:24 EST
Received: from winkl.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <NAA15254 at pad-thai.cam.ov.com>; Mon, 4 Nov 1996 13:33:22 GMT
Received: from localhost by winkl.cam.ov.com (8.6.10/4.7) id IAA02391; Mon, 4 Nov 1996 08:33:23 -0500
Message-Id: <199611041333.IAA02391 at winkl.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Fwd: Internet-Draft CUTOFF Date
Date: Mon, 04 Nov 1996 08:33:21 -0500
From: John Linn <linn at cam.ov.com>
[For the benefit of any CAT-related document editors who are not
also subscribers to the general IETF announcement list. --jl]
------- Forwarded Message
Received: from ietf.org by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <VAA15816 at pad-thai.cam.ov.com>; Fri, 1 Nov 1996 21:06:28 GMT
Received: from ietf.org by ietf.org id aa00358; 1 Nov 96 15:34 EST
Received: from localhost by ietf.org id aa00235; 1 Nov 96 15:32 EST
To: ;@IETF-Announce
Subject: Internet-Draft CUTOFF Date
Date: Fri, 01 Nov 1996 15:32:19 -0500
Sender: ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9611011532.aa00235 at ietf.org>
The cut-off for Internet-Draft submissions prior to the San Jose IETF
meeting is Tuesday, November 26, 1996 at 5pm ET. Internet-Drafts
received after this time will not be announced nor made available in
the Internet-drafts Directories.
We will begin processing Internet-Draft submissions the week
following the IETF meeting.
Thank you for your understanding and cooperation. Please do not
hesitate to contact me if you have any questions or concerns.
Kind Regards,
Cynthia Clark
Internet-Drafts Administrator
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa28479; 4 Nov 96 9:46 EST
Received: from localhost by ietf.org id aa27743; 4 Nov 96 9:29 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kahle-mail-archive-00.txt
Date: Mon, 04 Nov 1996 09:29:24 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611040929.aa27743 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Restricting the External Archiving of Email
Author(s) : B. Kahle
Filename : draft-kahle-mail-archive-00.txt
Pages : 2
Date : 10/31/1996
This draft proposes a mail header field "Restrict:" with a defined value of
"no-external-archive" that gives information to a receiving mail transport
agent or mail user agent that this message should not be archived by
individuals or organizations not associated with the list owner.
With the increasing number of search engines that gather information and
offer wide access, some writers and would like to restrict how their words
are distributed.
Mailing lists may begin (or have already begun) to be systematically
archived for searching and historical reference. This draft is designed
for mailing lists, but it can also be applied to messages in Usenet
newsgroups as well.
The legal issues around this are deep and difficult, and
this draft does not address these legal issues. However, it would be
useful to respectful mail receivers if there was a standard method
for mail creators (authors or list owners) to express their desires about
whether or not their mail can be archived.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-kahle-mail-archive-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kahle-mail-archive-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kahle-mail-archive-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961031150346.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kahle-mail-archive-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kahle-mail-archive-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961031150346.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa28482; 4 Nov 96 9:46 EST
Received: from localhost by ietf.org id aa27759; 4 Nov 96 9:29 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ngtrans-routing-aspects-02.txt
Date: Mon, 04 Nov 1996 09:29:26 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611040929.aa27759 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Routing Aspects Of IPv6 Transition
Author(s) : R. Callon, D. Haskin
Filename : draft-ietf-ngtrans-routing-aspects-02.txt
Pages : 13
Date : 11/01/1997
This internet draft gives an overview of the routing aspects of the IPv6
transition. It is based on the protocols defined in the document
"Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be
familiar with the transition mechanisms before reading this document.
The proposals contained in this document are based on the work of the
Ngtrans working group.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ngtrans-routing-aspects-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ngtrans-routing-aspects-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ngtrans-routing-aspects-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961101150715.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ngtrans-routing-aspects-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ngtrans-routing-aspects-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961101150715.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa29935; 4 Nov 96 10:04 EST
Received: from fnal.fnal.gov by ietf.org id aa29823; 4 Nov 96 10:02 EST
Received: from gungnir.fnal.gov ("port 35003"@gungnir.fnal.gov)
by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IBFXS7QNGK003R2T at FNAL.FNAL.GOV> for
ietf at ietf.org; Mon, 04 Nov 1996 09:01:30 -0600
Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4)
id JAA22606; Mon, 04 Nov 1996 09:01:03 -0600
Date: Mon, 04 Nov 1996 09:01:03 -0600
Sender:ietf-request at ietf.org
From: Matt Crawford <crawdad at fnal.gov>
Subject: Re: The cartel begins to crumble?
In-reply-to: "01 Nov 1996 15:23:07 CST."
<"199611012123.PAA02754"@Mercury.mcs.net>
X-Orig-Sender: crawdad at gungnir.fnal.gov
To: ietf at ietf.org
Message-id: <199611041501.JAA22606 at gungnir.fnal.gov>
Content-transfer-encoding: 7BIT
X-Face:
/RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$! at A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Source-Info: From (or Sender) name not authenticated.
> > The second person who claims *ANY* TLD is the one to ignore.
This sounds like a fair rule to apply at any level of the hierarchy.
I'll apply it one level higher than Karl & company.
Received: from ietf.org by ietf.org id aa01690; 4 Nov 96 10:34 EST
Received: from BUTTHEAD.FSM.NET by ietf.org id aa01607; 4 Nov 96 10:32 EST
Received: from localhost by supernet.com.co (SMI-8.6/SMI-SVR4)
id KAA06676; Mon, 4 Nov 1996 10:27:12 +0500
Date: Mon, 4 Nov 1996 10:27:11 +0500 (GMT)
Sender:ietf-request at ietf.org
From: "Jesus Maria Arango - Ing. Comunicaciones FSM LTDA." <jarango at supernet.com.co>
X-Sender: jarango at butthead
To: Martin J Duerst <mduerst at ifi.unizh.ch>
cc: Gary Scott Malkin <gmalkin at xylogics.com>, jed at llnl.gov, ietf at ietf.org
Subject: Re: The cartel begins to crumble? - .com crowding
In-Reply-To: <"josef.ifi..396:04.10.96.11.43.20"@ifi.unizh.ch>
Message-ID: <Pine.SOL.3.93.961104102132.5051E-100000 at butthead>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
My personal experience with the .com TLD being crowded is that some
country domains are not well administered. For example, it takes quite
long to get (if you ever get one) a domain under .com.co for Colombia, So
I just rather apply to the registration services in the U.S. I think that
the Internic should be more careful when asigning country domains to
institutions who are not planning to make go use of it. I wish that the
colombian domain (.co) would be taken off from the actual holder, which
happens to be a burocratic university in Bogota.
*****************************************
* Jesus Arango *
* Ingeniero de Comunicaciones *
* Supernet - FSM LTDA. - Cablesistema *
* E-Mail: jarango at fsm.net *
* Internic POC Handle: JA406 *
* Tel: (574) 268-9000 *
* Fax: (574) 268-1281 *
****************************************
Received: from ietf.org by ietf.org id aa08106; 4 Nov 96 12:27 EST
Received: from doorstep.unety.net by ietf.org id aa08023; 4 Nov 96 12:25 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA10045; Mon, 4 Nov 1996 11:19:41 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCA42.526C4460 at webster.unety.net>; Mon, 4 Nov 1996 11:21:28 -0600
Message-ID: <01BBCA42.526C4460 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net.s0.g0>
To: Martin J Duerst <mduerst at ifi.unizh.ch>,
"'Valdis.Kletnieks at vt.edu'" <Valdis.Kletnieks at vt.edu>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: The cartel begins to crumble? - .com crowding
Date: Mon, 4 Nov 1996 11:21:26 -0600
Encoding: 25 TEXT
Source-Info: From (or Sender) name not authenticated.
On Monday, November 04, 1996 10:52 AM, Valdis.Kletnieks at vt.edu wrote:
@ On Mon, 04 Nov 1996 12:43:09 +0100, Martin J Duerst said:
@ > ibm.com. If we have .biz (which I assume stands for business),
@
@ A good point made in passing. Remember that not all the world is
@ English-speaking, and may not easily recognize that 'biz' is a phonetic
@ mangling of 'business'. At least COMmercial, NETwork, MILitary, and
@ EDUcational can be easily puzzled out....
@
@
Some people in Ukraine are working on new top level domains
for .KOM and .CET which evidently are equivalents to .COM and .NET.
More discussion on this appears on the newdom mailing list
from time to time <http://www.newdom.com/lists/>.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa11646; 4 Nov 96 13:43 EST
Received: from localhost by ietf.org id aa11417; 4 Nov 96 13:37 EST
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: ietf-rsvp at ietf.org
Subject: 37th IETF - List of Registered Attendees
Date: Mon, 04 Nov 1996 13:37:34 -0500
X-Orig-Sender: mbeaulie at ietf.org
Message-ID: <9611041337.aa11417 at ietf.org>
The following is a list of registered attendees as of Sunday,
November 3, 1996.
NOTE: Early Registration Cut-off is this Friday, November 8. If
you register ON or BEFORE November 8, your registration fee will
be $250.00, if you register AFTER November 8, your registration
fee will be $270.00.
1 Aboba, Bernard Microsoft Corporation
2 Adam, Daniel Microsoft Corporation
3 Adams, Robert Cisco Systems
4 Agbleze, Mawuse FTP Software, Inc.
5 Ahmed, Masuma Terayon Corporation
6 Ahuja, Ratinder Cisco Systems
7 Aibara, Reiji Hiroshima University
8 Alaettinoglu, Cengiz Information Sciences Institute
9 Alden, Roland
10 Alexander, Steve Silicon Graphics, Inc.
11 Allen, Edward Bay Networks, Inc.
12 Allen, Jeff Bunyip Information Systems
13 Allen, Terry Fujitsu Software Corp.
14 Allocchio, Claudio National Institute for Nuclear Physics, Italy
15 Almes, Guy Advanced Network and Services, Inc.
16 Alterman, Louise Lucent Technologies
17 Ambler, Christopher Image Online Design, Inc.
18 Amidon, Keith Hewlett-Packard
19 Andersson, Loa Eriksson
20 Angelopoulos, Spiros Sterling Software
21 Aprille, Thomas Lucent Technologies, Bell Laboratories
22 Arango, Jesus Supernet S.A.
23 Armstrong, Susie Qualcomm Inc.
24 Arneson, David Digital
25 Arunkumar, Nagaraj 3Com Corporation
26 Asano, Kazuo Fujitsu Laboratories Ltd.
27 Aspinwall, Russell Calyx UK Ltd.
28 Back, Nigel BT Laboratories
29 Bailey, Chase Cisco Systems
30 Bailey, Ed IBM Corporation
31 Baker, Fred cisco Systems
32 Bakker, Steven DANTE
33 Balenson, David Trusted Information Systems
34 Bannister, Joseph USC/ISI
35 Bantel, Richard Lucent Technologies
36 Barnes, Jim Bay Networks
37 Bathina, Raghu Trancell Systems, Inc.
38 Beaulieu, Marcia Corporation for National Research Initiatives
39 Bedell, J. Patrick
40 Bellovin, Steven AT&T Research
41 Berkhout, Vincent DANTE
42 Bernardi, Marco CSELT
43 Berson, Steven Information Sciences Institute
44 Beyer, Mark Netmanage, Inc.
45 Bhoajaraj, Sandya Hewlett-Packard
46 Bhogavilli, Suresh Information Sciences Institute
47 Bierman, Andy Cisco Systems, Inc.
48 Binder, Richard Corporation for National Research Initiatives
49 Blanchet, Marc Viagenie inc.
50 Blondel, P.F.C. S.A.R.A.
51 Blumenthal, Uri IBM Corporation
52 Borden, Marty Bay Networks, Inc.
53 Borinski, Stan Realogic, Inc.
54 Boroumand, Javad USC-ISI
55 Boroumand, Sepideh NASA GSFC/HSTX
56 Bos, Erik-Jan SURFnet bv
57 Boulianne, Luc McGill University
58 Bound, Jim Digital Equipment Corporation
59 Bowen, Rich NetEdge Systems, Inc.
60 Boyle, Jim The MITRE Corporation
61 Braden, Robert Information Sciences Institute
62 Bradescu, Roxana Sun Microsystems, Inc.
63 Breed, Charles Pretty Good Privacy, Inc.
64 Breslau, Lee Xerox PARC
65 Briceno, Marc DigiCash, Inc.
66 Bridgham, David Epilogue Technology Corporation
67 Brim, Scott Cornell University
68 Brockners, Frank University of Cologne - ZPR
69 Brody, Lawrence AT&T
70 Brown, Anne Nortel Technology
71 Brown Klinger, Sheila Lucent Technologies
72 Buchko, Steven Newbridge Networks Inc.
73 Burgan, Jeffrey Bay Networks, Inc.
74 Burle, Marlene Conferon, Incorporated
75 Bush, Randy NSRC
76 Cabeca, Linda Bay Networks, Inc.
77 Cai, Yiqun Northern Telecom
78 Cain, Patrick BBN Corporation
79 Cajano, Alessandro Telecom Italia
80 Calcari, Susan InterNIC/University of Wisconsin
81 Callaghan, Brent Sun Microsystems, Inc.
82 Callon, Ross Cascade Communications
83 Calvert, Kenneth Georgia Institute of Technology
84 Cansever, Derya GTE Laboratories, Inc.
85 Carlson, Richard Argonne National Laboratory
86 Carney, Michael Sun Microsystems, Inc.
87 Carpenter, Brian CERN
88 Carrel, David Cisco Systems
89 Carter, Stephen Novell, Inc.
90 Casner, Stephen Precept Software, Inc.
91 Caswell, Peter US Robotics
92 Chen, Yao-Min Fujitsu Laboratories of America
93 Cherenson, Andrew Liquid Audio, Inc.
94 Chiotasso, Chris BGS Systems, Inc.
95 Chiu, Alex Sun Microsystems
96 Chow, Jeff AMD
97 Christy, Greg Cisco Systems
98 Chu, H. K. Jerry SunSoft
99 Clark, Cynthia Corporation for National Research Initiatives
100 Clark, David Massachusetts Institute of Technology
101 Clauberg, Axel University of Cologne
102 Colella, Richard America Online
103 Comay, David Sun Microsystems, Inc.
104 Compton, Kip Continental Cablevision, Inc.
105 Cook, Gordon Cook Report on Internet
106 Copeland, Ken U.S. Dept. of Veterans Affairs
107 Corson, Scott University of Maryland
108 Coya, Stephen Corporation for National Research Initiatives
109 Craren, Michael 3COM
110 Crawford, Matt Fermilab
111 Crawley, Eric Bay Networks, Inc.
112 Crowe, David NERO Network
113 Curtin, Bill DISA
114 Daigle, Leslie Bunyip Information Systems
115 Dam, Tru Network Systems Corporation
116 Dang, Winston University of Hawaii
117 Daniel, Ron Los Alamos National Laboratory
118 Daoud, Edward Fujitsu
119 Davie, Bruce Cisco Systems
120 Dawkins, Spencer Nortel
121 De Winter, Jack Wildbear Consulting, Inc.
122 Delagi, Bruce Apple Computer, Inc.
123 Demirtjis, Ann Sprint
124 Demizu, Noritoshi Sony Computer Science Lab, Inc
125 Dittler, Hans Braintec Network Consulting
126 Doi, Yuusuke KEIO University
127 Donelan, Sean Data Research Associates, Inc.
128 Donner, Paul
129 Doraswamy, Naganand FTP Software, Inc.
130 Dosedal, Anke Cisco Systems
131 Droms, Ralph Bucknell University
132 Droz, Patrick IBM Research Laboratory
133 Duniho, Michael National Security Agency
134 Dunn, Jeffrey Hewlett-Packard
135 Dunstan, Adam Bay Networks, Inc.
136 Dupont, Francis INRIA Rocquencourt
137 Earhart, Rob Carnegie Mellon University
138 Eastlake, Donald CyberCash, Inc.
139 Eisler, Mike Sun Soft Inc.
140 Ellehauge, Peter Dansk Data Elektronik A/S
141 Ellerbee, Jeff ichat Inc.
142 Ellis, Gehrett Corporation for National Research Initiatives
143 Elz, Robert University of Melbourne
144 Emery, Nick AltaVista Internet Software
145 England, Kent Six Sigma Networks
146 Erickson, Rodger Wall Data
147 Erlinger, Michael The Aerospace Corporation
148 Estrin, Deborah Information Sciences Institute
149 Fair, Erik Apple Computer, Inc.
150 Fajman, Roger National Institutes of Health
151 Farinacci, Dino Cisco Systems, Inc.
152 Fasano, Paolo CSELT
153 Faynberg, Igor Lucent Technologies
154 Ferguson, Paul Cisco Systems
155 Fernandez, Antonio Bellcore
156 Ferracin, Joseph SITA/ITS
157 Fink, Robert Lawrence Berkeley Laboratory
158 Finkelstein, David Xcert Software Inc.
159 Flanigan, William Defense Information Systems Agency
160 Fleshman, Michael Clearview Systems, Inc.
161 Ford, Warwick
162 Forster, James Cisco Systems
163 Forsythe, Margaret Epilogue Technology Corp.
164 Fowler, Dave Newbridge Networks Inc.
165 Fox, Barbara Microsoft Corporation
166 Fox, Craig Cisco Systems
167 Fox, Daniel Bay Networks
168 Frankhauser, Martine SITA
169 Fuller, Vince BBN Corporation
170 Fumeno, Takanori Telecoment Inc.
171 Gadre, Jay Bell Atlantic
172 Galvin, James CommerceNet
173 Ganguly, Anik Campbell Services Inc.
174 Gilliam, William Hewlett-Packard
175 Gilmore, John Electronic Frontier Foundation
176 Girod, Lewis Massachusetts Institute of Technology
177 Glass, Steven FTP Software, Inc.
178 Glatting, Dennis CyberSafe Corporation
179 Goel, Vab Sprint
180 Goland, Yaron Microsoft
181 Gold, Harry NCCOSC
182 Goller, Sean Carnegie Mellon University
183 Gonzalez, Ricardo Hypertech Corporation
184 Goto, Yukinori Institute of Systems & Information Technology
185 Goyal, Mukul Sun Microsystems, Inc.
186 Gray, Eric
187 Greene, Barry Cisco Systems
188 Greene, Maria Ascom Nexion, Inc.
189 Grill, Thomas E-Systems
190 Gudmundsson, Olafur Trusted Information Systems
191 Gupta, Rajeev Trillium Digital Systems, Inc.
192 Gurajapu, Suresh Trancell Systems, Inc.
193 Haller, Neil Bellcore
194 Halpern, Joel Newbridge Networks Inc.
195 Halpin, James U.S. Robotics
196 Hambridge, Sally Intel Corporation
197 Hamilton, Martin Univeristy of Technology, Loughborough
198 Handelman, Sigmund IBM Corporation
199 Hanna, Donal Netskills
200 Harrison, Sari Apple Computer Inc.
201 Hasegawa, Yusaku Nara Institute of Science & Technology
202 Haskin, Dimitry Bay Networks, Inc.
203 Heard, C.M. VVNET, Inc.
204 Hedberg, Roland SUNET
205 Heffernan, Andy cisco Systems
206 Heidemann, John USC/ISI
207 Hernacki, Brian Netscape Communications, Inc.
208 Herron, Andrew Microsoft Corporation
209 Herzog, Shai IBM
210 Hien, Nguyen IBM Corporation
211 Hildenbrand, Bruce Sun Microsystems
212 Hilton, Rhonda Cable Television Laboratories
213 Hinden, Robert Ipsilon Networks, Inc.
214 Hirabaru, Masaki Merit Network, Inc.
215 Hirai, Chiaki Hitachi Ltd.
216 Hoffman, Paul Internet Mail Consortium
217 Holcomb, Jeff Apple Computer, Inc.
218 Holdrege, Matt Ascend Communications
219 Holmstead, Stephen Hewlett Packard
220 Hopkins, Gerry Bell Atlantic
221 Hopprich, John Cisco Systems
222 Hornby, Peter Unisys Corporation
223 Horneffer, Martin University of Cologne
224 Horowitz, Marc Cygnus Support
225 Hosein, Javed Bay Networks, Inc.
226 Huddle, Scott MCI Telecommunications Corporation
227 Hunt, Bill VPNE Technologies
228 Hur, Matt Cyber Safe Corporation
229 Huss, Claude Matsushita Electric Works US R&D Laboratories
230 Huston, Geoff Telstra
231 Ilgun, Koral Advanced Computer Communications
232 Inbar, Ofer The Left Bank Operation, Inc.
233 Inoue, Yoshinobu Fujitsu Laboratories Ltd.
234 Irlam, Gordon Cygnus Support
235 Ishiyama, Masahiro Toshiba Corporation
236 Iuso, Francesco Telecom Italia
237 Iversen, Ruben Dan Net
238 Iwata, Atsushi NEC Corporation
239 Jackowski, Steven NetManage, Inc.
240 Jacobs, Stuart GTE Laboratories
241 Jacobsen, Ole ConneXions
242 Jennings, Barbara Sandia National Laboratories
243 Jensen, Del Novell, Inc.
244 Jiang, Jonathan Bellcore
245 Jinzenji, Hiroshi NTT Human Interface Labs
246 Johnson, Jeff Cisco Systems
247 Johnson, Keith Federal Express Corporation
248 Johnson, Richard Cisco Systems
249 Johnson, Terry Develcon Electronics Ltd.
250 Jokubaitis, Vito AT&T
251 Jones, Ken Bay Networks, Inc.
252 Jork, Markus Digital Equipment GmbH
253 Joseph, Mark Attachmate Corporation
254 Kaat, Marijke SURFnet Expertise Center
255 Kalra, Sanjay Cisco Systems
256 Kapil, Vivek Nortel Technology
257 Kapur, Arun Quadritek Systems, Inc.
258 Kashima, Hiroaki Fujitsu Ltd.
259 Kastenholz, Frank FTP Software, Inc.
260 Kato, Akira The University of Tokyo Computer Center
261 Kaufman, Charlie Iris Associates
262 Kemp, David National Security Agency
263 Kennedy, John Novell Inc.
264 Kennedy, L. Sean BBN Corporation
265 Kent, Stephen BBN Corporation
266 Kern, Ed DIGEX
267 Keromytis, Angelos University of Pennsylvania
268 Kessens, David USC/ISI
269 Key, Kenneth Cisco Systems
270 Khalsa, Kirpal Lotus ccMail
271 Kim, Dorian CICNet, Inc.
272 Kim, Hyogon Bellcore
273 Kirchhoff, Julie Corporation for National Research Initiatives
274 Kirstein, Peter University College London
275 Kiyoshima, Naoki Ultra-high Speed Network & Computer Tech. Labs
276 Klensin, John MCI Telecommunications Corporation
277 Koch, Harald Secure Computing Canada Ltd.
278 Koester, Greg Bay Networks
279 Komiya, Masakatsu Japan Satellite Systems Inc.
280 Koskelainen, Petri Nokia Research Center
281 Krawczyk, John Bay Networks, Inc.
282 Krechmer, Ken Action Consulting
283 Kristol, David Lucent Technologies, Bell Laboratories
284 Krol, Edward University of Illinois Urbana
285 Krupczak, Cheryl Empire Technologies, Inc.
286 Kuang, Fidelia Apple Computer Inc.
287 Kuehne, Mirjam RIPE NCC
288 Kumar, Sanjay First Virtual Corporation
289 Kumar, Vinay ICAST Communications, Inc.
290 Kurakami, Hiroshi NTT Multimedia Networks Labs
291 Kurn, David Tandem Computers Inc.
292 Kuroda, Yasutsugu Fujutsu Laboratory Ltd.
293 Kwan, Stuart Microsoft Corporation
294 Kwan, William Jupiter Technology, Inc.
295 Lamond, Keith British Telecom North America
296 Lang, Ruth SRI International
297 Langlois, Sylvain Electricite de France
298 Lanphier, Rob Progressive Networks
299 Larsson, Jorgen Telia AB
300 Lasker, Valerie Precept Software, Inc.
301 LaVange, Don Novell, Inc.
302 Lavu, Lava George Mason University
303 Lawler, John VPNet Technologies, Inc.
304 Lear, Eliot Silicon Graphics, Inc.
305 Lee, WeeSan USC/ISI
306 Leech, Marcus Nortel Technology
307 Leinen, Simon SWITCH
308 Lemaire, Thomas 3Com Corporation
309 Lenggenhager, Thomas SWITCH
310 Lenharth, William University of New Hampshire
311 Leong, Ivan Pacific Internet Pte. Ltd.
312 Leroy, David FORE Systems
313 Leu, Brian Semaphore Communications Corp.
314 LeValley, Jim Macmillan Technical Publishing
315 Lewis, Edward Trusted Information System
316 Li, Hongqing Lucent Technologies
317 Li, Tony Juniper Networks Inc.
318 Li, Yan-Fa Hewlett-Packard
319 Liau, Wendy Oracle Corporation
320 Lichtensteiger, Reta Mitsubishi Electric ITA
321 Lim, Koon Sang Logic Group of Companies
322 Ling, Wenken Bay Networks, Inc.
323 Linn, John OpenVision Technologies
324 Liu, Eric Cable & Wireless
325 Liu, Yuan-Kwei NASA Ames Research Center
326 Lord, Anne UUNET PIPEX
327 Lu, Hui-Lan Lucent Technologies
328 Lu, Vivian NetEdge Systems, Inc.
329 Luciani, James Bay Networks, Inc.
330 Lundblade, Laurence Qualcomm Inc.
331 Macker, Joseph US Naval Research Laboratory
332 Mader, Keith Bay Networks, Inc.
333 Maeda, Kaori Hiroshima City University
334 Mahdavi, Jamshid Pittsburgh Supercomputing Center
335 Maher, Maryann USC/ISI
336 Malamud, Carl MIT Media Lab
337 Malis, Andrew Ascom Nexion, Inc.
338 Malkin, Gary Bay Networks
339 Mallory, Tracy 3Com Corporation
340 Mamros, Shawn FTP Software, Inc.
341 Mankin, Allison Information Sciences Institute
342 Mannie, Eric Brussels University
343 Manning, Bill Information Sciences Institute
344 Markham, Tom Secure Computing Corp.
345 Martillo, Joachim Telford Tools, Inc.
346 Martin, Antony DRA
347 Martin, Cynthia Defense Information Systems Agency
348 Martin, John TERENA
349 Masinter, Larry Xerox Corporation
350 Maston, Michael Cisco Systems
351 Mather, Tim Apple Computer
352 Mathis, Matt Pittsburgh Supercomputing Center
353 Matsuhira, Naoki Fujitsu Laboratories Ltd.
354 Matsune, Mio Network Information Service Co
355 Matsushita, Nobuo Bell Labs, Lucent Technologies
356 Maughan, Douglas National Security Agency
357 Maw, Tim Stentor Resource Centre Inc.
358 Maxham, Mark Apple Computer, Inc.
359 Mazzucato, Sandro Bunyip Information Systems
360 McBurnett, Neal Lucent Technologies, Bell Labs
361 McCloghrie, Keith cisco Systems
362 McCooey, Jeremy University of New Hampshire
363 McDonald, Daniel Sun Microsystems, Inc.
364 McGarvey, John IBM
365 McManis, Chuck Free Gate Corporation
366 McMillan, Tom 3Com Primary Access
367 McPherson, Danny MCI Telecommunications Corporation
368 Medrinsky, Ari Cyber Safe Corporation
369 Mende, Robert Silicon Graphics, Inc.
370 Merchant, Shashank Advanced Micro Devices
371 Meyer, David University of Oregon
372 Miller, Thomas Siemens
373 Miller, W. Marcus Lawrence Livermore National Labs
374 Mills, Cynthia GTE Laboratories, Inc.
375 Milnes, Brian Lycos, Inc.
376 Minami, Masaki Keio University
377 Minshall, Greg Ipsilon Networks, Inc.
378 Mistry, Danny Nortel Technology
379 Moats, Ryan AT&T Bell Laboratories InterNIC
380 Mogul, Jeffrey Digital Equipment Corporation
381 Mohta, Pushpendra CERFnet
382 Monsour, Robert Hi/fn, Inc.
383 Moore, Mike Hewlett-Packard
384 Moore, Robert IBM Corporation
385 Morris, David barili systems limited
386 Morris, Jonathan Manchester Metropolitan University
387 Morse Johnson, Kelly Cisco Systems
388 Mouradian, George AT&T Bell Laboratories
389 Moy, Diana U.S. Robotics
390 Moy, John Cascade Communications Corporation
391 Mundy, Russ Trusted Information Systems
392 Murai, Jun Keio University
393 Murphy, Sandra Trusted Information Systems
394 Murray, Cecil Campbell Services Inc.
395 Mutz, Andrew Hewlett-Packard
396 Myers, John Carnegie Mellon University
397 Myjak, Michael University of Central Florida
398 Nagami, Ken-ichi Toshiba Corporation
399 Nakamura, Osamu Keio University
400 Napjus, Erikas Carnegie Mellon University
401 Narayan, Vishy NASA Ames Research Center
402 Narayana, Raj Cable & Wireless
403 Narten, Thomas IBM Corporation
404 Nassi, Ike AppleSoft
405 Neer, Merle NRaD
406 Nemeth, Evi University of Colorado
407 Neuman, Clifford Information Sciences Institute
408 Newman, Chris Innosoft International, Inc.
409 Nguyen, Hai Raytheon E-Systems
410 Nicklass, Orly RAD Data Communications
411 Nicklow, Doug Lycos, Inc.
412 Nikander, Pekka
413 Noerenberg, John Qualcomm Inc.
414 Nowicki, William Silicon Graphics, Inc.
415 O'Leary, Peter Clear Blue Network Systems, Inc.
416 Obraczka, Katia USC/ISI
417 Oehler, Michael National Security Agency
418 Ohichi, Tsuyoshi Fujitsu Ltd.
419 Ohta, Masataka Tokyo Institute of Technology
420 Onishi, Steven Bay Networks, Inc.
421 Oran, David Cisco Systems
422 Ordille, Joann Bell Labs, Lucent Technologies
423 Ostrowski, Stephen 3Com
424 Ozaki, Satoshi Toshiba Corporation
425 Paez-Ramirez, Alonso BT Labs
426 Pang, Joseph Starlight Networks
427 Pareth, Sameer C2Net
428 Parker, Steve SunSoft, Inc.
429 Partan, Andrew WNA
430 Partington, Heath US Robotics Inc.
431 Patrick, Michael Motorola ISG
432 Perkins, Charles IBM Corporation
433 Perlman, Radia Novell, Inc.
434 Petke, Richard CompuServe, Inc.
435 Piper, Derrell Cisco Systems
436 Postel, Jon Information Sciences Institute
437 Presuhn, Randy BMC Software, Inc.
438 Pullen, J. Mark C3I Center
439 Rabin, Tal IBM
440 Rajagopalan, Bala Bellcore
441 Rajagopal, Murali Fujitsu
442 Ramanan, P.S. Sprint Corporation
443 Randall, Karen AT&T Universal Card Services Corporation
444 Rank, Edward Bay Networks
445 Ray, Cathe Sun Microsystems, Inc.
446 Reed, Benjamin IBM Corporation
447 Reeder, David Portland State University
448 Resnick, Pete Qualcomm Inc.
449 Rex, Martin SAP AG
450 Reynolds, Joyce K. Information Sciences Institute
451 Richard, Pat Xcert Software Inc.
452 Richardson, John Intel Corporation
453 Rogerson, Duncan University of London
454 Romanow, Allyn Sun Microsystems, Inc.
455 Roque Marques, Pedro Universidade de Lisboa
456 Rose, Marshall T. First Virtual Holdings Inc.
457 Rossen, Ken MCI Systemhouse
458 Routhier, Shawn Epilogue Technology Corporation
459 Royce, Kathy Bay Networks, Inc.
460 Ruth, Greg GTE Laboratories, Inc.
461 Rutkowski, Anthony General Magic, Inc.
462 Ryan, Gerard Bell Labs
463 Ryutov, Tatyana USC/ISI
464 Saito, Takeshi Toshiba Corporation
465 Sakamoto, Hiromitsu NEC Corporation
466 Salo, Timothy Minnesota Supercomputer Center
467 Samanick, John Defense Information Systems Agency
468 Saperia, Jon BGS Systems, Inc.
469 Sarkezians, Hasmik US Robotics
470 Sarmiento, Ramiro Sun Microsystems, Inc.
471 Sawyer, Wilson Bay Networks/LANcity
472 Scano, John 3Com
473 Schey, John Europay International
474 Schiller, Jeffrey Massachusetts Institute of Technology
475 Schmechel, Christopher Sun Microsystems, Inc.
476 Schneider, Mark National Security Agency
477 Schneider, Wolfgang GMD
478 Schnell, Steven Sprint Government Systems Division
479 Scott, Gregor Defense Information Systems Agency
480 Sedayao, Jeff Intel Corporation
481 Seto, Koichiro Hitachi Cable
482 Shand, Mike Digital Equipment Co. Ltd.
483 Shew, Stephen Nortel Technology
484 Shieh, Shuching Bay Networks, Inc.
485 Shimojo, Shinji Osaka University Computer Center
486 Shirey, Rob BBN Corporation
487 Shirley, Fred Sanders
488 Shmulevsky, Mark ADP, Inc.
489 Shobatake, Yasuro Toshiba Corporation
490 Siller, Curtis Lucent Technologies
491 Simpson, William Computer Systems Consulting Services
492 Sloane, Timon timonWare Inc.
493 Smith, Andrew NeoSoft, Inc.
494 Smith, Carl Sun Microsystems, Inc.
495 Smith, Michael TIAA-CREF
496 Smith, Philip UUNET PIPEX
497 Smith, Timothy IBM Corporation
498 Solensky, Frank FTP Software, Inc.
499 Sollins, Karen Massachusetts Institute of Technology
500 Solo, Dave BBN Corporation
501 Solomon, Jim Motorola
502 Spatscheck, Oliver University of Arizona
503 Speer, Michael Sun Microsystems, Inc.
504 Sridhar, T. Future Communications Software
505 Srinivasan, Suresh Thomson Technology Services Group
506 Srinivasan, Andre Oracle Corporation
507 St. Johns, Michael @Home Network
508 Staubach, Peter Sun Microsystems, Inc.
509 Steenstrup, Martha BBN Corporation
510 Stephens, Tom Microsoft Corporation
511 Stibler, Stephen IBM Corporation
512 Stockman, Bernhard Telia AB
513 Stuart, Wayne Cisco Systems
514 Sumikawa, Munechika Nara Institute of Science and Technology
515 Sumner, Mark Motorola
516 Suzuki, Muneyoshi NTT Multimedia Networks Labs
517 Swallow, George Cisco Systems
518 Swink, Michael Sprint
519 Takamatsu, Satoshi NTT
520 Takihiro, Masatoshi Hitachi Ltd.
521 Tallerico, David The MITRE Corporation
522 Talpade, Rajesh Georgia Institute of Technology
523 Tanaka, Kei Internet Initiative Japan Inc.
524 Tang, Cheng Hewlett-Packard
525 Taniguchi, Kunihiro NECUSA
526 Taylor, Peter Mailbase, Newcastle University
527 Tecot, Ed Apple Computer, Inc.
528 Teplitsky, Jacob Fore Systems
529 Teraoka, Fumio Sony Computer Science Laboratory, Inc.
530 Terpstra, Marten Bay Networks, Inc.
531 Tesink, Kaj Bellcore
532 Thatcher, Michael Thatcher Consulting Services
533 Thayer, Rodney Sable Technology Corporation
534 Thomas, Matt Digital Equipment Corporation
535 Thomas, Richard Nortel Technology
536 Thomson, Susan Bellcore
537 Tomimura, Eiji Sumitome Electric USA, Inc.
538 Tominaga, Akihiro Keio University
539 Topolcic, Claudio BBN Corporation
540 Touch, Joseph USC/ISI
541 Tow, Agnes AT&T
542 Tracy, Michael Sunsoft
543 Tramposch, Albert World Intellectual Property Organization
544 Travis, Ward Cisco Systems
545 Trest, Mike ATMNET
546 Trostle, Jonathan CyberSafe Corporation
547 Ts'o, Theodore Massachusetts Institute of Technology
548 Tsuchiya, Kazuaki Hitachi, Ltd.
549 Tung, Brian Information Sciences Institute
550 Turaj, Nancy The MITRE Corporation
551 Turner, Randy Sharp Laboratories of America
552 Uehara, Keisuke KEIO University
553 Umeda, Masayoshi Nippon Telegraph and Telephone Corporation
554 Vaudreuil, Gregory Octel Network Services
555 Veach, Ross CICNet, Inc.
556 Veenstra, Jack AT&T
557 Verina, Maria ICGEB
558 Verrilli, Colin IBM Corporation
559 Villanueva, Deric WRQ
560 Vohra, Quaizar University of New Hampshire
561 von Kaenel, Juerg IBM
562 Vozza, Vincenzo Telecom Italia
563 Vu, Anh Fore Systems
564 Vu, Joseph Fore Systems
565 Wada, Hiromi Matsushita Electric Industrial Company, Ltd.
566 Wahl, Mark Critical Angle, Inc.
567 Wall, Matt Carnegie Mellon University
568 Wallace, Dick Concord Communications, Inc.
569 Watanabe, Ken Hitachi, Ltd.
570 Watt, James Newbridge Networks Inc.
571 Weaver, Elfed Defense Research Agency
572 Webber, Bob PictureTel Corporation
573 Weiler, Samuel Carnegie Mellon University
574 Weiss, Howard SPARTA, Inc.
575 Wellens, Chris InterWorking Labs, Inc.
576 Wells, Amy Tracy InterNIC Net Scout
577 West, Jim Ciena Optical Communications
578 Whipple, Mark Octel Services
579 White, Gerry LANcity Corporation
580 White, Paul University College London
581 Williams, Carl Sun Microsystems, Inc.
582 Windrim, Mark Newstar Technologies
583 Winter, Brian US Robotics Inc.
584 Won, King Network General Corp.
585 Woodcock, Bill Zocalo Engineering
586 Wright, Graham Hummingbird Communications
587 Wright, Russ Lawrence Berkeley Laboratory
588 Wroclawski, John Massachusetts Institute of Technology
589 Yamamoto, Kazuhiko Nara Institute of Science Technology
590 Yao, Kwang Hewlett-Packard
591 Yarnell, Jeff Kaspia Systems, Inc.
592 Yavatkar, Raj Intel Corporation
593 Yen, Leemay 3Com Corporation
594 Ylonen, Tatu SSH Communications Security
595 Yu, I-Hsiang GTE Laboratories Inc.
596 Zhang, Lixia UCLA
597 Zhang, Zhaohui Bay Networks, Inc.
598 Ziegast, Eric GTE Interactive Media
599 Ziemba, Paul Fore Systems
600 Zorn, Glen Microsoft Corporation
Received: from ietf.org by ietf.org id aa14011; 4 Nov 96 14:20 EST
Received: from proxy1.ba.best.com by ietf.org id aa13922; 4 Nov 96 14:18 EST
Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.7.6/8.7.3) with ESMTP id LAA08649 for <ietf at ietf.org>; Mon, 4 Nov 1996 11:12:32 -0800 (PST)
Received: from bill.scli.com ([206.79.9.179]) by shellx.best.com (8.6.12/8.6.5) with SMTP id LAA27866 for <ietf at ietf.org>; Mon, 4 Nov 1996 11:11:37 -0800
Received: by bill.scli.com with Microsoft Mail
id <01BBCA59.C85F27C0 at bill.scli.com>; Mon, 4 Nov 1996 14:09:24 -0800
Message-ID: <01BBCA59.C85F27C0 at bill.scli.com>
Sender:ietf-request at ietf.org
From: Bill Hunt <bill at vpnet.com>
To: "ietf at ietf.org" <ietf at ietf.org>
Subject: Cartel Nonsense
Date: Mon, 4 Nov 1996 14:09:23 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
I do hope this discussion eventually gets back to something
remotely relevent, but I'm afraid I won't be here to find out as I am
unsubscribing in another letter.
I suspect the original subject had a deeper meaning than intended,
as fed-up members such as myself drop off the list.
Bill Hunt
bill at vpnet.com
----------
From:Masataka Ohta[SMTP:mohta at necom830.hpcl.titech.ac.jp]
Sent:Saturday, November 02, 1996 10:11 AM
To:dorian at cic.net
Cc:mohta at necom830.hpcl.titech.ac.jp; ietf at ietf.org
Subject:Re: English is it -> was: Re: The cartel begins to crumble?
dorian;
> While tentativeness because of unfamiliar language is part of the reason,
> differences across cultures of the mode and tone of formal exchange is one of
> possible reason why some people might feel less inclined to step up to the mic
> at meetings.
>
> -dorian, a non-native speaker of English or American.
dakara, chanto youroppa jintono chigaimo nobete arudeshouga.
nihongo no bubun yondekara forou site hosiin desukedo?
anata nihon no nyuusu guruupu deno ronchou, mitakoto arimasu?
Masataka Ohta
Received: from ietf.org by ietf.org id aa19594; 4 Nov 96 16:34 EST
Received: from cnri by ietf.org id aa19268; 4 Nov 96 16:27 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22218;
4 Nov 96 16:27 EST
Received: from ruebert.ieee.org by venera.isi.edu (5.65c/5.61+local-25)
id <AA10198>; Mon, 4 Nov 1996 13:26:11 -0800
Received: (from daemon at localhost) by ruebert.ieee.org (8.7.5/8.7.3) id QAA03288; Mon, 4 Nov 1996 16:28:35 -0500 (EST)
Date: Mon, 4 Nov 1996 16:28:35 -0500 (EST)
Message-Id: <199611042128.QAA03288 at ruebert.ieee.org>
To: ietf at isi.edu
Sender:ietf-request at ietf.org
From: majordomo at majordomo.ieee.org
Subject: Welcome to comsoc-conferences
Reply-To: majordomo at majordomo.ieee.org
Precedence: bulk
Organization: IEEE Service Center, Piscataway, NJ
Source-Info: From (or Sender) name not authenticated.
--
Welcome to the comsoc-conferences mailing-list!
If you ever want to remove yourself from this mailing list,
send the following command in email to
"majordomo at majordomo.ieee.org" with the following command
in the body of your email message:
unsubscribe comsoc-conferences ietf at isi.edu
Here's the general information for the list you've
subscribed to, in case you don't already have it:
#### No info available for comsoc-conferences.
Received: from ietf.org by ietf.org id aa20437; 4 Nov 96 16:54 EST
Received: from callandor.cybercash.com by ietf.org id aa20425;
4 Nov 96 16:53 EST
Received: by callandor.cybercash.com; id QAA11872; Mon, 4 Nov 1996 16:48:10 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma011853; Mon, 4 Nov 96 16:47:53 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA23674; Mon, 4 Nov 96 16:50:32 EST
Date: Mon, 4 Nov 1996 16:50:31 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: majordomo at majordomo.ieee.org
Cc: ietf at ietf.org
Subject: Welcome to comsoc-conferences (fwd)
Message-Id: <Pine.SUN.3.91.961104164146.22876D-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
unsubscribe comsoc-conferences ietf at isi.edu
end
I'm on the IETF mailing list to read IETF discussions and get IETF
announcements. People who want to get IEEE or ACM or ... meeting
announcements should subscribe to those lists themselves. I don't know who
tried to subscribe the ietf list to the ieee announcement service but it was
wrong.
There are many computer and networking conferences, meetings, call for
papers, etc., every day. If they were all announced on the IETF list, the
list would be essentially useless. Unsolicited email is not the way to
advertise on the Internet. There are plenty of web pages, appropriate
newsgroups, and narrow mailing lists. By being on the IETF list I am
soliciting IETF meeting annoucements, not IEEE or other organziations
annoucnements.
Donald
=====================================================================
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee at cybercash.com
318 Acton Street +1 508-371-7148(fax) dee at world.std.com
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com http://www.eff.org/blueribbon.html
---------- Forwarded message ----------
Date: Mon, 4 Nov 1996 16:28:35 -0500 (EST)
From: majordomo at majordomo.ieee.org
To: ietf at isi.edu
Subject: Welcome to comsoc-conferences
--
Welcome to the comsoc-conferences mailing-list!
If you ever want to remove yourself from this mailing list,
send the following command in email to
"majordomo at majordomo.ieee.org" with the following command
in the body of your email message:
unsubscribe comsoc-conferences ietf at isi.edu
Here's the general information for the list you've
subscribed to, in case you don't already have it:
#### No info available for comsoc-conferences.
Received: from ietf.org by ietf.org id aa22628; 4 Nov 96 17:54 EST
Received: from apollo.it.hq.nasa.gov by ietf.org id aa22565; 4 Nov 96 17:53 EST
Received: from wirehead.it.hq.nasa.gov (WireHead.it.hq.nasa.gov [131.182.119.88]) by apollo.it.hq.nasa.gov (8.6.12/8.6.12) with ESMTP id WAA20797; Mon, 4 Nov 1996 22:52:17 GMT
Received: from localhost (cshenton at localhost) by wirehead.it.hq.nasa.gov (8.6.12/8.6.12) with SMTP id WAA14884; Mon, 4 Nov 1996 22:51:41 GMT
Message-Id: <199611042251.WAA14884 at wirehead.it.hq.nasa.gov>
X-Authentication-Warning: wirehead.it.hq.nasa.gov: cshenton owned process doing -bs
X-Authentication-Warning: wirehead.it.hq.nasa.gov: Host localhost didn't use HELO protocol
To: majordomo at majordomo.ieee.org
Cc: ietf at ietf.org
Subject: Re: Welcome to comsoc-conferences (fwd)
In-Reply-To: Your message of "Mon, 4 Nov 1996 16:51:05 -0500 (EST)"
References: <199611042151.QAA10185 at ruebert.ieee.org>
X-Mailer: Mew version 1.03 on Emacs 19.31.8
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Mon, 04 Nov 1996 17:51:41 -0500
Sender:ietf-request at ietf.org
From: Chris Shenton <cshenton at it.hq.nasa.gov>
Source-Info: From (or Sender) name not authenticated.
unsubscribe comsoc-conferences ietf-announce at cnri.reston.va.us
end
They subscribed ietf-announce
Looks like they subscribed a bunch of other lists too... :-(
Members of list 'comsoc-conferences':
c.dessoye
0002912712 at mcimail.com
100010.3371 at compuserve.com
100045.3451 at compuserve.com
100046.3710 at compuserve.com
100125.3213 at compuserve.com
100130.3723 at compuserve.com
100141.536 at compuserve.com
100141.676 at compuserve.com
100144.3104 at compuserve.com
100263.17 at compuserve.com
100277.152 at compuserve.com
100304.2136 at compuserve.com
100327.2041 at compuserve.com
100331.1340 at compuserve.com
100333.1654 at compuserve.com
100335.347 at compuserve.com
100336.2470 at compuserve.com
100342.1167 at compuserve.com
100432 at compuserve.com
100436.230 at compuserve.com
100437.1126 at compuserve.com
100440.3230 at compuserve.com
100543.175 at compuserve.com
100543.662 at compuserve.com
100550.1756 at compuserve.com
100572.1156 at compuserve.com
100601.2536 at compuserve.com
100606.3360 at compuserve.com
100633.2467 at compuserve.com
100735.3315 at compuserve.com
100765.3267 at compuserve.com
160317.273 at compuserve.com
2416755 at mcimail.com
3 at AM.ITU.CH
4312323 at mcimail.com
4395849 at mcimail.com
519-5060 at mcimail.com
6053253 at mcimail.com
6110721 at mcimail.com
638.1781 at mcimail.com
638171 at mcimail.com
6621920 at mcimail.com
70624.557 at compuserve.com
70670.3674 at compuserve.com
71154.2522 at compuserve.com
71221.621 at compuserve.com
7124754 at mcimail.com
71650.1046 at compuserve.com
72662.1562 at compuserve.com
72662.5050 at compuserve.com
73064.71 at compuserve.com
73252.1364 at compuserve.com
735-2328 at mcimail.com
73521.2256 at compuserve.com
7409947 at mcimail.com
74431.515 at compuserve.com
74431.610 at compuserve.com
74431.744 at compuserve.com
74431.751 at compuserve.com
74551.1064 at compuserve.com
74667.1275 at compuserve.com
74777.2215 at compuserve.com
74777.3561 at compuserve.com
75006.3504 at compuserve.com
75162.2575 at compuserve.com
75372.34642 at compuserve.com
75410.2346 at compuserve.com
a.pelaez at ieee.org
msalerno at lynxtech.com
msemilof at cmp.com
mss at gummo.doc.ic.ac.uk
mthyfaul at cmp.com
mtw at dial-switch.ch
mukasa at ast.lab.kdd.co.jp
a.hirsch at magnet.at
multicomm at cc.bellcore.com
f.wickenburg at magnet.at
abpg4 at singnet.com.sg
fad at prism.uvsq.fr
acray at mcgraw-hill.com
adoughe at Gateway.Uswnvg.COM
murase at nwk.cl.nec.co.jp
Faouzi.Daoud at prism.uvsq.fr
fdida at masi.ibp.fr
mustafa at ece.concordia.ca
filali at irit.fr
nab01531 at niftyserve.or.jp
flegal at pobox.oleane.com
nadism at mbunix.mitre.org
naets at ebu.ch
neteurop at dial.pipex.com
fly at juicer.magna.com.au
fmarain at innet.be
aevagora at cmp.com
netmgt at ncri.com
fogarty at eurescom.d400.de
forte at informatik.uni-kl.de
fourneau at masi.ibp.fr
fujikawa at nikkeibp.co.jp
networks at cw.telecom.at
newaves at aoi.com
fulvio.faraci at MacPost.cselt.stet.it
g-troup at dworkin.wustl.edu
news.announce.conferences
g.weisman at ieee.org
nhe at postman.dg13.cec.be
niau at systems.co.za
afad at alain.demon.co.uk
gabriela.wuerth at aut.alcatel.at
niitsu at krsun.nslab.ntt.jp
nkc at bellcore.com
nmf-members at nmf.org
gaddisgm at mcgraw-hill.com
ag112120 at dircon.co.uk
ahmadi at engn.uwindsor.ca
ahmed at ece.concordia.ca
aidarous at bnr.ca
nmsig at nemo.ncsl.nist.gov
noiseworks at attmail.com
gae at alfalinea.innet.it.ptc.org
gaha at prodigy.com
gca at economist.com
aitec at geo2.poptel.org.uk
akabanovsky at pyr.com
gcomlist1 at manjaro.ece.iit.edu
akikaz at ascii.co.jp
geradsd at agcs.com
akses at tfi.be
noms96 at joker.bellcore.com
Germind at Mgn.com
nsm-info at gateway.mitre.org
aledo at micronet.it
alexander.higgins at ITU.CH
alg at comm.toronto.edu
am79 at dial.pipex.com
nzzspi at dm.rs.ch
oliveira at eurecom.fr
anderse at dsu.su.se.ptc.org
announcements.chi at Xerox.com
opd at dial.eunet.ch
osimcast at bbn.com
aow-nmsig at stc.ipa.go.jp
OSIMIS at cs.ucl.ac.uk
giga at tele.pitt.edu
gk at datanews.be
globecom at signet.com.sg
godsdog at digmedia.com
arby at pi.se
goran.frojdh at aftonbladet.se
gordon at elronet.co.il
aref at alhayatdemon.co.uk.ptc.org
gotz at cc.bellcore.com
arl at arl.wustl.edu
OVForum at andrew.cmu.edu
oyamada at krsun.nslab.ntt.jp
grand at hntpz.hinet.net.ptc.org
panflet at cix.compulink.co.uk
gsissa at inet.it
arpanet-bboard at mc.lcs.mit.edu
guthery at austin.sar.slb.com
atm-list at csc.com
Guy.Pujolle at prism.uvsq.fr
atm at bbn.com
audrey at yankee.co.uk
aurore.lester-smith at infoboard.be
guyd at computing.emap.co.uk
auscom at 02email.com.au.ptc.org
guyd at post.emap.co.uk
avibliz at eltonet.co.il.ptc.org
G_F_Wetzel at cbgw1.att.com
badri at cs.rutgers.edu
Paolooberto at cselt.stet.it
hansjoerg.schmid at alcatel.ch
banafss at mcgraw-hill.com
harneks at isd.toi.ernet.in
baranyi at mtesz.hu
barrere at irit.fr
bashore at ix.netcom.com
hdreifus at aol.com
hegering at lrz-muenchen.de
batnir at agcs.com
heikki.nenonen at aamulehti.mailnet.fi
paulcov at bnr.ca
heinz at pct.de
paulmcc at mcs.com
hhodara at snap.org
pbrown at cmp.com
bborda at phillips.com
hikaru at kopenews.nslab.ntt.jp
pclarke at ifields.demon.co.uk.ptc.org
hipparch at sophia.inria.fr
bcs-hci-request at mailbase.ac.uk
hlu at arch4.att.com
benzekri at irit.fr
pcollier at gotha.vtcom.fr
per.roijer at sds.se
hori at nikkeibp.co.jp
horlait at masi.ibp.fr
perform at tay1.dec.com
hrt at telmo.fi
Bernier1 at aol.com
petero at pi.net
besier at eurescom.d400.de
betourne at irit.fr
peter_hankin at rhk.com
huggard at irish-computer.ie
bgelpke at access.ch
bhumip at gte.com
ian at icompub.demon.co.uk
pf at hightech.presse.co.at
icad-request at santafe.edu
phill at intercom.com.au
ie-list at cs.ucl.ac.uk
pla at ccmail.idg.dk
bich at cc.bellcore.com
ieee.announce at bellcore.com
ieeetcpc at ccvm.sunysb.edu
ieee_rtc_list at cs.tamu.edu
ietf-announce at cnri.reston.va.us
billinghurst at wireworks.ptc.org
bjr at d-comm.com
plateau at imag.imag.fr
BM-List1 at cs.ucdavis.edu
ietf-madman at innosoft.com
bobchap at ibm.net
pne at dial.pipex.com
pogran at bbn.com
ifip-emailmgt at ics.uci.edu
poseyma at mcgraw-hill.com
bolles at radiomail.net
bottomac at mcgraw-hill.com
ifip-nm at bbn.com
prabhu at ee.uta.edu
pradeep at dstc.uts.edu.au
igorf at arch4.att.com
bran at silcom.com
prs at masi.ibp.fr
iimc at thumper.bellcore.com
brants at evert.com
ikbsbb at inf.rl.ac.uk
prs at uvsq.fr
braudyb at aol.com
ilka at prz.tu-berlin.de
brg at hebdo.ch
ptravis at cmp.com
inet.kfho271 at niftyserve.or.jp
iplpdn at cnri.reston.va.us
pxk12334 at niftyserve.or.jp
pyramid at pyr.com
ipmb0024 at mx.ivnet.com.tw
brunosv at cpqd.br
bryan at yankee.co.uk
bumblis at mcc.com
bur_goode at vnet.ibm.com
byte.me at applelink.apple.com
iroberts at cmp.com
c.desmond at ieee.org
isadsoc at fokus.gmd.de
isinm97_oc at ctr.columbia.edu
quevenco at adp01.iaea.or.at.ptc.org
c.dessoye at ieee.org
cabukv at informa.mk
caillng at mobitel.telia.se
isogai at softbank.co.jp
candewilde at aol.com
quevenco at adp01.iaea.or.at
it at jp.dk
radio74 at iprolink.ch
cara.cunningham at idg.com
itc at fokus.gmd.de
j.cheong at trl.oz.au
radio at sovam.com
j.n.slater at herts.ac.uk
rafiq at crisv2.univ-pau.fr
carera at jec.it.ptc.org
jali at worldaccess.nl
ralph at city.ac.uk
Carl. at eleceng.ucl.ac.uk
rappaport at sbee.sunysb.edu
jandre at imtn.tpd.dsccc.com
castanet at labri.u-bordeaux.fr
jard at irisa.fr
raymonmj at mcgraw-hill.com
javan at comm.toronto.edu
cboeke at phillips.com
jbraue at mcgraw-hill.com
raynal at irisa.fr
raynaud at irit.fr
cbonafield at nwc.com
jcoons at dataquest.com
ccrc at dworkin.wustl.edu
rcas at cris.com
cellular at comnets.rwth-aachen.de
rcotro at micronet.it
jeffc at wrn.org
rdantu at tddcae99.fnts.com
jeremiah_caron at wcmh.com
cellular at dfv.rwth-aachen.de
reda at iprolink.ch
jerry at ece.concordia.ca
rem-cof-request at es.net
chapel at scmp.com
chee-eng at mcgraw-hill.com
chigir-i at ascii.co.jp
rem-conf at es.net
reres at comm.polymtl.ca
jezequel at irisa.fr
reres at laas.fr
reres at uklirb.informatik.uni-kl.de
chipweek at vogel.anet.cz
jgallont at cid.infosel.com.mx
revesz at idg.hu
jim_kent at rhk.com
rfumi at technet.it.ptc.org
jjohnson at mcgraw-hill.com
richard.wilson at rbp.co.uk
chris-finn at telechoice.com
jkeator at npr.org
richard at alex.ptc.org
richard at ptc.org
chris at yankee.co.uk
jlevenberg at mcimail.com
chrish at media.emap.co.uk
rlfike at aol.com
rlouw at wn.apc.org
christos at ece.miami.edu
jmoberg at telepost.no
jne at glasgow-caledonian.ac.uk
chuanyi at ecse.rpi.edu
roberto.kung at issy.cnet.fr
cip at bnn.com
roberto.saracco at cselt.stet.it
joel_jakubson at rhk.com
cjs1 at psp.att.com
johan.hjelm at baf.bonnier.se
claireg at romtec.co.uk
robert_s at idg.se
clytle at sed.stel.com
john.francis at ITU.CH
cnom at maestro.bellcore.com
johnston at auntie.bbcnc.org.uk
rob_garretson at idg.com
jonas at fti.se
commsoft at cc.bellcore.com
rocks at earn.cvut.cz
comp.arch.storage
comp.client-server
jorgen at mogul.no
comp.graphics.research
comp.graphics.visualization
comp.graphics
comp.lang.visual
rogerdean at attmail.com
comp.mail.multi-media
josh at ccnet.com
comp.multimedia
jouni.roksa at tbx.telebox.fl.ptc.org
comp.org.acm
Ron.Horn.0090874 at nt.com
jphang at hk.super.net
rpreston at cmp.com
js at hightech.presse.co.at
comp.org.ieee
comp.org.usenix
jsaganger at nn.apc.org
comp.os.research
jsavage at ix.netcom.com
jschenke at cmp.com
rune.Wikstol at s.hk.telenor.ptc.org
comp.parallel
juanole at laas.fr
just4net at aol.com
samar.shamoon at ITU.CH
jweil at cris.com
comp.protocols.iso at bellcore.com
jwhite at acp.com.au
saracco at cselt.stet.it
sb.all at ieee.org
karen at icompub.demon.co.uk
sbw at ccrl.nj.nec.com
karlm at wrn.org
comp.realtime
scott_linke at aus.hp.com
seb at cc.bellcore.com
kdd at gte.com
comptime at singnet.com.sg
ke at voa.gov
shchori at ccsg.tak.ac.il.ptc.org
sheppard at elsevier.co.uk
shomer at cix.compulink.co.uk
keith at yankee.co.uk
kevin at brs95787.demon.co.uk
comsoc-chapters at ieee.org
khart at cmp.com
comsoc-gicb at ieee.org
comsoc.bog at tab.ieee.org
kjl at cc.bellcore.com
comswtc at gmu.edu
klaus.baumer at telekom.dbp.de
sidou at eurecom.fr
corpcom at osf.org
sig-dsm at doc.imperial.ac.uk
cost237-transport at comp.lancs.ac.uk
klynch at cmp.com
sig11 at roses.stanford.edu
courtiat at laas.fr
sigmedia at bellcore.com
kmiller at businessweek.com
simon at blah.com
knecht at mvuss.att.com
cousin at irisa.fr
simon at cui.unige.ch
craig at bbn.com
simon at vsat.demon.co.uk
kseo at bbn.com
crblackman at cityscape.co.uk
sjefred at orapp.no
kusaura at krsun.nslab.ntt.jp
smarty at hol.gr
labetoul at eurecom.fr
smds at cnri.reston.va.us
ctc-members at redbank.tinac.com
lanworks at delphi.com
larryg at arch4.att.com
cybsys-l at bingvmb.cc.binghamton.edu
smithma at mcgraw-hill.com
larsendg at mcgraw-hill.com
laura.cerchio at cselt.stet.it
d.frazier at cablelabs.com
danny-briere at telechoice.com
snmp at psi.com
david at icompub.demon.co.uk
snmsigl at nemo.ncsl.nist.gov
sofia at idg.se
DCrosby at VTRLMEL1.TRL.OZ.AU
sound at acm.org
lawendel at micronet.it
declank at cartermill.com
ssaunders at mcgraw-hill.com
dgreenfield at mcgraw-hill.com
staples at bnr.ca
lbmoniz at telepac.pt
Received: from ietf.org by ietf.org id aa24277; 4 Nov 96 18:32 EST
Received: from cnri by ietf.org id aa24186; 4 Nov 96 18:30 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25472;
4 Nov 96 18:30 EST
Received: from ruebert.ieee.org by venera.isi.edu (5.65c/5.61+local-25)
id <AA17561>; Mon, 4 Nov 1996 15:29:05 -0800
Received: (from daemon at localhost) by ruebert.ieee.org (8.7.5/8.7.3) id SAA26693; Mon, 4 Nov 1996 18:31:29 -0500 (EST)
Date: Mon, 4 Nov 1996 18:31:29 -0500 (EST)
Message-Id: <199611042331.SAA26693 at ruebert.ieee.org>
To: ietf at isi.edu
Sender:ietf-request at ietf.org
From: majordomo at majordomo.ieee.org
Subject: Majordomo results
Reply-To: majordomo at majordomo.ieee.org
Precedence: bulk
Organization: IEEE Service Center, Piscataway, NJ
Source-Info: From (or Sender) name not authenticated.
--
>>>> unsubscribe comsoc-conferences ietf at isi.edu
**** unsubscribe: 'ietf at isi.edu' is not a member of list 'comsoc-conferences'.
Received: from ietf.org by ietf.org id aa28407; 4 Nov 96 21:59 EST
Received: from cnri by ietf.org id aa28270; 4 Nov 96 21:51 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa28904;
4 Nov 96 21:51 EST
Received: from dworkin.wustl.edu by venera.isi.edu (5.65c/5.61+local-25)
id <AA26464>; Mon, 4 Nov 1996 18:50:41 -0800
Received: (from milind at localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA05570; Mon, 4 Nov 1996 20:48:59 -0600
Date: Mon, 4 Nov 1996 20:48:59 -0600
Sender:ietf-request at ietf.org
From: "Milind M. Buddhikot" <milind at dworkin.wustl.edu>
Message-Id: <199611050248.UAA05570 at dworkin.wustl.edu>
To: BM-List1 at cs.ucdavis.edu, giga at tele.pitt.edu, announcements.chi at xerox.com,
arl at arl.wustl.edu, atm at bbn.com, ccrc at dworkin.wustl.edu, cgs at mit.edu,
cip at bbn.com, commsoft at cc.bellcore.com, comsoc-gicb at ieee.org,
end2end-interest at isi.edu, ftroup at aurora.cis.upenn.edu,
g-troup at dworkin.wustl.edu, hipparch at sophia.inria.fr,
icad-request at santafe.edu, ietf at isi.edu, iplpdn at CNRI.Reston.VA.US,
ir-l%uccvma.bitnet at cunyvm.cuny.edu, isadsoc at fokus.gmd.de,
enternet at bbn.com, klaus at informatik.rwth.aachen.de, prs at masi.ibp.fr,
rem-conf-request at es.net, reres at laas.fr,
s-comput%tcsvm.BITNET at wugate.wustl.edu, sig11 at roses.stanford.edu,
sigmedia at bellcore.com, simon at cui.unige.ch, sip-request at catarina.usc.edu,
smds at CNRI.Reston.VA.US, sound at acm.org, tccc at cs.umass.edu, tcplw at bsdi.com,
tf-mm at i4serv.informatik.rwth.aachen.de, uist.chi at xerox.com,
wittig at vnet.ibm.com, osimcast at bbn.com, ieeetcpc at ccvm.sunysb.edu,
comsoc.tac at tab.ieee.org
Subject: CFP for NOSSDAV97
Source-Info: From (or Sender) name not authenticated.
Hi:
Enclosed please find a Call-for-Papers (CFP) for the 7th International
Workshop on Network and Operating Systems Support for Digital Audio
and Video to be held in St. Louis, Missouri (USA) from May 19-21,
1997.
Please feel free to circulate the CFP by any means you deem
appropriate. Also, please excuse any multiple copies of this CFP you
may receive due to your memberships in multiple mailing lists.
Thanks and regards.
Milind
*****************************************************************************
* *
* NOSSDAV'97 *
* *
* Call-for-Papers *
* *
* *
* The 7th International Workshop on Network and Operating System *
* Support for Digital Audio and Video (NOSSDAV 97) *
* *
* URL: http://www.arl.wustl.edu/NOSSDAV97/nossdav.html *
* *
* May 19 - 21 1997 *
* *
* Hosted by: *
* The Applied Research Laboratory *
* Department of Computer Science *
* Washington University in St. Louis, Missouri *
* *
* Sponsored by IEEE Communications Society *
* In cooperation with ACM SIGCOMM and SIGMM *
******************************************************************************
Objectives
The 7th International Workshop on Network and Operating Systems
Support for Digital Audio and Video (NOSSDAV 97) is the international
workshop concerned with state of the art technology in networking and
operating system support for multimedia systems. For seven years,
NOSSDAV has proven to be an outstanding forum for researchers involved
in building innovative multimedia systems, networks and applications
on both the research and industrial front. Other topics that will be
examined include "middleware" for multimedia, media toolkits, mobile
communications, Virtual Reality (VR), real-time systems, software
agents, digital libraries, and other digital media besides audio and
video.
A key aspect of the workshop is that it provides extensive discussion
periods during which attendees can informally discuss their current
work and future research directions. Traditionally, NOSSDAV has
emphasized on high quality experimental research that prototypes
systems to explore innovative solutions to the problems in the diverse
areas of multimedia computing. NOSSDAV97 will continue this tradition.
Relevant topics for the workshop include:
* APIs and Continuous Media (CM) programming abstractions for
multimedia
* Cell-based system architectures
* Communication protocols for multimedia
* Distributed multimedia systems
* End-to-end admission control
* High-speed/ATM networks
* Micro-kernel and OS support for real-time communications
* Mobile multimedia systems
* Multicast protocols and media scaling
* Multimedia network interfaces
* Multimedia-oriented desk, local and wide area networks
* Multimedia and the Internet
* Multimedia storage, server, and I/O architectures
* Quality of service and synchronization frameworks
* Resource management and reservation in the OS and network
* Software agents for multimedia systems
* TV set-top device communication
* VOD system architecture
* VR systems
* Workstation and PDA architectures for multimedia
Submissions
Two types of submissions are solicited: position papers and research
papers. For the purpose of paper review, position papers are
restricted to three single-spaced pages. Research papers are
restricted to an extended abstract no longer than five formatted
postscript pages. To complete your submission, please send the
following items by electronic mail to NOSSDAV97 at arl.wustl.edu
(1) The research or position paper in POSTSCRIPT form.
(2) The title of the paper, a list of authors with complete contact
information in the form of email address and phone number, and an
abstract summarizing the paper in PLAIN TEXT.
Only if electronic submission is impossible, papers may be sent to the
following mailing address.
Dr. Gurudatta M. Parulkar
ATTN: NOSSDAV 97
Washington University
Department of Computer Science
Applied Research Laboratory
Campus Box 1045
St. Louis, Missouri 63130
USA
The paper abstracts will be circulated among the NOSSDAV97 program
committee members to solicit reviewers.
Please note that the proceedings of the workshop will be published as
a book by Springer-Verlag and the best papers will be forwarded to
selected journals for publication.
Important Dates
Submission Deadline: 15 January 1997 (A FIRM DEADLINE)
Acceptance Notification: 15 March 1997
Final Paper Due: 15 April 1997 (A FIRM DEADLINE)
Workshop: 19 - 21 May 1997
Program Chair
Dr. Gurudatta M. Parulkar
Director, Applied Research Lab
Department of Computer Science
Washington University, St. Louis MO. USA
guru at arl.wustl.edu, TEL: (314) 935-7534
Local Arrangements Chair
John D. DeHart
Senior Research Associate, Applied Research Lab
Department of Computer Science
Washington University, St. Louis MO. USA
jdd at arl.wustl.edu, TEL: (314) 935-7534
Other Correspondance:
NOSSDAV97 at arl.wustl.edu TEL: (314) 935-7534
Program Committee
Andrew T. Campbell, Columbia University
Domenico Ferrari, Universita` Cattolica, Italy
Kevin Jeffay, Univ of North Carolina
Mike Jones, Microsoft, Inc.
Chuck Kalmanek, AT&T Research
S. Keshav, Cornell University
Jim Kurose, University of Masachusetts
Monica Lam, Stanford University
Ian Leslie, Cambridge University, UK
Tom Little, Boston University
Derek McAuley, University of Glasgow, UK
Steve McCanne, Univ of California, Berkeley
A. Desai Narasimhalu, National University of Singapore
Gerald Neufeld, Univ of British Columbia, Canada
Duane Northcutt, Sun Microsystems
Joe Pasquale, Univ of California, San Diego
Bernhard Plattner, ETH, Zurich
Steve Pink, SICS, Sweden
P Venkat Rangan, Univ of California, San Diego
KK Ramakrishnan, AT&T Research
Henning Schulzrinne, Columbia University
Brian Smith, Cornell University
Doug Shepherd, University of Lancaster, UK
Ralf Steinmetz, University of Darmstadt, Germany
James Sterbenz, GTE
Dan Swinehart, Xerox PARC
Harrick Vin, Univ of Texas, Austin
Raj Yavatkar, Intel
Radu Popescue-Zeletin, GMD FOKUS, Germany
Hui Zhang, CMU
Publicity Chair
Milind M. Buddhikot
Graduate Research Assistant
Department of Computer Science
Washington University, St. Louis MO, USA
milind at dworkin.wustl.edu TELE (314) 935 4302
Publications Chair
Vykky A. Klingenberg
Technical Assistant, Applied Research Laboratory
Department of Computer Science
Washington University, St. Louis MO, USA
vykky at arl.wustl.edu TELE (314) 935 7534
LOCATION
As is traditional, the workshop will take place at an elite resort,
away from the hustle and bustle of daily life. Innsbrook Estates
Executive Conference Center is located on 3,200 acres of the most
gorgeous rolling Missouri woodland, dotted by crystal clear lakes.
For accommodations, there are 1, 2, and 3-bedroom condominiums which
are fully equipped with living and dining areas, fireplaces, cable
television and kitchens to offer conferees all the comforts of home in
a lakeside or wooded hideaway. You want to relax after a day of
lectures? There is an eighteen hole golf-course, a junior-olympic
swimming pool, lighted tennis courts, mini-fitness center with a sauna
and hot tub, softball, volleyball, horseback riding, miniature golf
course, fishing, lake swimming, canoeing, and sailing, just to name a
few of the amenities. A relaxing excursion to a scenic location away
from the conference site is also being planned.
Received: from ietf.org by ietf.org id aa11823; 5 Nov 96 6:29 EST
Received: from cnri by ietf.org id aa11458; 5 Nov 96 6:18 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa06828; 5 Nov 96 6:18 EST
Received: from MAILBOX.ADM.RL.AF.MIL by venera.isi.edu (5.65c/5.61+local-25)
id <AA10544>; Tue, 5 Nov 1996 03:17:28 -0800
Received: from shaggy (SHAGGY.C3D.RL.AF.MIL [128.132.39.57]) by mailbox.adm.rl.af.mil (8.7.6/8.7.6) with SMTP id GAA11875 for <ietf at isi.edu>; Tue, 5 Nov 1996 06:18:43 -0500 (EST)
Message-Id: <MAPI.Id.0016.00686574202020203330453730303036 at MAPI.to.RFC822>
Read-Receipt-To: Chester "J." Maciag <chet at shaggy.c3d.rl.af.mil>
Priority: Normal
To: ietf at isi.edu
Reply-To: maciagc at rl.af.mil
Mime-Version: 1.0
Sender:ietf-request at ietf.org
From: "Chester J. Maciag" <chet at rl.af.mil>
Date: Tue, 05 Nov 96 07:20:50 EST
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe comsoc-conferences ietf at isi.edu
-----------------------------------------------------------------------
Chester J. Maciag
Network Security Engineer
Rome Laboratory Communication Networks Branch
525 Brooks Rd, Rome NY 13441
(315) 330-1875 DSN 587-1875
FAX: (315) 330-8012 or (315) 330-7137
Received: from ietf.org by ietf.org id aa13294; 5 Nov 96 7:56 EST
Received: from mail.cno.com.br by ietf.org id aa13099; 5 Nov 96 7:53 EST
Received: by mail.cno.com.br (AIX 3.2/UCB 5.64/4.03)
id AA18006; Tue, 5 Nov 1996 10:52:18 -0400
Received: from unknown(10.1.0.25) by mail.cno.com.br via smap (V1.3)
id sma019027; Tue Nov 5 10:52:00 1996
Received: from canario.dpabr.cno.com.br by dsbr01.dpabr.cno.com.br (AIX 3.2/UCB 5.64/4.03)
id AA42029; Tue, 5 Nov 1996 09:52:05 -0400
Message-Id: <MAPI.Id.0016.00616e6172696f203631333830303044 at MAPI.to.RFC822>
In-Reply-To: <"josef.ifi..123:04.10.96.09.01.51"@ifi.unizh.ch>
References: Conversation <199611012236.OAA09605 at servo.qualcomm.com> with last message <"josef.ifi..123:04.10.96.09.01.51"@ifi.unizh.ch>
Priority: Normal
To: ietf at ietf.org
Mime-Version: 1.0
Sender:ietf-request at ietf.org
From: Luiz Sergio Canario <canario at cno.com.br>
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
Date: Tue, 05 Nov 96 10:54:44 EST
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Phil Karn wrote:
>The IETF is an English-speaking, US-centric organization because
the
>Internet originated in the US.
Definitely not so for "English-speaking"! English is the major language
in business, in science, in diplomacy, and so on. The Internet is no
exception at all.
Regards,Martin.
As a no English-speaking and not an American at all, I am feeling
excluded of all the discussion around Iternet. May be we, no
english-speaking and no Americans, should found another mail-list to
discuss our point of views about Internet.
Or maybe we should, each one of us, use our native language.
Sory for my english, but unfortunely I am not an English-speaking nor
an American.
Luiz Sergio Canario
Received: from ietf.org by ietf.org id aa14486; 5 Nov 96 8:23 EST
Received: from ns.aic.net by ietf.org id aa13926; 5 Nov 96 8:20 EST
Received: by aic.net (8.7.3/8.7.3) id QAA10529; Tue, 5 Nov 1996 16:14:44 +0300 (GMT)
Message-Id: <199611051314.QAA10529 at aic.net>
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: Luiz Sergio Canario <canario at cno.com.br>
Date: Tue, 5 Nov 1996 16:14:43 +0300 (GMT)
Cc: ietf at ietf.org
In-Reply-To: <MAPI.Id.0016.00616e6172696f203631333830303044 at MAPI.to.RFC822> from "Luiz Sergio Canario" at Nov 5, 96 10:54:44 am
Sender:ietf-request at ietf.org
From: edd at acm.org
Reply-To: edd at amnic.net
Organization: AM Network Information Center @ AIC Network Operations
X-Tel: +37 42 28 14 25
X-FAX: +37 42 28 50 82
X-InterNIC-ID: ET22
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> As a no English-speaking and not an American at all, I am feeling
> excluded of all the discussion around Iternet. May be we, no
> english-speaking and no Americans, should found another mail-list to
> discuss our point of views about Internet.
> Or maybe we should, each one of us, use our native language.
Well, I can't agree. Internet and 99% of associated "things"
originated in the US. In fact, 90% of the Internet is in the U.S.A.
These facts are enough - the official language of the Internet
IS the English language. This is fact.
> Sory for my english, but unfortunely I am not an English-speaking nor
> an American.
Nor I am American nor English is my native language. Even my alphabet isn't
latin. But it doesn't matter. The point here is to understand that the
English is the language of the Internet and associated WG's. Of course
we (you and me) are free to use our mother tongues where it IS appropriate...
After all, English is relatively easy to learn language (compared to others)...
Just my 2c,
-edd
--
Edgar der Danieliantz, edd at acm.org
AM Hostmaster / Armenia NIC
Received: from ietf.org by ietf.org id aa17315; 5 Nov 96 9:32 EST
Received: from luggage.tecc.co.uk by ietf.org id aa16973; 5 Nov 96 9:28 EST
Received: from auntie.bbcnc.org.uk by luggage.tecc.co.uk id aa16234;
5 Nov 96 14:24 GMT
To: ietf at ietf.org
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
In-reply-to: Your message of "Tue, 05 Nov 1996 10:54:44 EST."
<MAPI.Id.0016.00616e6172696f203631333830303044 at MAPI.to.RFC822>
Date: Tue, 05 Nov 1996 14:24:35 +0000
Sender:ietf-request at ietf.org
From: Gordon Joly <gordo at tecc.co.uk>
Message-ID: <9611051424.aa16234 at luggage.tecc.co.uk>
Source-Info: From (or Sender) name not authenticated.
According to today's Guardian, published in the UK (London and
Manchester 96/11/05, G2, page 2, "Brain Storms" by Victor Keegan);
"Information overload is an English disease, or rather a disease in
English. Sixty percent of all radio broadcasts, 70 per cent of
addressed mail and 85 per cent of all international telephone calls
(and 80 per cent of data transfers) are in English"
I would assume that all figures are global rather than local to
Europe.
Gordon Joly.
--
Gordon.Joly at bbc.co.uk http://www.bbc.co.uk/ +44 181 752 5454
BBC Multimedia Centre, G374, 201 Wood Lane, LONDON W12 7TS
Received: from ietf.org by ietf.org id aa18216; 5 Nov 96 9:43 EST
Received: from sibyl.intellinet.com by ietf.org id aa17907; 5 Nov 96 9:41 EST
Received: from intellinet.intellinet.com (mars.intellinet.com [204.182.227.16]) by intellinet.com (8.6.12/8.6.9) with SMTP id IAA12569; Tue, 5 Nov 1996 08:40:59 -0600
Message-Id: <2.2.32.19961105134359.0073caa8 at pop.intellinet.com>
X-Sender: ads at pop.intellinet.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 05 Nov 1996 08:43:59 -0500
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Amoja Sumler <ads at intellinet.com>
Subject: Re: Welcome to comsoc-conferences (fwd)
Cc: majordomo at majordomo.ieee.org
Source-Info: From (or Sender) name not authenticated.
unsubscribe comsoc-conferences ietf-announce at cnri.reston.va.us
end
Amoja Danekal Sumler TCP/IP Consultant (Internet Overlord) Intellinet
___ _ _ _ _ _ ____ _
|_ _|_ __ | |_ ___| | (_)_ __ ___| |_ | _ \ _ _| | ___ ___
| || '_ \| __/ _ \ | | | '_ \ / _ \ __| | |_) | | | | |/ _ \/ __|
| || | | | || __/ | | | | | | __/ |_ | _ <| |_| | | __/\__ \
|___|_| |_|\__\___|_|_|_|_| |_|\___|\__| |_| \_\\__,_|_|\___||___/
http://www.intellinet.com/~ads/ Member of P.O.E. SUPPORT THE SHAPINGS!!
Received: from ietf.org by ietf.org id aa19501; 5 Nov 96 9:48 EST
Received: from dragonfly.cisco.com by ietf.org id aa19212; 5 Nov 96 9:47 EST
Received: from groeck-pc.cisco.com (groeck-pc.cisco.com [171.69.28.33]) by dragonfly.cisco.com (8.6.12/8.6.5) with SMTP id GAA07228; Tue, 5 Nov 1996 06:46:09 -0800
Message-Id: <2.2.32.19961105144734.008b35a0 at dragonfly.cisco.com>
X-Sender: groeck at dragonfly.cisco.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 05 Nov 1996 06:47:34 -0800
To: Gordon Joly <gordo at tecc.co.uk>
Sender:ietf-request at ietf.org
From: Guenter Roeck <groeck at cisco.com>
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
Would it eventually be possible to stop this
mail thread, or at least move to another list ?
Thanks,
Guenter
At 02:24 PM 11/5/96 +0000, Gordon Joly wrote:
>
>According to today's Guardian, published in the UK (London and
>Manchester 96/11/05, G2, page 2, "Brain Storms" by Victor Keegan);
>
>"Information overload is an English disease, or rather a disease in
>English. Sixty percent of all radio broadcasts, 70 per cent of
>addressed mail and 85 per cent of all international telephone calls
>(and 80 per cent of data transfers) are in English"
>
>I would assume that all figures are global rather than local to
>Europe.
>
>Gordon Joly.
>
>--
>Gordon.Joly at bbc.co.uk http://www.bbc.co.uk/ +44 181 752 5454
>BBC Multimedia Centre, G374, 201 Wood Lane, LONDON W12 7TS
>
>
Received: from ietf.org by ietf.org id aa20075; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa19504; 5 Nov 96 9:48 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mboned at ns.uoregon.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mboned-admin-ip-space-00.txt
Date: Tue, 05 Nov 1996 09:48:25 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050948.aa19504 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MBONE Deployment Working
Group of the IETF.
Title : Administratively Scoped IP Multicast
Author(s) : D. Meyer
Filename : draft-ietf-mboned-admin-ip-space-00.txt
Pages : 2
Date : 11/04/1996
This document defines the "administratively scoped IP multicast space"
to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes
a simple set of semantics for the implementation of Administratively
Scoped IP Multicast.
This memo is a product of the MBONE Deployment Working Group (MBONED) in
the Operational Requirements area of the Internet Engineering Task Force.
Submit comments to <mboned at ns.uoregon.edu> or the author.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mboned-admin-ip-space-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mboned-admin-ip-space-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104143933.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mboned-admin-ip-space-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mboned-admin-ip-space-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104143933.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19968; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa19155; 5 Nov 96 9:47 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-freed-charset-reg-01.txt
Date: Tue, 05 Nov 1996 09:47:13 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050947.aa19155 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IANA Character Set Registration Procedures
Author(s) : N. Freed, J. Postel
Filename : draft-freed-charset-reg-01.txt
Pages : 10
Date : 11/04/1996
MIME [RFC MIME-IMB, RFC MIME-IMT, RFC MIME-HEADERS] and various other
modern Internet protocols are capable of using many different character
sets. This in turn means that the ability to label different character sets
is essential. This registration procedure exists solely to associate a
specific name or names with a given character set and to give an indication
of whether or not a given character set can be used in MIME text objects.
In particular, the general applicability and appropriateness of a given
registered character set is a protocol issue, not a registration issue, and
is not dealt with by this registration procedure.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-freed-charset-reg-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-freed-charset-reg-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-freed-charset-reg-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104143146.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-freed-charset-reg-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-freed-charset-reg-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104143146.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19797; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa17813; 5 Nov 96 9:40 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mhtml-spec-05.txt
Date: Tue, 05 Nov 1996 09:40:30 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050940.aa17813 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME Encapsulation of
Aggregate HTML Documents Working Group of the IETF.
Title : MIME E-mail Encapsulation of Aggregate Documents, such
as HTML (MHTML)
Author(s) : J. Palme, A. Hopman
Filename : draft-ietf-mhtml-spec-05.txt
Pages : 15
Date : 11/04/1996
Although HTML [RFC 1866] was designed within the context of MIME, more than
the specification of HTML as defined in RFC 1866 is needed for two
electronic mail user agents to be able to interoperate using HTML as a
document format. These issues include the naming of objects that are
normally referred to by URIs, and the means of aggregating objects that go
together. This document describes a set of guidelines that will allow
conforming mail user agents to be able to send, deliver and display these
objects, such as HTML objects, that can contain links represented by URIs.
In order to be able to handle inter-linked objects, the document uses the
MIME type multipart/related and specifies the MIME content-headers
"Content-Location" and "Content-Base".
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mhtml-spec-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-spec-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-spec-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104110143.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-spec-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-spec-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104110143.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19819; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa17972; 5 Nov 96 9:42 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ion at nexen.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ion-transition-00.txt
Date: Tue, 05 Nov 1996 09:42:16 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050942.aa17972 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internetworking Over NBMA
Working Group of the IETF.
Title : Classical IP to NHRP Transition
Author(s) : J. Luciani
Filename : draft-ietf-ion-transition-00.txt
Pages : 5
Date : 11/04/1996
This document describes methods and procedures for the graceful transition
from an ATMARP LIS[1] to an NHRP LIS[2] network model over ATM.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ion-transition-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ion-transition-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ion-transition-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104112348.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ion-transition-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ion-transition-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104112348.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19838; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa17780; 5 Nov 96 9:40 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-zigmond-media-url-00.txt
Date: Tue, 05 Nov 1996 09:40:25 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050940.aa17780 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Uniform Resource Locators for Television and Telephony
Author(s) : D. Zigmond
Filename : draft-zigmond-media-url-00.txt
Pages : 3
Date : 11/04/1996
World-Wide Web browsers are starting to appear on a variety of consumer
electronic devices, such as televisions and both cellular and wireline
telephones. On these devices, some of the URL schemes described in [1] are
inappropriate. For example, many of these devices lack local storage, so
the "file" scheme is of little use. However, these devices usually have
access to other sources of information, such as television broadcasts and
voice telephone services. This draft proposes three new URL schemes for
accessing such information on appropriate devices.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-zigmond-media-url-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-zigmond-media-url-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-zigmond-media-url-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104104400.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-zigmond-media-url-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-zigmond-media-url-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104104400.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19821; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa17796; 5 Nov 96 9:40 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-mhtml-info-05.txt
Date: Tue, 05 Nov 1996 09:40:27 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050940.aa17796 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the MIME Encapsulation of
Aggregate HTML Documents Working Group of the IETF.
Title : Sending HTML in E-mail, an informational supplement to
RFC ???: MIME E-mail Encapsulation of Aggregate HTML
Documents (MHTML)
Author(s) : J. Palme
Filename : draft-ietf-mhtml-info-05.txt
Pages : 11
Date : 11/04/1996
The memo "MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)"
(draft-ietf-mhtml-spec-05.txt) specifies how to send packaged aggregate
HTML objects in MIME e-mail. This memo is an accompanying informational
document, intended to be an aid to developers. This document is not an
Internet standard.
Issues discussed are implementation methods, caching strategies, problems
with rewriting of URIs, making messages suitable both for mailers which can
and which cannot handle Multipart/related and handling recipients which do
not have full Internet connectivity.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mhtml-info-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-info-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-info-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104105833.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-info-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-info-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104105833.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19802; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa18607; 5 Nov 96 9:45 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-dawson-csp-00.txt
Date: Tue, 05 Nov 1996 09:45:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050945.aa18607 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME Calendaring and Scheduling Content Type Profile
Author(s) : F. Dawson
Filename : draft-dawson-csp-00.txt
Pages : 61
Date : 11/04/1996
The use of mail enabled applications such as calendaring and scheduling has
grown considerably in the last decade. Enterprise and inter-enterprise
business has become dependent on rapid scheduling of events and actions
using this information technology. The store-and-forward characteristic of
electronic messaging technologies has been shown to be complementary to the
asynchronous nature of group communications. However, the longer term
growth of mail enabled applications, such as calendaring and scheduling, is
currently limited by the lack of Internet standards for the message content
types that these groupware applications are based on. This specification is
intended to progress the level of interoperability possible between
dissimilar calendaring and scheduling applications that communicate using
an SMTP or MIME transport.
This specification defines a usage profile for the MIME Calendaring and
Scheduling Content Type [MIME-CAL]. Any MIME based calendaring and
scheduling application that supports this MIME Calendaring
and Scheduling Content Type profile will be able to interoperate with
other MIME based calendaring and scheduling applications using
a broad range of scheduling functions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-dawson-csp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dawson-csp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-dawson-csp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104115138.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dawson-csp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dawson-csp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104115138.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19993; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa19186; 5 Nov 96 9:47 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-madman-nsm-mib-03.txt
Date: Tue, 05 Nov 1996 09:47:19 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050947.aa19186 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory
Management Working Group of the IETF.
Title : Network Services Monitoring MIB
Author(s) : N. Freed
Filename : draft-ietf-madman-nsm-mib-03.txt
Pages : 22
Date : 11/04/1996
A networked application is a realization of some well defined service on
one or more host computers that is accessible via some network, uses some
network for its internal operations, or both.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-madman-nsm-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-madman-nsm-mib-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-madman-nsm-mib-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104143440.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-madman-nsm-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-nsm-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104143440.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20092; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa19599; 5 Nov 96 9:48 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-harrington-ngtrans-v4comp-00.txt
Date: Tue, 05 Nov 1996 09:48:48 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050948.aa19599 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Limiting the role of IPv4-compatible Addresses in IPv6
Author(s) : D. Harrington
Filename : draft-harrington-ngtrans-v4comp-00.txt
Pages : 7
Date : 11/04/1996
This draft presents a proposal to limit IPv4-compatible IPv6 addresses to
tunnelling interfaces in the transition from IPv4 to IPv6. The reasons and
context for restricting the usage in this manner will be presented.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-harrington-ngtrans-v4comp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-harrington-ngtrans-v4comp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-harrington-ngtrans-v4comp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104161257.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-harrington-ngtrans-v4comp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-harrington-ngtrans-v4comp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104161257.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19841; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa18589; 5 Nov 96 9:45 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-dawson-csct-00.txt
Date: Tue, 05 Nov 1996 09:45:09 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050945.aa18589 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME Calendaring and Scheduling Content Type
Author(s) : F. Dawson
Filename : draft-dawson-csct-00.txt
Pages : 68
Date : 11/04/1996
There is a clear need to provide and deploy interoperable calendaring and
scheduling services for the Internet. Current group scheduling and Personal
Information Management (PIM) products are being extended for use across the
Internet, today, in proprietary ways. This document has been defined to
provide the a definition of a MIME message format for openly exchanging
calendaring and scheduling information across the Internet.
This memo is meant to serve as the basis for registration of such a
MIME media type per [RFC1521]. The proposed media type value is
"TEXT/CALENDAR". This string would label a media type containing
calendaring and scheduling information encoded as text characters
formatted in a manner outlined below.
This MIME media type provides a standard content type for
capturing calendar event and todo information. It also can be used to
convey free/busy time information. The content type is suitable as a MIME
message entity that can be transferred over MIME based email systems or
using HTTP. In addition, the content type is useful as an object for
interactions between desktop applications using the operating system
clipboard, drag/drop or file systems capabilities.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-dawson-csct-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-dawson-csct-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-dawson-csct-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104114347.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-dawson-csct-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-dawson-csct-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104114347.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19782; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa17737; 5 Nov 96 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: int-serv at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-intserv-guaranteed-mib-01.txt
Date: Tue, 05 Nov 1996 09:38:58 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050938.aa17737 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services Working
Group of the IETF.
Title : Integrated Services Management Information Base
Guaranteed Service Extensions
Author(s) : F. Baker
Filename : draft-ietf-intserv-guaranteed-mib-01.txt
Pages : 14
Date : 11/04/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the the interface attributes
defined in the Guaranteed Service of the Integrated Services Model.
Comments should be made to the Integrated Services Working Group,
int-serv at isi.edu.
This memo does not, in its draft form, specify a standard for the
Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-intserv-guaranteed-mib-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-guaranteed-mib-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104103014.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-guaranteed-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-guaranteed-mib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104103014.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19791; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa17948; 5 Nov 96 9:42 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipsec at tis.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipsec-esp-3des-md5-00.txt
Date: Tue, 05 Nov 1996 09:42:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050942.aa17948 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Security Protocol Working
Group of the IETF.
Title : Combined 3DES-CBC, HMAC and Replay Prevention Security
Transform
Author(s) : N. Doraswamy
Filename : draft-ietf-ipsec-esp-3des-md5-00.txt
Pages : 13
Date : 11/04/1996
This draft describes a combination of privacy, authentication, integrity
and replay prevention into a single packet format.
This document is the result of significant work by several major
contributors and the IPsec working group as a whole. These contributors,
cited later in this document, provided many of the key technical details
summarized in this document. [IB93] [IBK93]
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipsec-esp-3des-md5-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104110923.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipsec-esp-3des-md5-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104110923.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19814; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa18002; 5 Nov 96 9:42 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-abela-ulm-00.txt
Date: Tue, 05 Nov 1996 09:42:21 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050942.aa18002 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Universal Format for Logger Messages
Author(s) : J. Abela
Filename : draft-abela-ulm-00.txt
Pages : 7
Date : 11/04/1996
This document presents a format to describe system events for logging
purpose. Some of the features presented here are in use with the common
syslog facility, but most of them are lost in the crowd of syslog format
freedom.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-abela-ulm-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-abela-ulm-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-abela-ulm-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104113231.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-abela-ulm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-abela-ulm-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104113231.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19785; 5 Nov 96 9:51 EST
Received: from localhost by ietf.org id aa18634; 5 Nov 96 9:45 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnsind-2ndry-04.txt
Date: Tue, 05 Nov 1996 09:45:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050945.aa18634 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Selection and Operation of Secondary DNS Servers
Author(s) : R. Elz, R. Bush, S. Bradner, M. Patton
Filename : draft-ietf-dnsind-2ndry-04.txt
Pages : 12
Date : 11/04/1996
The Domain Name System requires that multiple servers exist for every
delegated domain (zone). This document discusses the selection of
secondary servers for DNS zones. Both the physical and topological
location of each server are material considerations when selecting
secondary servers. The number of servers appropriate for a zone is also
discussed, and some general secondary server maintenance issues considered.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-2ndry-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-2ndry-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-2ndry-04.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104134302.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-2ndry-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-2ndry-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104134302.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21150; 5 Nov 96 9:54 EST
Received: from localhost by ietf.org id aa17713; 5 Nov 96 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-mib-03.txt
Date: Tue, 05 Nov 1996 09:38:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050938.aa17713 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : RSVP Management Information Base
Author(s) : F. Baker, J. Krawczyk
Filename : draft-ietf-rsvp-mib-03.txt
Pages : 73
Date : 11/04/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the Resource Reservation
Protocol (RSVP) within the interface attributes defined in the Integrated
Services Model. Thus, the Integrated Services MIB is directly relevant to
and cross-referenced by this MIB. Comments should be made to the RSVP
Working Group, rsvp at isi.edu.
This memo does not, in its draft form, specify a standard for the
Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-mib-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-mib-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104102505.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104102505.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21234; 5 Nov 96 9:54 EST
Received: from server.txport.com by ietf.org id aa20711; 5 Nov 96 9:53 EST
Received: from j_oyarbide.txport.com by txport.com (4.1/SMI-4.1)
id AA04407; Tue, 5 Nov 96 08:52:39 CST
Received: by j_oyarbide.txport.com with Microsoft Mail
id <01BBCAFF.17345F00 at j_oyarbide.txport.com>; Tue, 5 Nov 1996 09:52:43 -0500
Message-Id: <01BBCAFF.17345F00 at j_oyarbide.txport.com>
Sender:ietf-request at ietf.org
From: Jorge Alejandro Oyarbide <joyarbide at txport.com>
To: Luiz Sergio Canario <canario at cno.com.br>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: NON SENSE. English is the best language for this....
Date: Tue, 5 Nov 1996 09:52:42 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
I disagree completly with those that don`t want English as the language =
for discussing these issues... I`m not an american in fact I come from =
El Salvador ( now Canadian ),and I consider that English is the best =
language for discussion. Is impossible to make global discussions in all =
the different languages that exist in the world; there allways be some =
body saying I speak Chinese or Japanese or Spanish, or else an of course =
it will be better for them to doit in their language but how far can =
that go.... and what about the others that don`t speak those languages.
Is common sense... what you want, a 1000 different discussion groups =
and a huge central office translating what ever they concluded ?. Please =
don't be ridiculous. Please land and be realistic and stop this Non =
Sense.
English is international an most countries speak it. That is not the =
case for the other langauges. If it was then this topic could have some =
sense.
Ps.. this is my personal opinion an not my company`s...
:) Bye...
----------
De :edd at acm.org[SMTP:edd at acm.org]
Date d'envoi=A0:mardi 5 novembre 1996 11:14
A=A0:Luiz Sergio Canario
Cc=A0:ietf at ietf.org
Objet=A0:Re: English is it -> was: Re: The cartel begins to crumble?
> As a no English-speaking and not an American at all, I am feeling=20
> excluded of all the discussion around Iternet. May be we, no=20
> english-speaking and no Americans, should found another mail-list to=20
> discuss our point of views about Internet.=20
> Or maybe we should, each one of us, use our native language.
Well, I can't agree. Internet and 99% of associated "things"
originated in the US. In fact, 90% of the Internet is in the U.S.A.
These facts are enough - the official language of the Internet=20
IS the English language. This is fact.
> Sory for my english, but unfortunely I am not an English-speaking nor=20
> an American.
Nor I am American nor English is my native language. Even my alphabet =
isn't
latin. But it doesn't matter. The point here is to understand that the
English is the language of the Internet and associated WG's. Of course
we (you and me) are free to use our mother tongues where it IS =
appropriate...
After all, English is relatively easy to learn language (compared to =
others)...
Just my 2c,
-edd
--
Edgar der Danieliantz, edd at acm.org
AM Hostmaster / Armenia NIC
Received: from ietf.org by ietf.org id aa21854; 5 Nov 96 9:59 EST
Received: from localhost by ietf.org id aa17725; 5 Nov 96 9:38 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: int-serv at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-intserv-mib-03.txt
Date: Tue, 05 Nov 1996 09:38:54 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050938.aa17725 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integrated Services Working
Group of the IETF.
Title : Integrated Services Management Information Base
Author(s) : F. Baker, J. Krawczyk
Filename : draft-ietf-intserv-mib-03.txt
Pages : 12
Date : 11/04/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing the the interface attributes
defined in the Integrated Services Model. Comments should be made to the
Integrated Services Working Group, int-serv at isi.edu.
This memo does not, in its draft form, specify a standard for the
Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-intserv-mib-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-intserv-mib-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-intserv-mib-03.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104102728.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-intserv-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-intserv-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104102728.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab21854; 5 Nov 96 9:59 EST
Received: from localhost by ietf.org id aa19140; 5 Nov 96 9:47 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-freed-pvcsc-01.txt
Date: Tue, 05 Nov 1996 09:47:03 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050947.aa19140 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME Parameter Value and Encoded Words: Character Sets,
Language, and Continuations
Author(s) : N. Freed, K. Moore
Filename : draft-freed-pvcsc-01.txt
Pages : 10
Date : 11/04/1996
This memo defines extensions to the RFC MIME-IMB media type
and RFC 1806 disposition parameter value mechanisms to
provide (1) a means to specify parameter values in character sets
other than US-ASCII, (2) to specify the language to be used should
the value be displayed, and (3) a continuation mechanism for long
parameter values to avoid problems with header line wrapping.
This memo also defines an extension to the encoded words defined in RFC
MIME-HEADERS to allow the specification of the language to be used for
display as well as the character set.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-freed-pvcsc-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-freed-pvcsc-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-freed-pvcsc-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104135336.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-freed-pvcsc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-freed-pvcsc-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104135336.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ac21854; 5 Nov 96 9:59 EST
Received: from localhost by ietf.org id aa19577; 5 Nov 96 9:48 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: http-wg at cuckoo.hpl.hp.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-http-state-mgmt-04.txt, .ps
Date: Tue, 05 Nov 1996 09:48:42 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611050948.aa19577 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the HyperText Transfer Protocol
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : HTTP State Management Mechanism
Author(s) : D. Kristol, L. Montulli
Filename : draft-ietf-http-state-mgmt-04.txt, .ps
Pages : 19
Date : 11/04/1996
This document specifies a way to create a stateful session with HTTP
requests and responses. It describes two new headers, Cookie and
Set-Cookie, which carry state information between participating origin
servers and user agents. The method described here differs from Netscape's
Cookie proposal, but it can interoperate with HTTP/1.0 user agents that
use Netscape's method. (See the HISTORICAL section.)
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-http-state-mgmt-04.txt".
Or
"get draft-ietf-http-state-mgmt-04.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-http-state-mgmt-04.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-http-state-mgmt-04.txt".
Or
"FILE /internet-drafts/draft-ietf-http-state-mgmt-04.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961104150350.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-http-state-mgmt-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-http-state-mgmt-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961104150350.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22618; 5 Nov 96 10:10 EST
Received: from localhost by ietf.org id aa22401; 5 Nov 96 10:07 EST
To: IETF-Announce: ;
cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: MIME E-mail Encapsulation of Aggregate Documents, such
as HTML (MHTML) to Proposed Standard
Reply-to: iesg at ietf.org
Date: Tue, 05 Nov 1996 10:07:12 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611051007.aa22401 at ietf.org>
The IESG has received a request from the MIME Encapsulation of
Aggregate HTML Documents Working Group to consider the following three
documents for the status of Proposed Standard:
1. MIME E-mail Encapsulation of Aggregate Documents, such as HTML
(MHTML)
<draft-ietf-mhtml-spec-05.txt>
2. Content-ID and Message-ID Uniform Resource Locators
<draft-ietf-mhtml-cid-02.txt>
3. The MIME Multipart/Related Content-type
<draft-ietf-mhtml-related-00.txt>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by November 18, 1996.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa01511; 5 Nov 96 12:33 EST
Received: from relay.bt.net by ietf.org id aa01235; 5 Nov 96 12:29 EST
Received: from ripley.ukcore.bt.net (actually 194.72.139.129) by relay.bt.net with SMTP (PP); Tue, 5 Nov 1996 16:51:54 +0000
Comments: Authenticated sender is <jminhas at relay.bt.net>
Sender:ietf-request at ietf.org
From: Jag Minhas <jag at bt.net>
Organization: BTnet Network Operations Centre
To: Jorge Alejandro Oyarbide <joyarbide at txport.com>
Date: Tue, 5 Nov 1996 16:48:46 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: RE: NON SENSE. English is the best language for this....
Reply-to: jag at bt.net
CC: "ietf at ietf.org" <ietf at ietf.org>
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.40)
Message-ID: <9611051229.aa01235 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
> Well, I can't agree. Internet and 99% of associated "things"
> originated in the US.
>In fact, 90% of the Internet is in the U.S.A.
Really? I wonder how that fact was derived?
Best regards - Jag
Received: from ietf.org by ietf.org id aa08136; 5 Nov 96 13:47 EST
Received: from server.txport.com by ietf.org id aa08048; 5 Nov 96 13:45 EST
Received: from j_oyarbide.txport.com by txport.com (4.1/SMI-4.1)
id AA07475; Tue, 5 Nov 96 12:44:05 CST
Received: by j_oyarbide.txport.com with Microsoft Mail
id <01BBCB1F.6C636AA0 at j_oyarbide.txport.com>; Tue, 5 Nov 1996 13:44:10 -0500
Message-Id: <01BBCB1F.6C636AA0 at j_oyarbide.txport.com>
Sender:ietf-request at ietf.org
From: Jorge Alejandro Oyarbide <joyarbide at txport.com>
To: "edd at amnic.net" <edd at amnic.net>,
"'Valdis.Kletnieks at vt.edu'" <Valdis.Kletnieks at vt.edu>
Cc: "ietf at ietf.org" <ietf at ietf.org>
Subject: RE: English is it -> was: Re: The cartel begins to crumble?
Date: Tue, 5 Nov 1996 13:44:09 -0500
Return-Receipt-To: <joyarbide at txport.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Source-Info: From (or Sender) name not authenticated.
Do we need an official language ?? Can we just go with common sense ??
----------
De :Valdis.Kletnieks at vt.edu[SMTP:Valdis.Kletnieks at vt.edu]
Date d'envoi=A0:mardi 5 novembre 1996 10:44
A=A0:edd at amnic.net
Cc=A0:ietf at ietf.org
Objet=A0:Re: English is it -> was: Re: The cartel begins to crumble?=20
On Tue, 05 Nov 1996 16:14:43 +0300, you said:
> These facts are enough - the official language of the Internet=20
> IS the English language. This is fact.
Umm.. is this "official" official, being codified in an RFC or similar, =
or
merely a "de facto" official? I ran a quick 'grep -i english *.txt' on
a mirror of the RFCs, and although I found a lot of references
to "Bill English" as an author, and a lot of references as to how
English should be handled in the context of a specific protocol (for
instance, there were at least 20 hits against X.400/X.500 RFC's, and a
lot against MIME and charset issues), the only reference I found to
English as part of the Internet standards process itself was in RFC2026,
where the "sample copyright template" talks about translating to
languages other than English.
English is no more the "official" language of the Internet than
Windows 95 is the "official" operating system. No matter *what*
Bill Gates wishes were true...
--=20
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
<<Fichier=A0: ATT00011.att>>
Received: from ietf.org by ietf.org id aa08280; 5 Nov 96 13:48 EST
Received: from localhost by ietf.org id aa07876; 5 Nov 96 13:42 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: The PPP NetBIOS Frames Control Protocol (NBFCP)
to Proposed Standard
Date: Tue, 05 Nov 1996 13:41:59 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611051342.aa07876 at ietf.org>
The IESG has approved the Internet-Draft "The PPP NetBIOS Frames Control
Protocol (NBFCP)" <draft-ietf-pppext-netbios-fcp-08.txt> as a Proposed
Standard. This document is the product of the Point-to-Point Protocol
Extensions Working Group. The IESG contact persons are Frank Kastenholz
and Jeffrey Burgan.
Technical Summary
Multiple higher-level protocols may operate over PPP links. For a
protocol to be carried over a PPP link, a control protocol is
required. This control protocol is used to negotiate the operations
of that protocol. The PPP NetBIOS Frames Control Protocol is used to
configure and control PPP links to carry NetBIOS traffic.
Working Group Summary
This protocol was developed in the PPPEXT working group. Development
was without rancor
Protocol Quality
The protocol has been reviewed by Frank Kastenholz and Jeff Burgan.
Received: from ietf.org by ietf.org id aa08890; 5 Nov 96 13:56 EST
Received: from doorstep.unety.net by ietf.org id aa08790; 5 Nov 96 13:54 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id MAA15186 for <ietf at ietf.org>; Tue, 5 Nov 1996 12:48:39 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCB17.EAE3BAE0 at webster.unety.net>; Tue, 5 Nov 1996 12:50:26 -0600
Message-ID: <01BBCB17.EAE3BAE0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: FW: Popular Root Name Servers
Date: Tue, 5 Nov 1996 12:50:25 -0600
Encoding: 237 TEXT
Source-Info: From (or Sender) name not authenticated.
----------
From:Jim Fleming[SMTP:JimFleming at unety.net.]
Sent:Tuesday, November 05, 1996 11:54 AM
To:'Multiple recipients of list DOMAIN-POLICY'; 'New Newdom'
Cc:'bobm at NIC.DDN.MIL'; 'jamesf at ARL.MIL'; 'koda at ISI.EDU';
'marcel at NSIPO.NASA.GOV'; 'markk at NETSOL.COM'; 'matti at COMEDIA.SE';
'paul at VIX.COM'; 'psinet-domain-admin at PSI.COM'; 'sneeri at NI.UMD.EDU'
Subject:Popular Root Name Servers
To:
Vixie, Paul (PV15) paul at VIX.COM
Kosters, Mark A. (MAK21) markk at NETSOL.COM
Koda, Jim (JK7) koda at ISI.EDU
Sneeringer, Gerry (GS307) sneeri at NI.UMD.EDU
Fielding, James L. (JLF) jamesf at ARL.MIL
Administration, PSINet Domain (PDA4) psinet-domain-admin at PSI.COM
Rendahl, Matti [President] (MR164) matti at COMEDIA.SE
Schlapfer, Marcel (MS4039) marcel at NSIPO.NASA.GOV
McCollum, Robert W. (RM584) bobm at NIC.DDN.MIL
Re: Popular Root Name Servers
Greetings,
As the owners/operators/administrators/etc. of some of the most popular
root name servers in the world, you collectively control what top level
domains (TLDs) are supported on the global Internet and are "visible" to
most of the people.
As you may be aware, many people have worked for many months
to bring change to the top level domain administration of the Internet.
Here are some of the highlights of those changes:
1. The creation/addition of more top level domains.
2. The creation/addition of more commercially supported
registries for TLDs, IP addresses, and other
Internet resources.
3. The expansion of the root name server base to more areas
of the world and to more commercial companies.
These changes are essential to help grow the Internet and to assist
in transitioning the Internet from a U.S. government funded R&D project
to a commercial enterprise that can help the world communicate.
As the operators of the popular root name servers, you play a key
role in making sure that these transitions are smooth and that
people are not allowed to fragment the Internet. I encourage all of you
to actively participate in the discussions regarding these transitions.
If for any reason you do not feel that your server should be part of
this global expansion, then I suggest that you use the open forums
for discussion to inform everyone. As with many R&D projects, systems
that are used early in the development sometimes outlive their usefulness
and there is no easy way for people to transition out of the picture.
In my opinion, now is the time to make that transition as other
companies transition their servers into the picture.
Two of the more popular mailing lists for these discussions have
been included on the address. If you know of other more appropriate
lists or forums, I hope that you make suggestions.
In summary, your servers play a key role in the current Internet
Infrastructure. It is important for everyone to fully understand what
role they will play in the future to make sure that transitions are
smooth and orderly. Your comments are always welcome.
Jim Fleming
------------------------------------------------------
SERVER NS.ISC.ORG 192.5.5.241
Internet Software Consortium (ISC)
Hostname: F.ROOT-SERVERS.NET
Address: 192.5.5.241
System: DEC ALPHA running BIND 4.9.5
Host Administrator:
Vixie, Paul (PV15) paul at VIX.COM
+1 415 747 0204
Domain Server
Record last updated on 09-Oct-96.
-------
SERVER NS.INTERNIC.NET 198.41.0.4
Network Solutions, Inc. (NS45-HST)
505 Huntmar Park Drive
Herndon, VA 22070
Hostname: A.ROOT-SERVERS.NET
Address: 198.41.0.4
System: SUN running SUNOS
Host Administrator:
Kosters, Mark A. (MAK21) markk at NETSOL.COM
(703) 742-4795 (FAX) (703) 742-4811
Record last updated on 31-Aug-95.
-------
SERVER NS1.ISI.EDU 128.9.0.107
University of Southern California (ISI2)
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Hostname: B.ROOT-SERVERS.NET
Address: 128.9.0.107
System: ? running ?
Host Administrator:
Koda, Jim (JK7) koda at ISI.EDU
310) 822-1511
Record last updated on 12-Aug-95.
-------
SERVER TERP.UMD.EDU 128.8.10.90
University of Maryland (UMD-TERP)
Computer Science Center
College Park, MD 20742
Hostname: D.ROOT-SERVERS.NET
Address: 128.8.10.90
System: MICROVAX-II running UNIX
Coordinator:
Sneeringer, Gerry (GS307) sneeri at NI.UMD.EDU
(301) 405-2996
domain server
Record last updated on 12-Aug-95.
-------
SERVER AOS.ARL.ARMY.MIL 128.63.2.53
Army Research Laboratory (BRL-AOS)
Aberdeen Proving Ground, MD 21005-5066
Hostname: H.ROOT-SERVERS.NET
Address: 128.63.2.53
System: SUN running UNIX
Host Administrator:
Fielding, James L. (JLF) jamesf at ARL.MIL
(410)278-8929 (DSN) 298-8929 (410)278-6664 (FAX) (410)278-5077
domain server
Record last updated on 17-Aug-95.
-------
SERVER C.PSI.NET 192.33.4.12
Performance Systems International Inc. (C-NYSER)
Hostname: C.ROOT-SERVERS.NET
Address: 192.33.4.12
System: SUN running UNIX
Coordinator:
Administration, PSINet Domain (PDA4) psinet-domain-admin at PSI.COM
(703) 904-4100
domain server
Record last updated on 17-Apr-96.
-------
SERVER NIC.NORDU.NET 192.36.148.17
[No name] (NORDU)
Hostname: I.ROOT-SERVERS.NET
Address: 192.36.148.17
System: SUN-4/60 running UNIX
Coordinator:
Rendahl, Matti [President] (MR164) matti at COMEDIA.SE
+46 8 612 49 26 +46 70 533 13 56 (FAX) +46 8 612 49 36
Record last updated on 24-Aug-95.
-------
SERVER NS.NASA.GOV 192.203.230.10
Moffett Field (NS-NASA)
NASA Ames Research Center, Mail Stop 233-8
Moffett Field, CA 94035-1000
USA
Hostname: E.ROOT-SERVERS.NET
Address: 192.203.230.10
System: SUN running SUNOS
Host Administrator, Coordinator:
Schlapfer, Marcel (MS4039) marcel at NSIPO.NASA.GOV
1-415-604-0955 (FAX) 1-415-604-0036
domain server
Record last updated on 25-Oct-96.
-------
SERVER NS.NIC.DDN.MIL 192.112.36.4
GSI (DIIS-NS)
Suite 200
14200 Park Meadow Dr.
Chantilly, VA 22021
Hostname: G.ROOT-SERVERS.NET
Address: 192.112.36.4
System: SUN running UNIX
Coordinator:
McCollum, Robert W. (RM584) bobm at NIC.DDN.MIL
(703) 802-8476 (FAX) (703) 802-8376
Root Domain Server
Record last updated on 18-Aug-95.
-------
Received: from ietf.org by ietf.org id aa09768; 5 Nov 96 14:20 EST
Received: from zephyr.isi.edu by ietf.org id aa09586; 5 Nov 96 14:14 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA02512>; Tue, 5 Nov 1996 11:13:24 -0800
Message-Id: <199611051913.AA02512 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: BCP 12, RFC 2050 on Internet Registry IP Allocation Guidelines
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 05 Nov 96 11:13:23 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
BCP 12:
RFC 2050:
Title: INTERNET REGISTRY IP ALLOCATION GUIDELINES
Author: K. Hubbard, M. Kosters, D. Conrad,
D. Karrenberg, J. Postel
Date: November 1996
Mailbox: kimh at internic.net, markk at internic.net,
davidc at APNIC.NET, dfk at RIPE.NET, Postel at ISI.EDU
Pages: 13
Characters: 28,975
Updates/Obsoletes: 1466
URL: ftp://ds.internic.net/rfc/rfc2050.txt
This document describes the registry system for the distribution of
globally unique Internet address space and registry operations.
Particularly this document describes the rules and guidelines
governing the distribution of this address space. This RFC is a
product of the CIDR Deployment Working Group of the IETF.
IESG Note: By approving this document as a Best Current Practice,the
IESG asserts its belief that this policy described herein is an
accurate representation of the current practice of the IP address
registries with respect to address assignment. This does not
constitute endorsement or recommendation of this policy by the IESG.
The IESG will reevaluate its approval of this document in December
1997 taking into consideration the results of the discussions that
will be take place in the IRE Working Group between now and then.
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961105104950.RFC at ISI.EDU>
SEND /rfc/rfc2050.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2050.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961105104950.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09829; 5 Nov 96 14:21 EST
Received: from cnri by ietf.org id aa09720; 5 Nov 96 14:19 EST
Received: from verdi.nethelp.no by CNRI.Reston.VA.US id aa17616;
5 Nov 96 14:19 EST
Received: (qmail 6493 invoked by uid 1001); 5 Nov 1996 19:17:52 +0000 (GMT)
To: ietf at CNRI.Reston.VA.US
Subject: RE: NON SENSE. English is the best language for this....
Sender:ietf-request at ietf.org
From: sthaug at nethelp.no
X-Mailer: Mew version 1.05+ on Emacs 19.28.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Tue, 05 Nov 1996 20:17:51 +0100
Message-ID: <6491.847221471 at verdi.nethelp.no>
Source-Info: From (or Sender) name not authenticated.
> > Well, I can't agree. Internet and 99% of associated "things"
> > originated in the US.
>
> >In fact, 90% of the Internet is in the U.S.A.
>
> Really? I wonder how that fact was derived?
Certainly not by any scientific method. Even if you don't define what
'the Internet' includes, let's take a look at host count statistics.
1. Network Wizards results for the whole Internet, July 1996
(http://www.nw.com/zone/WWW/report.html):
12,881,000 hosts
2. RIPE NCC hostcount for all European top level domains, July 1996
(http://www.ripe.net/):
3,017,784 hosts
I'll let people draw their own conclusions.
Steinar Haug, Nethelp consulting, sthaug at nethelp.no
Received: from ietf.org by ietf.org id aa10444; 5 Nov 96 14:38 EST
Received: from doorstep.unety.net by ietf.org id aa10253; 5 Nov 96 14:33 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id NAA15294; Tue, 5 Nov 1996 13:27:54 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCB1D.674229A0 at webster.unety.net>; Tue, 5 Nov 1996 13:29:42 -0600
Message-ID: <01BBCB1D.674229A0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'System Administrator' <root at taka.agn.net>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>, 'New Newdom' <newdom at vrx.net>
Subject: RE: When? (was Re: NEWDOM: Re: TODO)
Date: Tue, 5 Nov 1996 13:29:41 -0600
Encoding: 100 TEXT
Source-Info: From (or Sender) name not authenticated.
On Tuesday, November 05, 1996 5:47 AM, System Administrator[SMTP:root at Taka.AGN.NET] wrote:
@ >
@ > Perry, if you can assure me either that the delay will be considerably less
@ > than 6 months or that we may have some assurance of being accepted I will
@ > gladly shut up and sit patiently. I am not unreasonable on this issue.
@ > Given an assurance of being accepted and the proposed date of addition to
@ > the root servers will allow us to patiently wait for that day. Until then,
@ > we're in limbo, and frankly, that's not a good place to be. Please don't
@ > let it get any more out of hand than it already is.
@ >
@ > Bottom line, we have an operational registry - when can we be placed in the
@ > root servers?
@ >
@
@ Ditto.
@
@ We were the first with both USA and EARTH and have had an operational
@ registry for 7 months now.
@
@ Consider this: If the 6 months time frame is correct, IANA will lose all
@ control of this and AlterNic will become the de-facto TLD registry.
@ (This is not a bad thing, IMHO)
@
@ John
@
@
Re: When? (was Re: NEWDOM: Re: TODO)
bmanning at ISI.EDU
Tue, 5 Nov 1996 08:41:34 -0800 (PST)
>
> On Mon, 4 Nov 1996, Christopher Ambler wrote:
> > Bottom line, we have an operational registry - when can we be placed
> > in the root servers?
>
> No, you have an *experimental* registry. It might never be added to the
> root servers.
>
> --apb (Alan Barrett)
>
Hi,
You will note that the two, "operational" and *experimental*
are not mutually exclusive. I get the impression that the
biggest hurdle is that folks who are running operational
registries presume that this is the only criteria for being
injected into the Internet root servers. It clearly is not.
For the nonce, the best they can expect is to be placed
in the Alternic or the outerInternets root servers.
One hopes that the IAHC is able to quickly resolve the process
issues and provide guidance on what other critera must be
met.
--bill
------------------------------------------------------------------------------
To Subscribe or Unsubscribe send e-mail to newdom-request at ar.com with the word
'subscribe' or 'unsubscribe' in the body of your message.
A HTML Archive of this list is at http://www.ar.com/lists/newdom/
@@@@@@
People should note carefully that some of the discussion
on the OLD newdom does not make it to the NEW newdom
and vice versa. This is partly because some people are not
allowed to post to the OLD newdom list.
This has the effect of making people who *only* read the
OLD newdom list think that the discussion that is being
held represents an OPEN forum when people know it is
not.
It is a shame that there is no easy way to alert the readers
of the OLD newdom list about the censorship that is going
on. If the goal of the list operators is to create a list where
only certain people are allowed to speak, why don't they
let people know, and then the readers can understand how
to interpret the comments made on that list.
It is disturbing to find out that governing bodies can draw
conclusions about people's views based on one's lack
of participation in a process when some of those individuals
are not allowed to participate in the process and that is
not taken into account.
The IETF and other organizations can claim all they want
that they are an "open" forum. Maybe a better way to
put it would be an open hallway with many closed doors
and only certain people have the keys...
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa12831; 5 Nov 96 15:04 EST
Received: from zephyr.isi.edu by ietf.org id aa12222; 5 Nov 96 14:59 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00605>; Tue, 5 Nov 1996 10:48:27 -0800
Message-Id: <199611051848.AA00605 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2022 on Multicast over UNI 3.0/3.1 based ATM
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 05 Nov 96 10:48:27 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2022:
Title: Support for Multicast over UNI 3.0/3.1
based ATM Networks
Author: G. Armitage
Date: November 1996
Mailbox: gja at thumper.bellcore.com
Pages: 82
Characters: 189,219
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2022.txt
Mapping the connectionless IP multicast service over the connection
oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task.
This memo describes a mechanism to support the multicast needs of
Layer 3 protocols in general, and describes its application to IP
multicasting in particular. This RFC is a product of the IP/ATM
working group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961105103453.RFC at ISI.EDU>
SEND /rfc/rfc2022.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2022.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961105103453.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13775; 5 Nov 96 15:17 EST
Received: from zephyr.isi.edu by ietf.org id aa13513; 5 Nov 96 15:14 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA07058>; Tue, 5 Nov 1996 12:13:28 -0800
Message-Id: <199611052013.AA07058 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2056 on URLs for Z39.50
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 05 Nov 96 12:13:27 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2056:
Title: Uniform Resource Locators for Z39.50
Author: R. Denenberg, J. Kunze, D. Lynch
Date: November 1996
Mailbox: ray at rden.loc.gov, jak at ckm.ucsf.edu,
DenisL at SilverPlatter.com
Pages: 7
Characters: 14,204
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2056.txt
Z39.50 is an information retrieval protocol that does not fit neatly
into a retrieval model designed primarily around the stateless fetch
of data. Instead, it models a general user inquiry as a
session-oriented, multi-step task, any step of which may be suspended
temporarily while the server requests additional parameters from the
client before continuing. This RFC is a product of the Uniform
Resource Identifiers Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961105120210.RFC at ISI.EDU>
SEND /rfc/rfc2056.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2056.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961105120210.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa18827; 5 Nov 96 16:23 EST
Received: from cnri by ietf.org id aa18668; 5 Nov 96 16:19 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa20180;
5 Nov 96 16:19 EST
Received: from ruebert.ieee.org by venera.isi.edu (5.65c/5.61+local-25)
id <AA06041>; Tue, 5 Nov 1996 13:18:00 -0800
Received: (from root at localhost) by ruebert.ieee.org (8.7.5/8.7.3) id QAA12359; Tue, 5 Nov 1996 16:18:17 -0500 (EST)
Date: Tue, 5 Nov 1996 16:18:17 -0500 (EST)
Message-Id: <199611052118.QAA12359 at ruebert.ieee.org>
Sender:ietf-request at ietf.org
From: Communications Society Marketing <comsoc-mktg at ieee.org>
To: ietf at isi.edu
Subject: Apology regarding comsoc-conferences subscriptions
Precedence: bulk
X-Sender: postmaster at ieee.org
X-Loopdetect: postmaster at ieee.org
Organization: IEEE Communications Society
Source-Info: From (or Sender) name not authenticated.
Dear Communications Industry Professional,
Please accept our apology for creating a list with your email address
on it yesterday. In our attempts to make use of these exciting new
technologies, our enthusiasm took us beyond our full understanding
of the ramifications of what we were attempting.
In a effort to fix the resulting problem, we have removed ALL addresses
from this list, including yours.
If you are interested in learning about important upcoming IEEE
Communications Society events, such as the dates, locations and paper
submission details and deadlines, please follow the instructions below
to subscribe to this list.
In the coming months we will be sending short announcements to you
with pointers to Internet locations. There you can get the information
you want about IEEE Communications Society events, such as visiting
our Conference Calendar listing at
http://www.ieee.org/comsoc/confs/
where you can find details on communications industry conferences,
workshops and symposia scheduled in the next two years.
Again, we're sorry for the messages you received yesterday regarding
this list and assure you that, unless YOU subscribe to it, you will
not be on it.
Thank you,
Clark DesSoye, Marketing Manager, IEEE Communications Society
Instructions for subscribing to the 'comsoc-conferences' Mailing-List:
Simply send an E-Mail message to:
majordomo at majordomo.ieee.org
containing one of the following lines in the body:
subscribe comsoc-conferences
-or-
subscribe comsoc-conferences e-mail_address
The first format will subscribe YOUR e-mail address as it
appears in the headers of your message. Use the 2nd format
to subscribe an alternate address.
Received: from ietf.org by ietf.org id aa19921; 5 Nov 96 16:46 EST
Received: from cnri by ietf.org id ab19791; 5 Nov 96 16:41 EST
Received: from thunder.ncr.disa.mil by CNRI.Reston.VA.US id aa20651;
5 Nov 96 16:41 EST
Received: from ncr.disa.mil ([164.117.176.106]) by thunder.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id QAA29345; Tue, 5 Nov 1996 16:25:49 -0500 (EST)
Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01)
id AA847240807; Tue, 05 Nov 96 16:34:40 EST
Date: Tue, 05 Nov 96 16:34:40 EST
Sender:ietf-request at ietf.org
From: "C.Joe Pasquariello" <pasquarc at ncr.disa.mil>
Message-Id: <9610058472.AA847240807 at ncr.disa.mil>
To: ISOC-Advisory-Council at isoc.org
Cc: ISOC-Trustees at isoc.org, IETF at CNRI.Reston.VA.US,
"ISOC Exec. Dir." <burack at isoc.org>
Subject: ISOC Advisory Council - Officer Election Announcement
Source-Info: From (or Sender) name not authenticated.
Greetings to the Council et al !
'Enclosed' below is:
- the proposed schedule and other particulars for filling the two
vacant officer positions on the ISOC Advisory Council, and
- a copy of the current Advisory Council mail list.
In view of the recent issuance of the RFC on ISOC/IETF Relationships,
I am copying the IETF list - for your information - and also with the
view of identifying any possible additional nominees.
An Advisory Council meeting is planned for Thursday PM of the IETF
meeting week - prior to the IETF Plenary. The meeting will be open to
any interested IETFers.
cheers,
C.Joe P-->
Chair, ISOC Advisory Council
-------------------------------------
|Camillo J. PASQUARIELLO, SES |
|Associate Director |
|US/DoD/DISA/Center for Standards |
|10701 Parkridge Blvd |
|Reston, VA 20191-4357 |
|Tel: (703) 735-3305 |
|FAX: (703) 735-3255 |
|EMail: PasquarC at ncr.disa.mil |
-------------------------------------
NB: 1. This and other documents of the ISOC Advisory Council are
posted on the ISOC gopher server <gopher.isoc.org> at
<isoc/bodies/council/documents>.
2. IF YOU RECEIVE THIS MESSAGE, AND ARE NOT YOUR ORGANIZATION'S
PRIMARY REPRESENTATIVE OR ALTERNATE TO ISOC, PLEASE ADVISE - SO WE
CAN TAKE ACTION TO KEEP OUR COUNCIL MAILING LIST [cy below]
CURRENT. [cc addressees excepted]. THANX!
==================== Election Announcement Follows =====================
Title: ISOC Advisory Council - Election Notice
Author: C.Joe PASQUARIELLO
Date: 1996.11.05
Body: Advisory Council
Document: 96-005
Revision: Basic
Supersedes:
Status: For comment & execution
Maintainer: Council Chair
=================================================================
Dear Members of the Advisory Council -
As we discussed in Montreal, there are two vacancies for Council
Officers to be filled.
I am pleased to report that the following members have indicated
their willingness to serve. OF COURSE, OTHER NOMINEES WOULD BE
WELCOME TOO:
- Prof.Dr. Srisakdi Charmonman; Thailand; Assumption
University
- Micheal E.Conn; USA; MCI Corp.
- Ole J. Jacobsen; USA; InterOp Company
- Stefano Trumpy; Italy, CNUCE
Accordingly we will need conduct an election as we did in
1994, via Email, with weighted voting - two votes per member
organization.
I propose the following procedure and schedule:
- 15 Nov: Nominations closed. Each candidate submit short
CV and statement.
- 18 Nov: Call for votes by ISOC Staff
- 30 Nov: Voting Closed
- 02 Dec: ISOC staff announce selections
[wk] - 09 Dec: New Officers seated at the December Council and
Board of Trustees Meetings
As of the December meeting, the Chair will also rotate to Nick
Trio, USA; IBM Corp.
Without objection, I propose we proceed according to the above.
Pls advise if you have comments or suggestions on this,
THX &
Best Regards,
/s/ C.Joe Pasquariello
Chair ISOC Advisory Council
=================== End Announcement =======================
============ Council Mailing List A.O. 5 Nov 96 Follows ===================
"Bernard Aboba <alt.>" <bernarda at microsoft.com>
"James Allard" <jallard at microsoft.com>
"Guy Almes" <almes at advanced.org>
"Robert Anderson (alt.)" <Anderson at Rand.org>
"Fred Aronson" <aronson at acm.org>
"Toshiya Asaba (alt.)" <asaba at iij.ad.jp>
"Cliff Bamford" <bamford at netcom.com>
"Keith Basil" <staff at tcp.ip.net>
"Andrew Bjerring" <bjerring at canarie.ca>
"Mark R. Boolootian" <booloo at llnl.gov>
"Charles Brownstein" <cbrownst at cnri.reston.va.us>
"Martin Burack" <burack at isoc.org>
"David Cantrell" <dcantrel at novell.com>
"Vint Cerf <alt.>" <vcerf at mci.net>
"Srisakdi Charmonman" <charm at abac.au.ac.th>
"Chris Chaundy" <chris at connect.com.au>
"Steve Cisler" <sac at apple.com>
"Michael Clore" <clore at acm.org>
"Avi Cohen" <A32 at taunivm.tau.ac.il>
"Jim Conklin (alt.)" <jbc at bitnic.educom.edu>
"Michael Conn" <meconn at mcimail.com>
"David Conrad" <davidc at apnic.net>
"Jim Dolgonas (alt.)" <jim.dolgonas at ucop.edu>
"T. Michael Elliott" <t.m.elliott at computer.org>
"Benjamin Epstein" <bepstein at ftna.com>
"Francois Fluckiger" <fluckiger at vxcern.cern.ch>
"Dave Frederickson <alt.>" <frederid at itsi.disa.mil>
"Ira Fuchs" <fuchs at princeton.edu>
"Kaye Gapen (alt.)" <kgapen at morino.org>
"Antonia Ghiselli (alt.)" <ghiselli at infn.it>
"Bill Godwin (alt.)" <godwin at info.net>
"Ben Golding (alt.)" <bgg at connect.com.au>
"Masaki Itoh" <itoh at slab.ntt.jp>
"Terry Gray" <gray at cac.washington.edu>
"Frode Greisen (alt.)" <Frode.Greisen at uni-c.dk>
"Erik Grimmelmann" <egrimmelmann at attmail.com>
"Mark Haas" <m.haas at computer.org>
"Anthony Hearn" <hearn at rand.org>
"Anita Holmgren" <anita at tenon.com>
"Steve Holmgren (alt.)" <holmgren at tenon.com>
"Ryoichi Hosoya" <hosoya at slab.ntt.jp>
"Richard Hronicek" <rahroni at srv.pacbell.com>
"Geoff Huston" <gih at telstra.net>
"Ole Jacobsen (alt.)" <ole at interop.com>
"Ron Johnson (alt.)" <ronj at cac.washington.edu>
"Walter Johnston" <walter at nynexst.com>
"Dr. D. F. Hartley" <d.hartley at ukerna.ac.uk>
"Cyndi Jung (alt.)" <cmj at 3com.com>
"Kevin Kahn (alt.)" <Kevin_Kahn at ccm.jf.intel.com>
"Robert Kahn" <rkahn at cnri.reston.va.us>
"Tomaz Kalin (alt.)" <kalin at rare.nl>
"Rafiq Khan (alt.)" <khanr at canarie.ca>
"Kenneth King" <kmk7 at cornell.edu>
"Tatsuo Kobayashi (alt.)" <Tatsuo_Kobayashi at justsystem.co.jp>
"Tracy LaQuey Parker" <tparker at cisco.com>
"Mark Laubach" <laubach at netcom.com>
"Yuet Lee (alt.)" <yclee at srv.pacbell.com>
"Stephan Leicht" <leicht at fz.telekom.de>
"Jean Le Mezec" <jlmft at mcimail.com>
"Bob Lemley" <lemley at acm.org>
"Donald Lindberg" <lindberg at lhc.nlm.nih.gov>
"Robert Lucky (alt.)" <rlucky at bellcore.com>
"Richard Mandelbaum" <rma at nysernet.org>
"Olivier Martin (alt.)" <omartin at dxcoms.cern.ch>
"Daniel Masys (alt.)" <masys at lhc.nlm.nih.gov>
"Alexander McKenzie" <mckenzie at bbn.com>
"Klara Mikus (alt.)" <h1245mik at iif.hu>
"Kees Neggers" <neggers at surfnet.nl>
"Seppo Noppari (alt.)" <Seppo.Noppari at tele.fi>
"Richard Nuttall" <richard at pipex.net>
"Jeffrey Ogden (alt.)" <jco at merit.edu>
"C. Joe Pasquariello" <pasquarc at ncr.disa.mil>
"Adam Peake" <ajp at glocom.ac.jp>
"Ole Carsen Pedersen" <unikocp at unidhp1.uni-c.dk>
"Abraham Peled" <abe at elron.net>
"Paul Peters" <paul at cni.org>
"Richard Pethia" <rdp at cert.sei.cmu.edu>
"John Phillips" <ttijp at cerf.net>
"Randolph Pitzer (alt.)" <rpitzer at spyglass.com>
"Larry Rapagnani" <rapagnani.1 at nd.edu>
"Peter Rastl" <rastl at cc.univie.ac.at>
"Steve Russell" <steve_russell at 3com.com>
"Nobuo Sakata" <sakata at web.ad.jp>
"Martin Schoffstall" <schoff at psi.com>
"William Schrader (alt.)" <wls at psi.com>
"Paul Severino (alt.)" <sev at baynetworks.com>
"Shawn Sexton <alt.>" <Shawn.P.Sexton.1 at nd.edu>
"Ehud Shapiro" <udi at ubique.co.il>
"Robert Shaw" <shaw at itu.ch>
"Tony Shaw (alt.)" <tti at cerf.net>
"W. David Sincoskie" <sincos at bellcore.com>
"Hermann Steinringer (alt.)" <steinringer at cc.univie.ac.at>
"Glenn Stewart (alt.)" <glenn at catapult.com>
"Leonard Swatski (alt.)" <swatskil at ncr.disa.mil>
"Olle Thylander (alt.)" <Olle.Thylander at hsv.se>
"Nicholas Trio" <nrt at watson.ibm.com>
"Stefano Trumpy" <trumpy at icnucevm.cnuce.cnr.it>
"Klaus Ullmann" <ullmann at dfn.d400.de>
"Enzo Valente" <valente at infn.it>
"Peter Villemoes" <peter.villemoes at nordu.net>
"Hans Wallberg" <Hans.Wallberg at umdac.umu.se>
"Bernie White" <bwhite at gte.com>
"Ray White" <white1r at itsi.disa.mil>
"Kanokwan Wongwatanasin (alt.)" <kanokwan at ksc.au.ac.th>
"Yoshihiro Yamakowa" <Yoshihiro_Yamakawa at justsystem.co.jp>
================ End AC Mail List =======================
Received: from ietf.org by ietf.org id aa20523; 5 Nov 96 16:56 EST
Received: from po2.glue.umd.edu by ietf.org id aa20237; 5 Nov 96 16:53 EST
Received: from bandwidth.eng.umd.edu (gravman at bandwidth.eng.umd.edu [129.2.98.136]) by po2.glue.umd.edu (8.8.2/8.7.3) with ESMTP id QAA02542 for <ietf at ietf.org>; Tue, 5 Nov 1996 16:52:58 -0500 (EST)
Received: from localhost (gravman at localhost) by bandwidth.eng.umd.edu (8.8.2/8.6.4) with SMTP id QAA04746 for <ietf at ietf.org>; Tue, 5 Nov 1996 16:52:54 -0500 (EST)
X-Authentication-Warning: bandwidth.eng.umd.edu: gravman owned process doing -bs
Date: Tue, 5 Nov 1996 16:52:54 -0500 (EST)
Sender:ietf-request at ietf.org
From: Gravman <gravman at glue.umd.edu>
X-Sender: gravman at bandwidth.eng.umd.edu
To: ietf at ietf.org
Message-ID: <Pine.SOL.3.95.961105165238.4738B-100000 at bandwidth.eng.umd.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
unsubscribe
Received: from ietf.org by ietf.org id aa16213; 5 Nov 96 21:50 EST
Received: from zephyr.isi.edu by ietf.org id aa15912; 5 Nov 96 21:48 EST
Received: by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA00743>; Tue, 5 Nov 1996 18:45:36 -0800
Sender:ietf-request at ietf.org
From: Bill Manning <bmanning at isi.edu>
Message-Id: <199611060245.AA00743 at zephyr.isi.edu>
Subject: Re: When? (was Re: NEWDOM: Re: TODO)
To: Jim Fleming <JimFleming at unety.net>
Date: Tue, 5 Nov 1996 18:45:36 -0800 (PST)
Cc: root at taka.agn.net, ietf at ietf.org, newdom at vrx.net
In-Reply-To: <01BBCB1D.674229A0 at webster.unety.net> from "Jim Fleming" at Nov 5, 96 01:29:41 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1189
Source-Info: From (or Sender) name not authenticated.
> People should note carefully that some of the discussion
> on the OLD newdom does not make it to the NEW newdom
> and vice versa. This is partly because some people are not
> allowed to post to the OLD newdom list.
>
As Jim clearly points out, there is more than
one mailing list labeled "newdom". It seems
his current favorite is the one hosted from
vrx.com. The original was hosted from iiia.org
until the list owner shut it down due to perceived
threats of legal action from some members of
said list.
The main thrust of the list then moved to ar.net,
where things went along just fine, until some of
the same set of people apparently became disruptive
enough that they were expelled.
Things are now split between the ar.net and vrx.com
lists. The folks that seemed to cause the largest
amount of problems on the iiia.org and ar.net are
now attempting to socialize their beliefs in a wide
variety of fora, generally espousing broader vision
and more "open-ness" than is found in the regular fora
of Internet protocols or operations types. It seems
clear that they have near zero clue and have the
attention span and patience of my two year old.
--bill
Received: from ietf.org by ietf.org id aa16920; 5 Nov 96 21:59 EST
Received: from Kitten.mcs.com by ietf.org id aa16665; 5 Nov 96 21:58 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id UAA05388; Tue, 5 Nov 1996 20:57:15 -0600 (CST)
Received: from Jupiter.Mcs.Net (karl at Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id UAA12374; Tue, 5 Nov 1996 20:57:14 -0600 (CST)
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id UAA02378; Tue, 5 Nov 1996 20:57:13 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611060257.UAA02378 at Jupiter.Mcs.Net>
Subject: Re: When? (was Re: NEWDOM: Re: TODO)
To: Bill Manning <bmanning at isi.edu>
Date: Tue, 5 Nov 1996 20:57:13 -0600 (CST)
Cc: JimFleming at unety.net, root at taka.agn.net, ietf at ietf.org, newdom at vrx.net
In-Reply-To: <199611060245.AA00743 at zephyr.isi.edu> from "Bill Manning" at Nov 5, 96 06:45:36 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>The folks that seemed to cause the largest
>amount of problems on the iiia.org and ar.net are
>now attempting to socialize their beliefs in a wide
>variety of fora, generally espousing broader vision
>and more "open-ness" than is found in the regular fora
>of Internet protocols or operations types. It seems
^^^^^^^^
>clear that they have near zero clue and have the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>attention span and patience of my two year old.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> --bill
And people wonder why folks are going around the "old guard".
Personal attacks and insults will get you nowhere Bill.
However, they will get you, and the organizations you are affiliated with,
particularly the IANA, ignored by those of us intent on making progress and
actually *doing something*.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa16968; 5 Nov 96 21:59 EST
Received: from apnic-ttc.apnic.net by ietf.org id aa16839; 5 Nov 96 21:58 EST
Received: by apnic-ttc.apnic.net; id LAA16850; Wed, 6 Nov 1996 11:52:39 +0900
Received: from unknown(10.0.10.4) by apnic-ttc.apnic.net via smap (g3.0.3)
id xma016840; Wed, 6 Nov 96 11:52:14 +0900
Received: from apnic.net (davidc at localhost) by moonsky.jp.apnic.net (8.8.2/8.7.1) with ESMTP id LAA00336; Wed, 6 Nov 1996 11:51:07 +0900 (JST)
Message-Id: <199611060251.LAA00336 at moonsky.jp.apnic.net>
X-Authentication-Warning: moonsky.jp.apnic.net: davidc owned process doing -bs
To: Jim Fleming <JimFleming at unety.net>
cc: 'System Administrator' <root at taka.agn.net>,
"'ietf at ietf.org'" <ietf at ietf.org>, 'New Newdom' <newdom at vrx.net>,
davidc at apnic.net
reply-to: newdom at vrx.net
Subject: Re: When? (was Re: NEWDOM: Re: TODO)
In-reply-to: Your message of "Tue, 05 Nov 1996 13:29:41 CST."
<01BBCB1D.674229A0 at webster.unety.net>
Date: Wed, 06 Nov 1996 11:51:07 +0900
Sender:ietf-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Source-Info: From (or Sender) name not authenticated.
Hi,
>People should note carefully that some of the discussion
>on the OLD newdom does not make it to the NEW newdom
>and vice versa. This is partly because some people are not
>allowed to post to the OLD newdom list.
Simply because those people were either to be constructive and/or they
were abusive. For those that aren't aware, Jim Fleming was seen as
one such individual. Unfortunately, the choices a list administrator
has are somewhat limited when it comes to trying to curb individuals
who (for whatever reason) are viewed as being incapable of working and
playing well with others.
>The IETF and other organizations can claim all they want
>that they are an "open" forum. Maybe a better way to
>put it would be an open hallway with many closed doors
>and only certain people have the keys...
The IETF is among the most open forums of which I am aware. Have you
ever been to an IETF? Also, given that newdom is not an IETF working
group, what exactly does the fact you were kicked off from newdom have
to do with the IETF?
Finally, given that multiple mailing lists exist for discussions on
DNS and TLD related issues, can we PLEASE not spam the IETF list with
newdom gunk (note reply-to)?
Thanks,
-drc
Received: from ietf.org by ietf.org id aa17431; 5 Nov 96 22:05 EST
Received: from doorstep.unety.net by ietf.org id aa17361; 5 Nov 96 22:04 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id UAA16710; Tue, 5 Nov 1996 20:58:20 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCB5C.544294E0 at webster.unety.net>; Tue, 5 Nov 1996 21:00:09 -0600
Message-ID: <01BBCB5C.544294E0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Bill Manning' <bmanning at isi.edu>
Cc: "ietf at ietf.org" <ietf at ietf.org>, "newdom at vrx.net" <newdom at vrx.net>,
"root at taka.agn.net" <root at taka.agn.net>
Subject: RE: When? (was Re: NEWDOM: Re: TODO)
Date: Tue, 5 Nov 1996 21:00:07 -0600
Encoding: 73 TEXT
Source-Info: From (or Sender) name not authenticated.
On Tuesday, November 05, 1996 12:45 PM, Bill Manning[SMTP:bmanning at ISI.EDU] wrote:
@ > People should note carefully that some of the discussion
@ > on the OLD newdom does not make it to the NEW newdom
@ > and vice versa. This is partly because some people are not
@ > allowed to post to the OLD newdom list.
@ >
@
@As Jim clearly points out, there is more than
@one mailing list labeled "newdom". It seems
@his current favorite is the one hosted from
@vrx.com. The original was hosted from iiia.org
@until the list owner shut it down due to perceived
@threats of legal action from some members of
@said list.
@
@The main thrust of the list then moved to ar.net,
@where things went along just fine, until some of
@the same set of people apparently became disruptive
@enough that they were expelled.
@
@Things are now split between the ar.net and vrx.com
@lists. The folks that seemed to cause the largest
@amount of problems on the iiia.org and ar.net are
@now attempting to socialize their beliefs in a wide
@variety of fora, generally espousing broader vision
@and more "open-ness" than is found in the regular fora
@of Internet protocols or operations types. It seems
@clear that they have near zero clue and have the
@attention span and patience of my two year old.
@
@ --bill
@
@
As usual, this is a one-sided view.
The NEW newdom list (hosted by vrx.net) has been
largely cultivated by people that want to get something
specific accomplished. Things were going fine and we
were having discussions about Root 64 and other specifc
objectives.
Because of this specific progress, people started moving
from the OLD newdom list and helping to work toward
specific results. The discussion on the OLD newdom list
diminished to a point where the list operator suggested
closing the list. That announcement caused a group of
people to switch lists resulting in a degeneration of the
progress being made.
As in the past, I suggest that everyone return to working
on specific projects with specific goals and objectives.
While this might anger some of the people trying to
derail these efforts, we can not allow that to slow things
down.
In the end, the entire global Internet will be able to
judge the results, and the archives will clearly show
who contributed and who did not. Computer historians
can pick through those archives and document what
occurred.
Our task at hand is to document the future....
...we have a lot of work to do...
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa19358; 5 Nov 96 22:25 EST
Received: from presence.lglobal.com by ietf.org id aa18762; 5 Nov 96 22:24 EST
Received: from [207.107.12.74] (voyager9.lglobal.com [207.107.12.74]) by presence.lglobal.com (8.6.12/8.6.12) with SMTP id WAA02122; Tue, 5 Nov 1996 22:32:02 -0500
X-Sender: allisat at mail.lglobal.com
Message-Id: <v01540b05aea5ae913220 at [207.107.12.74]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 5 Nov 1996 22:27:19 -0500
To: Bill Manning <bmanning at isi.edu>
Sender:ietf-request at ietf.org
From: Bob Allisat <tor at wtv.net>
Subject: Re: When? (was Re: NEWDOM: Re: TODO)
Cc: Jim Fleming <JimFleming at unety.net>, root at taka.agn.net, ietf at ietf.org,
newdom at vrx.net
Source-Info: From (or Sender) name not authenticated.
Jim Fleming wrote:
> People should note carefully that some of the discussion
> on the OLD newdom does not make it to the NEW newdom
> and vice versa. This is partly because some people are not
> allowed to post to the OLD newdom list.
Bill Manning replied:
: Things are now split between the ar.net and vrx.com
: lists. The folks that seemed to cause the largest
: amount of problems on the iiia.org and ar.net are
: now attempting to socialize their beliefs in a wide
: variety of fora, generally espousing broader vision
: and more "open-ness" than is found in the regular fora
: of Internet protocols or operations types. It seems
: clear that they have near zero clue and have the
: attention span and patience of my two year old.
Bill, there's no need to resort
to insults. We have moved beyond
that. As for me personally having
"zero clue" I'd have to agree. Of
all the commentators here I have
the very least "clue". Jim, on the
other hand has plenty clue.
I am, on the other hand, the very
definition of "clueless". I don't
know a router from a rooter from a
roto-tiller. RFC's hold no religious
state for me. I don't give two hoots
for Postel/IANA. ISOC is a gang of
elitists in my opinion. Internic is
a shameless money grab without re-
demption. NSI is merely a front
organization for the NSA/CIA super
spooks behind SAIC. It's all crooked.
And in the world according to Bob,
you, Mr. Manning, are no better or
worse than the guy behind the counter
at the corner store or the streetcar
operator or me. We are all equals.
But I'm *not* your two year old!
Never forget that Bill. You and
me are the same. Equals. Respect.
Internationally Yours,
Bob Allisat tor at wtv.net
Director, (416) 588-0670
World Televirtual Network http://www.wtv.net
PO Box 191 Station E Toronto Ontario Canada M6H 4E2
Received: from ietf.org by ietf.org id aa29217; 5 Nov 96 23:26 EST
Received: from rip.psg.com by ietf.org id aa28962; 5 Nov 96 23:25 EST
Received: by rip.psg.com
id m0vKzDf-0007zeC; Tue, 5 Nov 96 20:04 PST (Smail3.1.29.1#1)
Message-Id: <m0vKzDf-0007zeC at rip.psg.com>
Date: Tue, 5 Nov 96 20:04 PST
Sender:ietf-request at ietf.org
From: Randy Bush <randy at psg.com>
To: ietf at ietf.org
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
References: <MAPI.Id.0016.00616e6172696f203631333830303044 at MAPI.to.RFC822>
BAD MSG:
<199611051314.QAA10529 at aic.net>
ource-Info: From (or Sender) name not authenticated.
While I find this whole discussion without merit, it is worth celebrating
that
> In fact, 90% of the Internet is in the U.S.A.
is quite false. This is the year that the *majority* of nodes are finally
outside the US. This is indeed worth celebrating.
We now return to the normal bickering andthe new-dumb mailing list.
randy
Received: from ietf.org by ietf.org id aa06811; 6 Nov 96 3:56 EST
Received: from bells.cs.ucl.ac.uk by ietf.org id aa06693; 6 Nov 96 3:54 EST
Received: from speedy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.06292-0 at bells.cs.ucl.ac.uk>; Wed, 6 Nov 1996 08:52:42 +0000
To: newdom at vrx.net
cc: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: Re: When? (was Re: NEWDOM: Re: TODO)
In-reply-to: Your message of "Wed, 06 Nov 1996 11:51:07 +0900." <199611060251.LAA00336 at moonsky.jp.apnic.net>
Date: Wed, 06 Nov 1996 08:52:38 +0000
Message-ID: <969.847270358 at cs.ucl.ac.uk>
Sender:ietf-request at ietf.org
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Source-Info: From (or Sender) name not authenticated.
please desist from bothering the ietf list with newdom stuff
the ietf is for internet engineering and standards,
not religion, politics and economics....(or linguistics...)
jon.
Received: from ietf.org by ietf.org id aa10348; 6 Nov 96 5:42 EST
Received: from ns.aic.net by ietf.org id aa10247; 6 Nov 96 5:39 EST
Received: by aic.net (8.7.3/8.7.3) id NAA14980; Wed, 6 Nov 1996 13:33:47 +0300 (GMT)
Message-Id: <199611061033.NAA14980 at aic.net>
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: Valdis.Kletnieks at vt.edu
Date: Wed, 6 Nov 1996 13:33:47 +0300 (GMT)
Cc: ietf at ietf.org
In-Reply-To: <199611051544.KAA06532 at black-ice.cc.vt.edu> from "Valdis.Kletnieks at vt.edu" at Nov 5, 96 10:44:51 am
Sender:ietf-request at ietf.org
From: edd at acm.org
Reply-To: edd at amnic.net
Organization: AM Network Information Center @ AIC Network Operations
X-Tel: +37 42 28 14 25
X-FAX: +37 42 28 50 82
X-InterNIC-ID: ET22
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
Dear Valdis,
> On Tue, 05 Nov 1996 16:14:43 +0300, you said:
> > These facts are enough - the official language of the Internet
> > IS the English language. This is fact.
>
> Umm.. is this "official" official, being codified in an RFC or similar, or
> merely a "de facto" official?
The second one, you know
> English is no more the "official" language of the Internet than
> Windows 95 is the "official" operating system. No matter *what*
> Bill Gates wishes were true...
Well, it seems you completely misunderstood me. First of all,
please do not mention Bill. He doesn't have anything to do here.
I hate M$ and I don't use their products at all...
About officiality - as I said, it is de facto standard, *IMHO*.
Best regards.
Edgar
Received: from ietf.org by ietf.org id aa10744; 6 Nov 96 5:45 EST
Received: from ns.aic.net by ietf.org id aa10671; 6 Nov 96 5:44 EST
Received: by aic.net (8.7.3/8.7.3) id NAA15004; Wed, 6 Nov 1996 13:41:05 +0300 (GMT)
Message-Id: <199611061041.NAA15004 at aic.net>
Subject: Re: English is it -> was: Re: The cartel begins to crumble?
To: Jorge Alejandro Oyarbide <joyarbide at txport.com>
Date: Wed, 6 Nov 1996 13:41:05 +0300 (GMT)
Cc: edd at amnic.net, Valdis.Kletnieks at vt.edu, ietf at ietf.org
In-Reply-To: <01BBCB1F.6C636AA0 at j_oyarbide.txport.com> from "Jorge Alejandro Oyarbide" at Nov 5, 96 01:44:09 pm
Sender:ietf-request at ietf.org
From: edd at acm.org
Reply-To: edd at amnic.net
Organization: AM Network Information Center @ AIC Network Operations
X-Tel: +37 42 28 14 25
X-FAX: +37 42 28 50 82
X-InterNIC-ID: ET22
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> Do we need an official language ?? Can we just go with common sense ??
Yes, yes, and yes! It seems you forgot that English ISN'T my native language?
Just for your information: my native language is in use for more than 2000
years. 2000 years ago where were no English, no Spanish (and, indeed,
no Internet :-)
Yours,
Edgar
Received: from ietf.org by ietf.org id aa11996; 6 Nov 96 6:02 EST
Received: from cnri by ietf.org id aa11729; 6 Nov 96 6:01 EST
Received: from ns.aic.net by CNRI.Reston.VA.US id aa06517; 6 Nov 96 6:00 EST
Received: by aic.net (8.7.3/8.7.3) id NAA15093; Wed, 6 Nov 1996 13:58:10 +0300 (GMT)
Message-Id: <199611061058.NAA15093 at aic.net>
Subject: Re: NON SENSE. English is the best language for this....
To: sthaug at nethelp.no
Date: Wed, 6 Nov 1996 13:58:10 +0300 (GMT)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <6491.847221471 at verdi.nethelp.no> from "sthaug at nethelp.no" at Nov 5, 96 08:17:51 pm
Sender:ietf-request at ietf.org
From: edd at acm.org
Reply-To: edd at amnic.net
Organization: AM Network Information Center @ AIC Network Operations
X-Tel: +37 42 28 14 25
X-FAX: +37 42 28 50 82
X-InterNIC-ID: ET22
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>
> > > Well, I can't agree. Internet and 99% of associated "things"
> > > originated in the US.
> >
> > >In fact, 90% of the Internet is in the U.S.A.
> >
> > Really? I wonder how that fact was derived?
>
> Certainly not by any scientific method. Even if you don't define what
> 'the Internet' includes, let's take a look at host count statistics.
Great. I was wrong in the second statement, but do you disagree with the
first one???
Seems it's better to stop this thread. I do right now.
Amenaayn bareekneer,
-edd
Received: from ietf.org by ietf.org id aa14506; 6 Nov 96 7:16 EST
Received: from cnri by ietf.org id aa14270; 6 Nov 96 7:11 EST
Received: from [131.112.32.132] by CNRI.Reston.VA.US id aa07637;
6 Nov 96 7:11 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199611061157.UAA11400 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id UAA11400; Wed, 6 Nov 1996 20:57:41 +0900
Subject: Re: NON SENSE. English is the best language for this....
To: edd at amnic.net
Date: Wed, 6 Nov 96 20:57:40 JST
Cc: sthaug at nethelp.no, ietf at CNRI.Reston.VA.US
In-Reply-To: <199611061058.NAA15093 at aic.net>; from "edd at acm.org" at Nov 6, 96 1:58 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
edd;
> > > > Well, I can't agree. Internet and 99% of associated "things"
> > > > originated in the US.
> > >
> > > >In fact, 90% of the Internet is in the U.S.A.
> > >
> > > Really? I wonder how that fact was derived?
> >
> > Certainly not by any scientific method. Even if you don't define what
> > 'the Internet' includes, let's take a look at host count statistics.
>
> Great. I was wrong in the second statement, but do you disagree with the
> first one???
Regardless of whether you are right or it's actually 70%, you
described the problem, not an excuse not to solve the problem.
Masataka Ohta
Received: from ietf.org by ietf.org id aa15634; 6 Nov 96 7:59 EST
Received: from cnri by ietf.org id aa15560; 6 Nov 96 7:57 EST
Received: from milou.inria.fr by CNRI.Reston.VA.US id aa08456; 6 Nov 96 7:57 EST
Received: by milou.inria.fr (8.7.6/8.6.12) id NAA20440; Wed, 6 Nov 1996 13:56:11 +0100 (MET)
Message-Id: <199611061256.NAA20440 at milou.inria.fr>
To: end2end-interest at isi.edu, sigcomm96ex at aland.bbn.com, sigcommex at acm.org,
ietf at CNRI.Reston.VA.US
Subject: SIGCOMM '97 Tutorials
Date: Wed, 06 Nov 1996 13:56:09 +0100
Sender:ietf-request at ietf.org
From: Walid Dabbous <Walid.Dabbous at sophia.inria.fr>
Source-Info: From (or Sender) name not authenticated.
Sorry for multiple copies...
We solicit tutorial proposals for SIGCOMM'97.
Each tutorial is intented to cover a single topic
in detail, and should be a full day in length.
There should be 4 tutorials in two tracks.
Topics of interest include but are not limited to:
Multicast (applications, transmission control, routing)
IntServ (guaranteed/controlled load services, WFQ/CBQ, RSVP)
Internet over New Media (satellite, cable, etc)
Multimedia over internet
Web/cash applications
Tutorial submissions should include an extended abstract and outline
(2-4 pages), and an indication of length, objectives and intended audience.
Proposals should be sent by e-mail asap to dabbous at sophia.inria.fr.
Submission deadline is January 31st, 1997
More information on the tutorials will be available later on the SIGCOMM'97
tutorials web page http://www.inria.fr/rodeo/sigcomm97/tutorials.html
Walid Dabbous
INRIA U.R. de Sophia Antipolis | Email : dabbous at sophia.inria.fr
2004, Route des Lucioles BP 93 | Phone : +33 4 93 65 77 18
06902 Sophia Antipolis CEDEX France | Fax : +33 4 93 65 77 65
Received: from ietf.org by ietf.org id aa17289; 6 Nov 96 8:34 EST
Received: from cnri by ietf.org id aa17222; 6 Nov 96 8:31 EST
Received: from domen.uninett.no by CNRI.Reston.VA.US id aa09064;
6 Nov 96 8:31 EST
Received: from domen.uninett.no by domen.uninett.no with SMTP (PP)
id <05135-0 at domen.uninett.no>; Wed, 6 Nov 1996 14:30:39 +0100
X-Mailer: exmh version 1.6.7 5/3/96
Sender:ietf-request at ietf.org
From: Harald.T.Alvestrand at uninett.no
To: sthaug at nethelp.no
cc: ietf at CNRI.Reston.VA.US
Subject: Re: NON SENSE. English is the best language for this....
In-reply-to: Your message of "Tue, 05 Nov 1996 20:17:51 +0100." <6491.847221471 at verdi.nethelp.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 06 Nov 1996 14:30:36 +0100
Message-ID: <5132.847287036 at domen.uninett.no>
X-Orig-Sender: Harald.T.Alvestrand at uninett.no
Source-Info: From (or Sender) name not authenticated.
If we add up the .com, .net, .edu, .mil, .gov, .org and .us domains,
we get 8.224.279 out of the 12.880.699 hosts counted by Network Wizards.
That is 64 percent.
I've heard estimates that up to 20% of all .com hosts are outside
the US, and wouldn't care even to guess about the proportion under .net
(in some countries, orgs register under .net because they don't like
the policy of the country-domain admin. What fun!)
If we assumed that 20% of .com and .net were outside the US, we would
get 911.309 more non-US hosts, giving 56% of the Internet left inside
the United States.
I don't have a number for non-US people writing RFCs, but have heard
a guesstimate of one fifth.
One fact beats 20 guesses...
harald A
Received: from ietf.org by ietf.org id aa22484; 6 Nov 96 9:45 EST
Received: from localhost by ietf.org id aa20705; 6 Nov 96 9:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-claffy-icp-v2-00.txt
Date: Wed, 06 Nov 1996 09:37:31 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611060937.aa20705 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Cache Protocol (ICP), version 2
Author(s) : D. Wessels, K. Claffy
Filename : draft-claffy-icp-v2-00.txt
Pages : 7
Date : 11/05/1996
This draft document describes the Internet Cache Protocol (ICP) currently
implemented in a few World-Wide Web proxy cache packages. ICP was
initially developed by Peter Danzig, et. al. at the Univerisity of Southern
California. It evolved as an important part of hierarchical caching on the
Harvest research project.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-claffy-icp-v2-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-claffy-icp-v2-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-claffy-icp-v2-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961105100913.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-claffy-icp-v2-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-claffy-icp-v2-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961105100913.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22481; 6 Nov 96 9:45 EST
Received: from localhost by ietf.org id aa20947; 6 Nov 96 9:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-macker-mdp-framework-00.txt
Date: Wed, 06 Nov 1996 09:37:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611060937.aa20947 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Multicast Dissemination Protocol (MDP) Framework
Author(s) : J. Macker, W. Dang
Filename : draft-macker-mdp-framework-00.txt
Pages : 14
Date : 11/05/1996
This document outlines a simple protocol framework for reliable multicast
dissemination of data files. The general framework was originally developed
and used by the Image Multicaster (IMM) application within the Internet
MBone for dissemination of satellite imagery. This document describes the
potential for more general use of the protocol framework, its operational
modes, some performance issues, and the basic application data units (ADUs)
presently used. This is not intended to be a detailed protocol
specification document, but rather a broad description of the basic
architectural approach. Further detailed description of the protocol
implementation may be provided in future documents.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-macker-mdp-framework-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-macker-mdp-framework-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-macker-mdp-framework-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961105174324.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-macker-mdp-framework-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-macker-mdp-framework-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961105174324.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22483; 6 Nov 96 9:45 EST
Received: from localhost by ietf.org id aa20897; 6 Nov 96 9:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-lyon-itp-nodes-00.txt
Date: Wed, 06 Nov 1996 09:37:47 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611060937.aa20897 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Transaction Internet Protocol
Author(s) : J. Lyon
Filename : draft-lyon-itp-nodes-00.txt
Pages : 12
Date : 11/05/1996
In many applications where different nodes cooperate on some work, there is
a need to guarantee that the work happens atomically. that is, each node
must reach the same conclusion as to whether the work is to be completed,
even in the face of failures. This document proposes a simple,
easily-implemented protocol for achieving this end.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-lyon-itp-nodes-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-lyon-itp-nodes-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-lyon-itp-nodes-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961105102740.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-lyon-itp-nodes-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-lyon-itp-nodes-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961105102740.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22482; 6 Nov 96 9:45 EST
Received: from localhost by ietf.org id aa20775; 6 Nov 96 9:37 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-martins-ilps-00.txt
Date: Wed, 06 Nov 1996 09:37:36 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611060937.aa20775 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Internet Location Path System (ILPS)
Author(s) : L. Martins
Filename : draft-martins-ilps-00.txt
Pages : 6
Date : 11/05/1996
This document presents a new, uniform method of mapping IP addresses,
service identifiers and service-specific info. It does the ame work that is
done by DNS and URLs. I realize this would be extremally hard to implement,
as there is already an immense working base of DNS, but the idea provides
so much benefits that I thought I did not have the right not to post it (so
maybe the URN folks use it for something).
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-martins-ilps-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-martins-ilps-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-martins-ilps-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961105101506.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-martins-ilps-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-martins-ilps-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961105101506.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25528; 6 Nov 96 10:20 EST
Received: from ng.netgate.net by ietf.org id aa25340; 6 Nov 96 10:17 EST
Received: from [205.214.160.103] (d34.netgate.net [205.214.160.68]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id HAA24571; Wed, 6 Nov 1996 07:26:15 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v0310060caea5de7c5722 at [205.214.160.103]>
In-Reply-To: <199611060251.LAA00336 at moonsky.jp.apnic.net>
References: Your message of "Tue, 05 Nov 1996 13:29:41 CST."
<01BBCB1D.674229A0 at webster.unety.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 5 Nov 1996 22:20:17 -0800
To: "David R. Conrad" <davidc at apnic.net>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: When? (was Re: NEWDOM: Re: TODO)
Cc: Jim Fleming <JimFleming at unety.net>,
'System Administrator' <root at taka.agn.net>,
"'ietf at ietf.org'" <ietf at ietf.org>, 'New Newdom' <newdom at vrx.net>,
davidc at apnic.net
Source-Info: From (or Sender) name not authenticated.
At 6:51 PM -0800 11/5/96, David R. Conrad wrote:
>Finally, given that multiple mailing lists exist for discussions on
>DNS and TLD related issues, can we PLEASE not spam the IETF list with
>newdom gunk (note reply-to)?
David, I'm on the IAHC and want to try to track all the relevant
mailing lists. Should I subscribe to both newdom lists?
Thanks.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa27204; 6 Nov 96 10:31 EST
Received: from localhost by ietf.org id aa26430; 6 Nov 96 10:25 EST
To: IETF-Announce: ;
Subject: WG ACTION: Application Configuration Access Protocol (acap)
Date: Wed, 06 Nov 1996 10:25:36 -0500
Sender:ietf-announce-request at ietf.org
From: Cynthia Clark <cclark at ietf.org>
Message-ID: <9611061025.aa26430 at ietf.org>
A new working group has been formed in the Applications Area
of the IETF. For additional information, contact the Area Directors or
the WG Chair.
Application Configuration Access Protocol (acap)
------------------------------------------------
Chair(s):
Chris Newman <chris.newman at innosoft.com>
Applications Area Director(s):
Keith Moore <moore+iesg at cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Mailing lists:
General Discussion:ietf-acap+ at andrew.cmu.edu
To Subscribe: ietf-acap-request+ at andrew.cmu.edu
Archive: anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap
Description of Working Group:
The goal of this working group is to define, specify, and develop the
Application Configuration Access Protocol as a general access mechanism
for per-user and per-server structured lists of information. In
addition, the Working Group will specify how to use the protocol to
store specific structured lists, initially application configuration
options and addressbooks.
The Application Configuration Access Protocol is a proposed solution to
the problems of client configuration for users of the internet.
Given the increasing prevalence of network access points and rapidly
increasing numbers of users with diverse needs and settings, there is a
phenomenon of internet application users who typically connect from
more than one physical location and/or operating system to use the same
set of internet services and applications. These users must recreate
sets of personal configuration information for each system, session,
and location that they use. This may include information such as
application options and preferences; personal or shared user data such
as addressbooks, bookmarks, or subscription lists; or shared data for
internal client use, such as authorization group lists.
The products of this working group will be:
* a formal specification for the protocol
* formal specifications of datasets used by the protocol and related
extensions to the protocol
* an RFC intended to move to a Standard in a timely manner
* a specification for extensibility of the protocol in the form of a
framework document
* additional informational and/or experimental RFCs as necessary to
amplify and/or extend ACAP.
Note on goals and milestones: because the work of the ACAP WG is based
on the previous work done on IMSP, there is justification for a
somewhat more aggressive schedule than is customary.
Goals and Milestones:
Jul 96 Submission of "ACAP vs. Other Protocols" Informational Document
for discussion
Sep 96 Submission of revised proposed WG charter to area directors
Sep 96 Submission of "ACAP vs. Other Protocols" as Internet Draft
Oct 96 Second internet-draft of ACAP protocol specification
Dec 96 working group meeting at San Jose IETF
Jan 97 Working implementations of client and server library
Feb 97 Final internet-draft of ACAP protocol submitted to IESG for
consideration as Proposed Standard
Mar 97 Additional dataset specifications defined as directed by WG.
Received: from ietf.org by ietf.org id aa03762; 6 Nov 96 12:25 EST
Received: from doorstep.unety.net by ietf.org id aa03629; 6 Nov 96 12:22 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA19494; Wed, 6 Nov 1996 11:16:12 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCBD4.2C2750E0 at webster.unety.net>; Wed, 6 Nov 1996 11:18:01 -0600
Message-ID: <01BBCBD4.2C2750E0 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Dave Crocker' <dcrocker at brandenburg.com>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>
Subject: IAHC
Date: Wed, 6 Nov 1996 11:18:00 -0600
Encoding: 71 TEXT
Source-Info: From (or Sender) name not authenticated.
On Wednesday, November 06, 1996 12:20 AM, Dave Crocker[SMTP:dcrocker at brandenburg.com] wrote:
@ At 6:51 PM -0800 11/5/96, David R. Conrad wrote:
@ >Finally, given that multiple mailing lists exist for discussions on
@ >DNS and TLD related issues, can we PLEASE not spam the IETF list with
@ >newdom gunk (note reply-to)?
@
@David, I'm on the IAHC and want to try to track all the relevant
@ mailing lists. Should I subscribe to both newdom lists?
@
David,
According to the following, the IAHC is going to have 9 members.
Have all of those members been appointed yet...?
If so, can you tell everyone who they are and who made the
appointments...?
@@@@ http://www.isoc.org/whatsnew/iahc.html
"The IAHC will be composed of representatives of the large
international Internet community. The International Telecommunication
Union (ITU), the World Intellectual Property Organization
(WIPO), and the International Trademark Association (INTA) will
designate one each. ISOC, IANA, and the Internet Architecture
Board (IAB) will each appoint two members for a total of nine."
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Also,
According to <http://info.isoc.org/whatsnew/itlds.html>
"The IAHC will work in an open electronic forum soliciting advice,
comments, and counsel from a wide array of interested parties."
Can you explain where the IAHC is holding discussions...?
Was there a meeting in Washington, D.C. this week...?
If so, are the meeting notes on line...?
Also,
According to the following schedule, the formation of the IAHC
triggers the establishment of "Day 1".
Can you explain when Day 1 occurred...?...(if it did)
@@@@ http://info.isoc.org/whatsnew/itlds.html
Schedule of Events
Day 1IAHC formed
Day 30IAHC finalizes procedures and publicly announces
Day 31Begin accepting applications
Day 90Acceptance of applications ceases
Day 135IAHC announces registry selection and iTLDs
Day 136ISOC begins contracting with selected registries
Day XISOC notifies IANA that contract is complete
Day X + 1IANA introduces new iTLDs to root zone file
Day X + 90Registry begins operations
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa08329; 6 Nov 96 15:02 EST
Received: from typhoon.dial.pipex.net by ietf.org id aa07854; 6 Nov 96 14:58 EST
Received: from Unknown by typhoon.dial.pipex.net (8.8.2/)
id TAA06910; Wed, 6 Nov 1996 19:56:32 GMT
Message-Id: <199611061956.TAA06910 at typhoon.dial.pipex.net>
Comments: Authenticated sender is <fp65 at pop.dial.pipex.com>
Sender:ietf-request at ietf.org
From: dzshobrook at dial.pipex.com
To: ietf at ietf.org
Date: Mon, 4 Nov 1996 20:49:06 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.40)
Source-Info: From (or Sender) name not authenticated.
unsubscribe fp65 at dial.pipex.com
Received: from ietf.org by ietf.org id aa08323; 6 Nov 96 15:02 EST
Received: from typhoon.dial.pipex.net by ietf.org id aa07871; 6 Nov 96 14:58 EST
Received: from Unknown by typhoon.dial.pipex.net (8.8.2/)
id TAA06964; Wed, 6 Nov 1996 19:56:38 GMT
Message-Id: <199611061956.TAA06964 at typhoon.dial.pipex.net>
Comments: Authenticated sender is <fp65 at pop.dial.pipex.com>
Sender:ietf-request at ietf.org
From: dzshobrook at dial.pipex.com
To: ietf at ietf.org
Date: Mon, 4 Nov 1996 20:49:06 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.40)
Source-Info: From (or Sender) name not authenticated.
unsubscribe dzshobrook at dial.pipex.com
Received: from ietf.org by ietf.org id aa09200; 6 Nov 96 15:20 EST
Received: from ns1.vrx.net by ietf.org id aa09061; 6 Nov 96 15:18 EST
Received: from C109.reach.net (C109.reach.net [204.50.58.141]) by ns1.vrx.net (8.7.5/8.6.9) with SMTP id PAA10950; Wed, 6 Nov 1996 15:16:36 -0500 (EST)
Date: Wed, 6 Nov 1996 15:16:36 -0500 (EST)
Message-Id: <199611062016.PAA10950 at ns1.vrx.net>
X-Sender: alterrich at vrx.net
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Bill Manning <bmanning at isi.edu>
Sender:ietf-request at ietf.org
From: "Richard J. Sexton" <richard at Alter.NIC>
Subject: Re: When? (was Re: NEWDOM: Re: TODO)
Cc: ietf at ietf.org, newdom at vrx.net
Source-Info: From (or Sender) name not authenticated.
At 06:45 PM 11/5/96 -0800, you wrote:
>> People should note carefully that some of the discussion
>> on the OLD newdom does not make it to the NEW newdom
>> and vice versa. This is partly because some people are not
>> allowed to post to the OLD newdom list.
>>
>
>As Jim clearly points out, there is more than
>one mailing list labeled "newdom". It seems
>his current favorite is the one hosted from
>vrx.com.
Thats actualy vrx.NET, Bill, ALthough it might work if you type .com,
I recall going to a bit of effort to help the fumble fingered.
> The original was hosted from iiia.org
>until the list owner shut it down due to perceived
>threats of legal action from some members of
>said list.
I agree with this.
>
>The main thrust of the list then moved to ar.net,
>where things went along just fine, until some of
>the same set of people apparently became disruptive
>enough that they were expelled.
Allisat and Fleming were expell. I quit out of disgust.
>Things are now split between the ar.net and vrx.com
>lists. The folks that seemed to cause the largest
>amount of problems on the iiia.org and ar.net are
>now attempting to socialize their beliefs in a wide
>variety of fora, generally espousing broader vision
>and more "open-ness" than is found in the regular fora
>of Internet protocols or operations types. It seems
>clear that they have near zero clue and have the
>attention span and patience of my two year old.
>
>--bill
Not the way I saw it.
After Allisat, Fleming and I left, Fleming kept mailing about 5
poeple; I set up newdom at vrx instead of havig to reply and cc
all those poeple. Oddly, it proved popular, and to my great
surprise, the poeple kicked of newdom at ar.com seemed to be the
ones that people wanted to read. About a week or so ago, RIck
Wesson sent either me of Fleming mail sugegsting he may as well
shut down his list.
Are you really complaining about "too much open-ness" in your
parapgraph above, Bill?
--
Richard J. Sexton
richard at Alter.NIC
Received: from ietf.org by ietf.org id aa09900; 6 Nov 96 15:26 EST
Received: from zephyr.isi.edu by ietf.org id aa09279; 6 Nov 96 15:21 EST
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA11084>; Wed, 6 Nov 1996 12:20:17 -0800
Message-Id: <199611062020.AA11084 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2039 on WWW Track MIBs
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 06 Nov 96 12:20:16 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2039:
Title: Applicablity of Standards Track MIBs to Management
of World Wide Web Servers
Author: C. Kalbfleisch
Date: November 1996
Mailbox: cwk at onramp.net
Pages: 14
Characters: 31,966
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2039.txt
Requirements for management of a World Wide Web (WWW) server are
presented. The applicable existing standards track MIBs are then
examined. Finally, an analysis of the additional groups of MIB
attributes that are needed to meet the requirements is presented.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961106121513.RFC at ISI.EDU>
SEND /rfc/rfc2039.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2039.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961106121513.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17068; 6 Nov 96 18:56 EST
Received: from nsipo.arc.nasa.gov by ietf.org id aa16792; 6 Nov 96 18:50 EST
Received: Wed, 6 Nov 1996 15:48:48 -0800 (PST) from localhost (RFC1413 sender feinler at localhost) by nsipo.arc.nasa.gov (8.7.1/1.5) id PAA12758
Date: Wed, 6 Nov 1996 15:48:47 -0800 (PST)
Sender:ietf-request at ietf.org
From: Jake Feinler <feinler at nsipo.arc.nasa.gov>
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
cc: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>, ietf at ietf.org
Subject: Re: The cartel begins to crumble?
In-Reply-To: <199610310251.LAA11198 at necom830.hpcl.titech.ac.jp>
Message-ID: <Pine.SUN.3.95.961106142821.6479J-100000 at nsipo.arc.nasa.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Having been the originator of the idea of .com, .edu, .gov, .mil, etc I
have been watching this discussion with some amusement.
I can only say to those whose first language is not English that you are
not alone in feeling some trepidation. I feel great sympathy for ** ANY**
speakers who are willing to step up to the microphone in IETF meetings,
especially if the topic is naming and addressing! That is not an
exercise for the faint of heart.
In the heat of battle and the exchange of ideas, it behooves us all to
remember that we are engaged in an international discussion among peers
and be a little kinder and gentler with each other. As this discussion is
pointing out, what is satire in one background can be insult in another.
Also I might point out that the naming system has held up reasonably well
over several years because of the many ideas and heated discussions that
led to a workable consensus. My suggestion would be to continue this
process of evolution of the naming system until better solutions are
found, and go easy on flames and bashing. IETF is not perfect in its
approach to problem solving, but hey, it's held up as a viable open
technical forum for more than 20 years (thanks to the dedication of many)
and has produced the phenomenon of the Internet, so has to be doing
something right. If you have good ideas get them in there...global
feedback and concensus are what have made the Internet great...it's a
chaotic democracy not a cartel conspiracy.
Signed,
Tattered but still unfurled
Jake Feinler
P.S. These are my own musings and do not represent any organizations with
which I am now or have been affiliated.
On Thu, 31 Oct 1996, Masataka Ohta wrote:
> Brian;
>
> > Just in case my words in French were misinterpreted -
>
> No. As I replied in Japanese, that was fine.
>
> > Having worked for 20 years about half in my native
> > language and half in a foreign language, I feel great
> > sympathy for non-English speakers who are willing
> > to step up to the microphone in IETF meetings.
>
> You are wrong.
>
> We are OK.
>
> You should and I do feel sympathy for those who can't step up to the
> microphone in IETF meetings even though they are there and have
> their own opinion.
>
>Masataka Ohta
>
Received: from ietf.org by ietf.org id aa18981; 6 Nov 96 20:01 EST
Received: from borax.Stanford.EDU by ietf.org id aa18749; 6 Nov 96 19:56 EST
Received: from macii-morgan.stanford.edu (macii-morgan.Stanford.EDU [36.53.0.167]) by borax.stanford.edu (8.7.5/8.7.3) with SMTP id QAA19739; Wed, 6 Nov 1996 16:55:21 -0800 (PST)
Date: Wed, 6 Nov 96 16:55:28 -0800
Sender:ietf-request at ietf.org
From: RL Bob Morgan <Bob.Morgan at stanford.edu>
To: Simon Spero <ses at tipper.oit.unc.edu>
Subject: Re: Carpools and Cartels
Cc: ietf at ietf.org
Message-ID: <Mailstrom.1.06.29568.15007.morgan at networking.stanford.edu>
In-Reply-To: Your message
<Pine.SUN.3.91.961101182619.10489A-100000 at tipper.oit.unc.edu> of Fri, 1 Nov
1996 18:33:36 -0500 (EST)
Content-Type: TEXT/plain; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> [Never one to miss the opportunity for a segue, Are
> there any carpools going from SF to San Jose during the IETF?]
If you're going from San Francisco or thereabouts to San Jose for the IETF
meeting, I recommend CalTrain. $4.75 one-way SF to SJ. More info should be at
http://server.berkeley.edu/Transit/Carriers/CalTrain (which unfortunately
doesn't seem to be up right at this moment). It's a 10-15 minute walk to the
Fairmont, or there are buses.
- RL "Bob" Morgan
Stanford
Received: from ietf.org by ietf.org id aa20685; 6 Nov 96 21:00 EST
Received: from tipper.oit.unc.edu by ietf.org id aa20564; 6 Nov 96 20:57 EST
Received: from hilly.oit.unc.edu (ppp6.mcnc.org [128.109.64.16]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id UAA09676; Wed, 6 Nov 1996 20:55:50 -0500
Message-Id: <1.5.4.32.19961107015503.0067a168 at tipper.oit.unc.edu>
X-Sender: ses at tipper.oit.unc.edu
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 06 Nov 1996 20:55:03 -0500
To: RL Bob Morgan <Bob.Morgan at stanford.edu>
Sender:ietf-request at ietf.org
From: Simon E Spero <ses at tipper.oit.unc.edu>
Subject: Re: Carpools and Cartels
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 04:55 PM 11/6/96 -0800, RL "Bob" Morgan wrote:
>If you're going from San Francisco or thereabouts to San Jose for the IETF
>meeting, I recommend CalTrain. $4.75 one-way SF to SJ. More info should be at
>http://server.berkeley.edu/Transit/Carriers/CalTrain (which unfortunately
>doesn't seem to be up right at this moment). It's a 10-15 minute walk to the
>Fairmont, or there are buses.
Yeah (this past year I was living in Mtn View about 20 yards from the
Caltrain line; some nights I can hear it still :-) Trouble is it stops
running a bit too early for IETF hours :-)
Simon
Received: from ietf.org by ietf.org id aa22707; 6 Nov 96 22:15 EST
Received: from cnri by ietf.org id aa22485; 6 Nov 96 22:11 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa29916;
6 Nov 96 22:11 EST
Received: from engine3.dnet.net.id by venera.isi.edu (5.65c/5.61+local-25)
id <AA05464>; Wed, 6 Nov 1996 19:10:51 -0800
Received: from NETwork.dnet.net.id ([202.148.1.203]) by engine3.dnet.net.id
(post.office MTA v1.9.3 ID# 0-13255) with ESMTP id AAA29915
for <ietf at isi.edu>; Thu, 7 Nov 1996 10:11:48 +0000
Sender:ietf-request at ietf.org
From: Rachmat Kosasih <rk at dnet.net.id>
To: ietf at isi.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject:
Date: Thu, 7 Nov 1996 10:13:36 -0000
X-Msmail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: <19961107101148.AAA29915 at NETwork.dnet.net.id>
Source-Info: From (or Sender) name not authenticated.
unsubscribe comsoc-conferences ietf at isi.edu
__________________________________________________________
Rachmat Kosasih Dyviacom Intrabumi,p.t.
Network Engineer Menara Mulia lt.11 Suite 1108
ph: +62-21-525-7520 Jl. Jend. Gatot Soebroto Kav 9 - 11
fx: +62-21-525-7634 Jakarta - 12930
mailto:rk at dnet.net.id Indonesia
__________________________________________________________
Received: from ietf.org by ietf.org id aa29960; 6 Nov 96 23:15 EST
Received: from Kitten.mcs.com by ietf.org id aa29684; 6 Nov 96 23:10 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id WAA08482; Wed, 6 Nov 1996 22:09:51 -0600 (CST)
Received: from Jupiter.Mcs.Net (karl at Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id WAA15808; Wed, 6 Nov 1996 22:09:45 -0600 (CST)
Received: (from karl at localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id WAA28072; Wed, 6 Nov 1996 22:09:45 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611070409.WAA28072 at Jupiter.Mcs.Net>
Subject: Re: Carpools and Cartels
To: RL Bob Morgan <Bob.Morgan at stanford.edu>
Date: Wed, 6 Nov 1996 22:09:44 -0600 (CST)
Cc: ses at tipper.oit.unc.edu, ietf at ietf.org
In-Reply-To: <Mailstrom.1.06.29568.15007.morgan at networking.stanford.edu> from "RL Bob Morgan" at Nov 6, 96 04:55:28 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
>
>
> > [Never one to miss the opportunity for a segue, Are
> > there any carpools going from SF to San Jose during the IETF?]
>
> If you're going from San Francisco or thereabouts to San Jose for the IETF
> meeting, I recommend CalTrain. $4.75 one-way SF to SJ. More info should be at
> http://server.berkeley.edu/Transit/Carriers/CalTrain (which unfortunately
> doesn't seem to be up right at this moment). It's a 10-15 minute walk to the
> Fairmont, or there are buses.
>
> - RL "Bob" Morgan
> Stanford
Is there a canonical source for info on the SJ IETF meeting (hotels, etc)?
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa00969; 6 Nov 96 23:35 EST
Received: from newdev.harvard.edu by ietf.org id aa00846; 6 Nov 96 23:30 EST
Received: (from sob at localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id XAA00652; Wed, 6 Nov 1996 23:27:57 -0500 (EST)
Date: Wed, 6 Nov 1996 23:27:57 -0500 (EST)
Sender:ietf-request at ietf.org
From: Scott Bradner <sob at newdev.harvard.edu>
Message-Id: <199611070427.XAA00652 at newdev.harvard.edu>
To: Bob.Morgan at stanford.edu, karl at mcs.net
Subject: Re: Carpools and Cartels
Cc: ietf at ietf.org, ses at tipper.oit.unc.edu
Source-Info: From (or Sender) name not authenticated.
> Is there a canonical source for info on the SJ IETF meeting (hotels, etc)?
http://www.ietf.org
its all there under "meetings"
Scott
Received: from ietf.org by ietf.org id aa06154; 7 Nov 96 1:09 EST
Received: from vm.biu.ac.il by ietf.org id aa06086; 7 Nov 96 1:06 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0797; Thu, 07 Nov 96 08:04:25 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1207; Thu, 7 Nov 1996 08:02:53 +0200
Date: Thu, 07 Nov 96 07:59:34 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Test
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070106.aa06086 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Plz ignore.
Received: from ietf.org by ietf.org id aa09825; 7 Nov 96 4:23 EST
Received: from vm.biu.ac.il by ietf.org id aa09728; 7 Nov 96 4:19 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0959; Thu, 07 Nov 96 11:17:40 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1924; Thu, 7 Nov 1996 11:17:40 +0200
Date: Thu, 07 Nov 96 11:16:55 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: RE: The cartel begins to crumble?
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070420.aa09728 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <199611020034.SAA15592 at Jupiter.Mcs.Net>, karl at mcs.net (Karl
Denninger) says:
> 2. Limits would be applied to the number of "new" registrations and
> organization could get within a window of time, to avoid registration
> stuffing.
ISPs act on behalf of their clients. They register dozens of DNs
per day. How do we handle the ISPs and PSPs? I work for IBM Israel
which as a number of PSPs that it services. As soon as they talk to
a client, that day they submit the request for cola.co.il (after
they talk to Pepsi) or for jeans.co.il (after they talk to Levi's).
There is *no* way to verify whether indeed they have an actual
client behind them with such a domain. We have seen PSPs request 30
DNs a day with just names out of the air.
You cannot limit a company from doing registrations - either
timewise of amountwise. This is their business and you can't
make artifical rules to slow them down.
The way out of this is to eliminate the ability to trade in DNs. If
the rule was that a DN is not transferrable, then there would be
no value to doing a large DN grab. See the Israeli DN policy
at www.isoc.org.il If we find that a company trades in DNs, they
lose all existing DNs.
>Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
>http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
> | 23 Analog Prefixes, 13 ISDN, Web servers $75/mo
>Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
>Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Hank Nussbacher
Israel
[the views expressed above are solely my own].
Received: from ietf.org by ietf.org id aa09905; 7 Nov 96 4:23 EST
Received: from vm.biu.ac.il by ietf.org id aa09775; 7 Nov 96 4:21 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0960; Thu, 07 Nov 96 11:19:02 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1926; Thu, 7 Nov 1996 11:19:02 +0200
Date: Thu, 07 Nov 96 11:18:40 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Re: Evaluating TLD proposal
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070423.aa09775 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <2159.wsimpson at greendragon.com>, wsimpson at greendragon.com (William
Allen Simpson) says:
>Denninger also raises the valid point that the proposed fees and such
>for the new registries do not apply to the existing registries. That is
>excrable. If the IANA is to be supported by fees, then the largest
>existing load should start right out by paying its fair share!
Speaking only for myself, as only one member of the IAHC, I will
work to make sure that any annual fees (if any) get applied across
the board and not just to new TLDs.
>I also have raised the issue in the past that this fee structure is not
>the best we could devise. What is the purpose of an "application fee"?
>Why have both a quarterly/yearly fee, and a percentage fee?
>
>Instead, I have recommended that the applicant post a "performance
>bond". As in other corporate contracts, this bond would be used to pay
>for rebidding and conversion to another contractor in the event that the
>initial contractor defaults. It could earn interest. It could be
>refundable at the termination of a successful contract.
>
>And I would make the quarterly fee entirely based on the number of
>domain registrants. As noted, this is relatively simple to verify. It
>makes more sense than administering 2 fees, one fixed and one variable,
>or worrying about percentages.
I initially agreed with you but over the weekend I thought about it
and came to the conclusion that annual or quarterly fees is not a
good idea. Scenerio: Company ABC gets the .inc domain. They run for a
year and have 10,000 DNs. The IAHC fee per domain would be $1 per DN
per year (just a number off the top of my head) and ABC gets billed
$10K. One month later no money. Second bill goes out. No money two
months later. Finally ABC lets it be known that it has no intention
of paying the yearly fee and has spoken to almost all his customers
and if their compname.inc disappears they (the individual companies)
would sue IAC/ISOC/IETF/ITU/etc. I do not see the IAHC getting into
a game of road-chicken to see who would blink first.
This is but one scenerio. Having to collect a yearly fee may not be
the wisest move. But that remains to be seen.
>
>This fee would be changed yearly to reflect the needed funds for the
>IANA and IETF Secretariate. I would not use any fee to directly fund
>root name servers, which for engineering reasons should be located at
>(and funded by) the major topological exchanges as they are built.
I would fund the root namservers located at the NAPs. The NAP is
a commercial operation but the service itself of a root DNS is not.
Again, I can be convinced otherwise if you can come up with good
reasons why not to fund roots with the new TLD funds.
>
>WSimpson at UMich.edu
> Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
>BSimpson at MorningStar.com
> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Hank Nussbacher
Israel
Received: from ietf.org by ietf.org id aa10418; 7 Nov 96 4:26 EST
Received: from vm.biu.ac.il by ietf.org id aa09875; 7 Nov 96 4:23 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0962; Thu, 07 Nov 96 11:20:10 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1930; Thu, 7 Nov 1996 11:20:11 +0200
Date: Thu, 07 Nov 96 11:19:43 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Re: The cartel begins to crumble?
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070426.aa09875 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <199611020034.SAA15592 at Jupiter.Mcs.Net>, karl at mcs.net (Karl
Denninger) says:
>The non-portable address problem has caused some of our incoming customers
>REAL headaches. We have had people who just can't change providers BECAUSE
>we can't route those addresses from 207.x.x.x, and nothing we can do fixes
>this problem for them. They're screwed, absolutely and completely, and some
>of them went out and did really crazy things (like embedding some of these
>addresses into remote devices which are then shipped to offices around the
>US, etc).
>
>Changing providers could be a $100,000+ event for these people. Yet we, as
>providers, are asked to "accept" this tying arrangement (frankly, I think it
>stinks -- but that's another thread.)
PIX. That is your solution. Cisco sells it and solves all your
address translation problems for far less than $100K. I do not
work for Cisco.
>Zones are transferrable. Its easily arguable that this is a self-healing
>problem to a large extent. A dead registry is going to be a tangible, and
>valuable, asset (assuming it has registrants in it -- if not the entire
>discussion is moot and irrelavent).
Company A sells DNs in their new .biz domain for a $200 one time
fee (forever). Three years later they go bankrupt. Company B
comes along and is willing to take over the .biz domain but
cannot charge any existing customers since they have a piece of
paper stating that their domain is cost free forever.
An orphaned registry is only valuable if it has enough critical
mass and many paying customers.
>Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
Hank Nussbacher
Israel
Received: from ietf.org by ietf.org id aa10547; 7 Nov 96 4:27 EST
Received: from vm.biu.ac.il by ietf.org id aa10301; 7 Nov 96 4:26 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0963; Thu, 07 Nov 96 11:21:15 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1932; Thu, 7 Nov 1996 11:21:15 +0200
Date: Thu, 07 Nov 96 11:20:58 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Re: IAHC
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070426.aa10301 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <199611012302.RAA13532 at Jupiter.Mcs.Net>, karl at mcs.net (Karl
Denninger) says:
>And you get to define what the namespace of "The Internet" is, right?
>
>Or, more correctly, the IANA gets to define it?
Disclaimer: I speak only for myself and am a member of the newly formed
IAHC which will hopefully resolve this issue.
I think the IANA has backed out of this so you have nothing to fear. It
is now in the hands of a committee made up of people from ISOC, IETF,
ITU, INTA, WIPA and what-have-you. The IANA has a minority voice.
So just give us a bit of time, some good input and we will have the new
iTLDs awarded in no time.
>Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
Hank Nussbacher
Israel
Received: from ietf.org by ietf.org id aa10630; 7 Nov 96 4:28 EST
Received: from vm.biu.ac.il by ietf.org id aa10502; 7 Nov 96 4:27 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0964; Thu, 07 Nov 96 11:22:23 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1934; Thu, 7 Nov 1996 11:22:23 +0200
Date: Thu, 07 Nov 96 11:21:54 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Re: More iTLD thread
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070428.aa10502 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <01BBC802.B4CACCE0 at webster.unety.net>, JimFleming at unety.net (Jim
Fleming) says:
>In my opinion, I do not think that the NASA server should even be in
>the set of "popular" root name servers because of the following reasons.
> 1. As you have shown, it is not accessible.
> 2. It is in North America, and more International coverage should
> be encouraged.
> 3. It is funded by U.S. taxpayers and as people have seen recently
> as well as during the past few years, the U.S. Government
> (mostly via the NSF) wants the Internet infrastructure to be
> shifted to the commercial sector. Root name servers should
> be no exception.
Total agreement. The root nameservers should be funded via money
raised in establishing any new iTLDs. That includes hardware, software
and manpower to run a true root nameserver. There should be 4-5 in
Europe, 2-3 in the Far East and about 6-7 in North America all funded
via new iTLDs.
>
>Many people feel that the U.S.-centric attitudes of Internet Infrastructure
>administration need to be down played and more emphasis needs to be
>placed on the International nature of the Internet. One of the major complaints
>that some people reported from a recent Harvard conference was a lack
>of participation from the International community.
As a former American who moved to Israel 15 years ago I have to agree
with you. Americans are very geo-centric and have a hard time understanding
the mentalities of other countries.
>--
>Jim Fleming
>UNETY Systems, Inc.
>Naperville, IL
Hank Nussbacher
Israel
Received: from ietf.org by ietf.org id aa10876; 7 Nov 96 4:29 EST
Received: from vm.biu.ac.il by ietf.org id aa10607; 7 Nov 96 4:29 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0965; Thu, 07 Nov 96 11:23:24 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1936; Thu, 7 Nov 1996 11:23:24 +0200
Date: Thu, 07 Nov 96 11:22:57 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Re: The cartel begins to crumble?
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070429.aa10607 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <199610310251.LAA11198 at necom830.hpcl.titech.ac.jp>,
mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) says:
>You should and I do feel sympathy for those who can't step up to the
>microphone in IETF meetings even though they are there and have
>their own opinion.
Speaking at a microphone at an IETF does not set a standard. Helping
draft an RFC via email and being able to take the time to reply
clearly, slowly and thoughtfully, even if it takes you 3x times
as long as a native English speakers, is the ulminate equalizer.
Only the loudest people grab the mike. There are many native
English speakers who are in the same boat as you.
>
> Masataka Ohta
Hank Nussbacher
Received: from ietf.org by ietf.org id aa11076; 7 Nov 96 4:33 EST
Received: from vm.biu.ac.il by ietf.org id aa10954; 7 Nov 96 4:32 EST
Received: from VM.BIU.AC.IL by VM.BIU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 0968; Thu, 07 Nov 96 11:29:19 IDT
Received: from VM.BIU.AC.IL (NJE origin HANK at BARILVM) by VM.BIU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 1942; Thu, 7 Nov 1996 11:29:19 +0200
Date: Thu, 07 Nov 96 11:28:29 IDT
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.biu.ac.il>
Subject: Re: IAHC
To: ietf at ietf.org
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611070432.aa10954 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
>According to the following, the IAHC is going to have 9 members.
>Have all of those members been appointed yet...?
Yes.
>
>If so, can you tell everyone who they are and who made the
>appointments...?
A press release will be issued this week.
>
>@@@@ http://www.isoc.org/whatsnew/iahc.html
>
>"The IAHC will be composed of representatives of the large
>international Internet community. The International Telecommunication
>Union (ITU), the World Intellectual Property Organization
>(WIPO), and the International Trademark Association (INTA) will
>designate one each. ISOC, IANA, and the Internet Architecture
>Board (IAB) will each appoint two members for a total of nine."
Here you have the answer to your 2nd question as to who made
the appointments.
>
>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
>Also,
>
>According to <http://info.isoc.org/whatsnew/itlds.html>
>"The IAHC will work in an open electronic forum soliciting advice,
>comments, and counsel from a wide array of interested parties."
>
>Can you explain where the IAHC is holding discussions...?
A new list will be out there hopefully within a few days.
>
>Was there a meeting in Washington, D.C. this week...?
Yes.
> If so, are the meeting notes on line...?
No.
>
>Also,
>
>According to the following schedule, the formation of the IAHC
>triggers the establishment of "Day 1".
>
>Can you explain when Day 1 occurred...?...(if it did)
The timeline has been revised with firm dates and that too should
be out there on the Internet very soon.
>
>@@@@ http://info.isoc.org/whatsnew/itlds.html
>
>Schedule of Events
>
>Day 1 IAHC formed
>Day 30 IAHC finalizes procedures and publicly announces
>Day 31 Begin accepting applications
>Day 90 Acceptance of applications ceases
>Day 135 IAHC announces registry selection and iTLDs
>Day 136 ISOC begins contracting with selected registries
>Day X ISOC notifies IANA that contract is complete
>Day X + 1 IANA introduces new iTLDs to root zone file
>Day X + 90 Registry begins operations
>
>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>
>--
>Jim Fleming
>UNETY Systems, Inc.
>Naperville, IL
>
>e-mail:
>JimFleming at unety.net
>JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Hank Nussbacher
Israel
Received: from ietf.org by ietf.org id aa14259; 7 Nov 96 5:11 EST
Received: from smtpgw.ed.nce.sita.int by ietf.org id aa13902; 7 Nov 96 5:10 EST
Return-Path: <steen.larsen at smtpgw>
Received: from rdsita.rd-sita.fr by smtpgw.ed.nce.sita.int (8.7.5/SitaNet-1.5)
id LAA18341; Thu, 7 Nov 1996 11:07:48 +0100 (MET)
Received: from slarsen.ed.nce.sita.int (pc-edstl.ed.nce.sita.int) by rdsita.rd-sita.fr (5.0/SMI-SVR4)
id AA23578; Thu, 7 Nov 1996 11:08:22 --100
Message-Id: <3281B628.4333 at ed.nce.sita.int>
Date: Thu, 07 Nov 1996 11:12:56 +0100
Sender:ietf-request at ietf.org
From: Steen Larsen <steen.larsen at ed.nce.sita.int>
Reply-To: steen.larsen at ed.nce.sita.int
Organization: SITA R&D Nice
X-Mailer: Mozilla 3.0Gold (Win95; I)
Mime-Version: 1.0
To: Hank Nussbacher <HANK at vm.biu.ac.il>
Cc: ietf at ietf.org
Subject: Trading domain names
References: <9611070420.aa09728 at ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Hank Nussbacher wrote:
>
> ......
> The way out of this is to eliminate the ability to trade in DNs. If
> the rule was that a DN is not transferrable, then there would be
> no value to doing a large DN grab. See the Israeli DN policy
> at www.isoc.org.il If we find that a company trades in DNs, they
> lose all existing DNs.
At first this looks like a good idea. But there would be lots of
loopholes around this. One obvious way is to create a Delaware, British
Virgin Islands, etc. company that owns the domain name. Instead of
trading the name you simply trade the company.
Well, maybe your idea isn't so bad anyway, using the loophole costs
money.
That could be a limiting factor stopping people from grabbing hundreds
of domain names for future re-sale.
Best regards
Steen
--
Steen Koefoed Larsen <steen.larsen at ed.nce.sita.int>
Disclaimer: This letter may contain pure garbage that differs
from the opinion of myself and the companies I work for.
SITA -- Societe Internationale de Telecommunications Aeronautiqes
R & D Nice, Heraklion - 1041 Route des Dolines, F-06560 Valbonne
Phone: +33 4 92.96.63.67, Fax: +33 4 92.96.64.92, SITATEX: NCEEMXS
E-mail at home: steenkl at dircon.co.uk, GSM Mobile: +45 40512486
*** Syntax? Why not - they tax everything else! ***
Received: from ietf.org by ietf.org id aa18919; 7 Nov 96 7:28 EST
Received: from fxiod01.is.chrysler.com by ietf.org id aa18427; 7 Nov 96 7:18 EST
Received: by fxiod01.is.chrysler.com; id AA20219; Thu, 7 Nov 96 07:17:51 EST
Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod01.is.chrysler.com via smap (V3.1.1)
id xma020214; Thu, 7 Nov 96 07:17:48 -0500
Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id HAA24649; Thu, 7 Nov 1996 07:07:11 -0500 (EST)
Message-Id: <3.0b36.32.19961107070838.00b52c50 at pop3hub.is.chrysler.com>
Reply-To: rgm3 at chrysler.com
X-Sender: rgm3 at pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b36 (32)
Date: Thu, 07 Nov 1996 07:17:16 -0500
To: Hank Nussbacher <HANK at vm.biu.ac.il>, ietf at ietf.org
Sender:ietf-request at ietf.org
From: Robert Moskowitz <rgm3 at chrysler.com>
Subject: Re: More iTLD thread
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Source-Info: From (or Sender) name not authenticated.
At 11:21 AM 11/7/96 IDT, Hank Nussbacher wrote:
>In article <01BBC802.B4CACCE0 at webster.unety.net>, JimFleming at unety.net (Jim
>Fleming) says:
>>In my opinion, I do not think that the NASA server should even be in
>>the set of "popular" root name servers because of the following reasons.
>> 1. As you have shown, it is not accessible.
>> 2. It is in North America, and more International coverage should
>> be encouraged.
>> 3. It is funded by U.S. taxpayers and as people have seen recently
>> as well as during the past few years, the U.S. Government
>> (mostly via the NSF) wants the Internet infrastructure to be
>> shifted to the commercial sector. Root name servers should
>> be no exception.
>
>Total agreement. The root nameservers should be funded via money
>raised in establishing any new iTLDs. That includes hardware, software
>and manpower to run a true root nameserver. There should be 4-5 in
>Europe, 2-3 in the Far East and about 6-7 in North America all funded
>via new iTLDs.
As a member of the FNCAC (carefully watch which hat I am wearing :), I am
not sure I agree. If there is a reachablity problem with the NASA server,
that might have to be fixed. But the US gov may want a level of assurance
that their systems can resolve names. Afterall, currently they have the
largest # of TLDs!
Robert Moskowitz
Chrysler Corporation
(810) 758-8212
Received: from ietf.org by ietf.org id aa19342; 7 Nov 96 7:42 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa19249;
7 Nov 96 7:40 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199611071158.UAA14489 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id UAA14489; Thu, 7 Nov 1996 20:57:54 +0859
Subject: Re: The cartel begins to crumble?
To: Hank Nussbacher <HANK at vm.biu.ac.il>
Date: Thu, 7 Nov 96 20:57:53 JST
Cc: ietf at ietf.org
In-Reply-To: <9611070429.aa10607 at ietf.org>; from "Hank Nussbacher" at Nov 7, 96 11:22 am
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> Speaking at a microphone at an IETF does not set a standard. Helping
> draft an RFC via email and being able to take the time to reply
> clearly, slowly and thoughtfully, even if it takes you 3x times
> as long as a native English speakers, is the ulminate equalizer.
Wrong. You ignore the importance of the face to face meetings.
If you disagree, we should stop having face to face meetings spending
a lot of travel expenses, which is a very good equalizer.
> Only the loudest people grab the mike. There are many native
> English speakers who are in the same boat as you.
Exactly. And that's the problem. Note that *I* have no difficulty
to grab the mike.
Masataka Ohta
Received: from ietf.org by ietf.org id aa23549; 7 Nov 96 9:40 EST
Received: from localhost by ietf.org id aa22622; 7 Nov 96 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-procrules-00.txt, .ps
Date: Thu, 07 Nov 1996 09:32:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611070932.aa22622 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Resource ReSerVation Protocol (RSVP) -- Version 1
Message Processing Rules
Author(s) : R. Braden, L. Zhang
Filename : draft-ietf-rsvp-procrules-00.txt, .ps
Pages : 26
Date : 11/05/1996
This memo contains an algorithmic description of the rules used by an RSVP
implementation for processing messages. It is intended to clarify the
version 1 RSVP protocol specification.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-procrules-00.txt".
Or
"get draft-ietf-rsvp-procrules-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-procrules-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-procrules-00.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-procrules-00.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961105152159.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-procrules-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-procrules-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961105152159.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23535; 7 Nov 96 9:40 EST
Received: from localhost by ietf.org id aa22595; 7 Nov 96 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at internic.net
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-dnsind-clarify-02.txt
Date: Thu, 07 Nov 1996 09:32:41 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611070932.aa22595 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Clarifications to the DNS Specification
Author(s) : R. Elz, R. Bush
Filename : draft-ietf-dnsind-clarify-02.txt
Pages : 8
Date : 11/06/1996
This draft considers some areas that have been identified as problems with
the specification of the Domain Name System, and proposes remedies for the
defects identified. Four separate issues are considered:
+ IP packet header address usage from multi-homed servers,
+ TTLs in sets of records with the same name, class, and type,
+ the issue of what is an authoritative, or canonical, name,
+ and the issue of what makes a valid DNS label.
The first two of these are areas where the correct behaviour has been
somewhat unclear, we seek to rectify that. The other two are already
adequately specified, however the specifications seem to be sometimes
ignored. We seek to reinforce the existing specification.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dnsind-clarify-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-clarify-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-clarify-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961106135015.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-clarify-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-clarify-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961106135015.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23555; 7 Nov 96 9:40 EST
Received: from localhost by ietf.org id aa22553; 7 Nov 96 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ota-http-version-00.txt
Date: Thu, 07 Nov 1996 09:32:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611070932.aa22553 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Version management with meta-level links via HTTP/1.1
Author(s) : K. Ota, K. Takahashi, K. Sekiya
Filename : draft-ota-http-version-00.txt
Pages : 5
Date : 11/06/1996
This draft describes version management of the resources with some
extensions to HTTP/1.1.
The main point of our approach is to use meta-level links, which is not an
anchor of HTML format, but an attribute of the resource. So, the contents
need not to be an HTML format.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ota-http-version-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ota-http-version-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ota-http-version-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961106103826.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ota-http-version-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ota-http-version-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961106103826.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa23536; 7 Nov 96 9:40 EST
Received: from localhost by ietf.org id aa22570; 7 Nov 96 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mobile-ip at smallworks.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-liyunzhou-mobileip-ppm-00.txt, .ps
Date: Thu, 07 Nov 1996 09:32:25 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611070932.aa22570 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Proximity Proxies for Mobile Nodes and Mobility Agents
(PPM)
Author(s) : Y. Li
Filename : draft-liyunzhou-mobileip-ppm-00.txt, .ps
Pages : 23
Date : 11/06/1996
This document aims to explore an approach for the interoperability testing
of Mobile IP implementations across the Internet. It proposes client/server
proximity proxies, two intermediate entities between the mobile node and
the mobility agent. This model can be used to solve the problem addressed
in the hierarchical foreign agents model. The document proposes to build a
tunnel between proximity proxies using Tunnel Request and Tunnel Reply
messages, and enable routing policies to the tunnel by using Proxy Update
message and adding a bit in Agent Advertisement message.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-liyunzhou-mobileip-ppm-00.txt".
Or
"get draft-liyunzhou-mobileip-ppm-00.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-liyunzhou-mobileip-ppm-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-liyunzhou-mobileip-ppm-00.txt".
Or
"FILE /internet-drafts/draft-liyunzhou-mobileip-ppm-00.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961106110438.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-liyunzhou-mobileip-ppm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-liyunzhou-mobileip-ppm-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961106110438.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24152; 7 Nov 96 9:45 EST
Received: from localhost by ietf.org id aa22613; 7 Nov 96 9:32 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-rsvp-spec-14.txt, .ps
Date: Thu, 07 Nov 1996 09:32:44 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9611070932.aa22613 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Resource Reservation Setup
Protocol Working Group of the IETF.
Title : Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification
Author(s) : R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin
Filename : draft-ietf-rsvp-spec-14.txt, .ps
Pages : 104
Date : 11/06/1996
This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or unicast
data flows, with good scaling and robustness properties.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rsvp-spec-14.txt".
Or
"get draft-ietf-rsvp-spec-14.ps".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-rsvp-spec-14.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-spec-14.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-spec-14.ps".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961106115231.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rsvp-spec-14.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-spec-14.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961106115231.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24668; 7 Nov 96 9:52 EST
Received: from [207.32.128.130] by ietf.org id aa24534; 7 Nov 96 9:50 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id IAA24263; Thu, 7 Nov 1996 08:41:59 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCC87.CC6A7240 at webster.unety.net>; Thu, 7 Nov 1996 08:43:50 -0600
Message-ID: <01BBCC87.CC6A7240 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Hank Nussbacher' <HANK at vm.biu.ac.il>, "ietf at ietf.org" <ietf at ietf.org>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: RE: More iTLD thread
Date: Thu, 7 Nov 1996 08:43:48 -0600
Encoding: 83 TEXT
Source-Info: From (or Sender) name not authenticated.
On Thursday, November 07, 1996 5:21 AM, Hank Nussbacher[SMTP:HANK at vm.biu.ac.il] wrote:
@ In article <01BBC802.B4CACCE0 at webster.unety.net>, JimFleming at unety.net (Jim
@ Fleming) says:
@ >In my opinion, I do not think that the NASA server should even be in
@ >the set of "popular" root name servers because of the following reasons.
@ > 1. As you have shown, it is not accessible.
@ > 2. It is in North America, and more International coverage should
@ > be encouraged.
@ > 3. It is funded by U.S. taxpayers and as people have seen recently
@ > as well as during the past few years, the U.S. Government
@ > (mostly via the NSF) wants the Internet infrastructure to be
@ > shifted to the commercial sector. Root name servers should
@ > be no exception.
@
@ Total agreement. The root nameservers should be funded via money
@ raised in establishing any new iTLDs. That includes hardware, software
@ and manpower to run a true root nameserver. There should be 4-5 in
@ Europe, 2-3 in the Far East and about 6-7 in North America all funded
@ via new iTLDs.
@
@ >
@ >Many people feel that the U.S.-centric attitudes of Internet Infrastructure
@ >administration need to be down played and more emphasis needs to be
@ >placed on the International nature of the Internet. One of the major complaints
@ >that some people reported from a recent Harvard conference was a lack
@ >of participation from the International community.
@
@ As a former American who moved to Israel 15 years ago I have to agree
@ with you. Americans are very geo-centric and have a hard time understanding
@ the mentalities of other countries.
@
@ >--
@ >Jim Fleming
@ >UNETY Systems, Inc.
@ >Naperville, IL
@
@ Hank Nussbacher
@ Israel
@
@
I think that many of the people that have been working
on these issues for many months on the "newdom"
mailing list will appreciate your comments.
One of the modest goals proposed and being discussed
on that mailing list is the documenting of 64 root name
servers scattered around the world. With Root 64, ISPs
and system administrators would be able to make a better
engineering decision on which name servers they wish to
include in their "root.cache" file.
Also discussed on that list is a "round table" decision
making model, where the owners of those root name
servers, in concert with the ISPs and top level domain
registries, will work together to decide which top level
domains to support.
In my opinion, the round table model allows natural
market forces to control the evolution as opposed to
a few people. Customers have input into the process
by the economic support of the ISPs and registries
via their registration fees.
If you are interested in following those discussions
on the newdom list, there is a web site with more
information.
<http://www.newdom.com/lists/>
Thanks again for your comments.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa26232; 7 Nov 96 10:09 EST
Received: from localhost by ietf.org id aa26021; 7 Nov 96 10:07 EST
To: ietf at ietf.org
Subject: Re: The cartel begins to crumble?
Sender:ietf-request at ietf.org
From: Bill Wohler <wohler at newt.com>
Date: Thu, 07 Nov 1996 10:07:26 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611071007.aa26021 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
karl at mcs.net (Karl Denninger) writes:
>> OK, I'll bite. I hereby claim all TLDs that no one has yet registered with
>> either Alternic or IANA.
>More reduction to the absurd.
If there isn't central control, it isn't absurd at all. Take the
real-life example of the thousands of domains that have already gotten
nuked once billing began. And there was even control in
place--somewhat.
What, besides ethics, keeps me from running the equivalent of:
newtld `echo 1*3[a-z] | egrep -v '(edu|com|gov|...)'`
Considering the amount of spam and other sludge on the net, I would
hardly leave this to ethics of the netizens of the planet.
I am not warm to opening up the TLDs, but we may have to do this
in the future. One must be ensured that the root servers contain all
the TLDs, and that all the root servers contain the same data.
--
Bill Wohler <wohler at newt.com> ph: +1-415-854-1857 fax: +1-415-854-3195
Say it with MIME. Maintainer of comp.mail.mh and news.software.nn FAQs.
If you're passed on the right, you're in the wrong lane.
Received: from ietf.org by ietf.org id aa26368; 7 Nov 96 10:10 EST
Received: from localhost by ietf.org id aa26299; 7 Nov 96 10:09 EST
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: "Dale R. Worley" <worley at ariadne.com>
Subject: Standards conformance (was: The Cartel Begins to Crumble)
Date: Thu, 07 Nov 1996 10:09:45 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9611071009.aa26299 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
In article <199611011724.MAA02841 at jekyll.piermont.com> perry at piermont.com
("Perry E. Metzger") writes:
I believe that most of the firms that have seriously flouted
standards in the past (Wang comes to mind) have been punished in
the marketplace.
It's a very complicated issue, but in the long run, that seems to be
true. The minicomputer industry in Massachusetts, USA was dominated
by four companies (Digital, Wang, Data General, and Prime) which built
and sold proprietary systems for twenty years or so. And they were
able to charge a high markup on their hardware, but sold their
software at low prices.
Around the end of the 1980's, Unix became popular enough that many
customers switched from proprietary operating systems. The four
minicomputer companies attempted to resist the change, because they
would have to sell Unix-based systems for considerably less than they
sold equivalent proprietary systems.
The marketplace took its revenge. Wang and Prime are effectively
dead, though they remain in business. Data General concentrates on
other lines of business than computer sales. Only Digital remains as
a mass seller of computer systems, but is much smaller than it was.
Massachusetts suffered severe economic stress.
So successfully flouting popular standards seems to be possible, but
over long periods of time, it is probably not sustainable.
Dale
--
Dale R. Worley Ariadne Internet Services
Voice: +1 617-899-7949 Fax: +1 617-899-7946 E-mail: worley at ariadne.com
"Internet-based electronic commerce solutions to real business problems."
Received: from ietf.org by ietf.org id aa00400; 7 Nov 96 11:22 EST
Received: from Kitten.mcs.com by ietf.org id aa00202; 7 Nov 96 11:20 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA29529; Thu, 7 Nov 1996 10:19:04 -0600 (CST)
Received: from Mercury.mcs.net (karl at Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA11379; Thu, 7 Nov 1996 10:19:03 -0600 (CST)
Received: (from karl at localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA18711; Thu, 7 Nov 1996 10:19:02 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611071619.KAA18711 at Mercury.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Hank Nussbacher <HANK at vm.biu.ac.il>
Date: Thu, 7 Nov 1996 10:19:02 -0600 (CST)
Cc: ietf at ietf.org
In-Reply-To: <9611070426.aa09875 at ietf.org> from "Hank Nussbacher" at Nov 7, 96 11:19:43 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> >Zones are transferrable. Its easily arguable that this is a self-healing
> >problem to a large extent. A dead registry is going to be a tangible, and
> >valuable, asset (assuming it has registrants in it -- if not the entire
> >discussion is moot and irrelavent).
>
> Company A sells DNs in their new .biz domain for a $200 one time
> fee (forever). Three years later they go bankrupt. Company B
> comes along and is willing to take over the .biz domain but
> cannot charge any existing customers since they have a piece of
> paper stating that their domain is cost free forever.
>
> An orphaned registry is only valuable if it has enough critical
> mass and many paying customers.
Bad assumption.
If a TLD is desirable, it will have NEW customers.
If it has no customers, there is no disruption when it disappears.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa00401; 7 Nov 96 11:22 EST
Received: from Kitten.mcs.com by ietf.org id aa00180; 7 Nov 96 11:19 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA29449; Thu, 7 Nov 1996 10:17:13 -0600 (CST)
Received: from Mercury.mcs.net (karl at Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA11044; Thu, 7 Nov 1996 10:17:12 -0600 (CST)
Received: (from karl at localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA18637; Thu, 7 Nov 1996 10:17:10 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611071617.KAA18637 at Mercury.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Hank Nussbacher <HANK at vm.biu.ac.il>
Date: Thu, 7 Nov 1996 10:17:10 -0600 (CST)
Cc: ietf at ietf.org
In-Reply-To: <9611070420.aa09728 at ietf.org> from "Hank Nussbacher" at Nov 7, 96 11:16:55 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> In article <199611020034.SAA15592 at Jupiter.Mcs.Net>, karl at mcs.net (Karl
> Denninger) says:
> > 2. Limits would be applied to the number of "new" registrations and
> > organization could get within a window of time, to avoid registration
> > stuffing.
>
> ISPs act on behalf of their clients. They register dozens of DNs
> per day. How do we handle the ISPs and PSPs? I work for IBM Israel
> which as a number of PSPs that it services. As soon as they talk to
> a client, that day they submit the request for cola.co.il (after
> they talk to Pepsi) or for jeans.co.il (after they talk to Levi's).
> There is *no* way to verify whether indeed they have an actual
> client behind them with such a domain. We have seen PSPs request 30
> DNs a day with just names out of the air.
I'm talking about *TLDs*, not second-level delegations. Frankly, we request
30 DNs a day sometimes. Its not unusual at all.
> You cannot limit a company from doing registrations - either
> timewise of amountwise. This is their business and you can't
> make artifical rules to slow them down.
Nobody is trying to in THAT case.
> The way out of this is to eliminate the ability to trade in DNs. If
> the rule was that a DN is not transferrable, then there would be
> no value to doing a large DN grab. See the Israeli DN policy
> at www.isoc.org.il If we find that a company trades in DNs, they
> lose all existing DNs.
How do you prove it?
Are you willing to get sued if you're wrong, and potentially be liable not
only for real lost business (millions of US $) but ALSO punitive damages?
Why does ANYONE want that kind of liability.
Three standards to adhere to:
1)Verifyability
2)Objectivity
3)Serves the purpose
You need to meet all three.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa00550; 7 Nov 96 11:24 EST
Received: from Kitten.mcs.com by ietf.org id aa00466; 7 Nov 96 11:23 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA29791; Thu, 7 Nov 1996 10:22:53 -0600 (CST)
Received: from Mercury.mcs.net (karl at Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA12167; Thu, 7 Nov 1996 10:22:52 -0600 (CST)
Received: (from karl at localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA19008; Thu, 7 Nov 1996 10:22:51 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611071622.KAA19008 at Mercury.mcs.net>
Subject: Re: IAHC
To: Hank Nussbacher <HANK at vm.biu.ac.il>
Date: Thu, 7 Nov 1996 10:22:50 -0600 (CST)
Cc: ietf at ietf.org
In-Reply-To: <9611070426.aa10301 at ietf.org> from "Hank Nussbacher" at Nov 7, 96 11:20:58 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> In article <199611012302.RAA13532 at Jupiter.Mcs.Net>, karl at mcs.net (Karl
> Denninger) says:
> >And you get to define what the namespace of "The Internet" is, right?
> >
> >Or, more correctly, the IANA gets to define it?
>
> Disclaimer: I speak only for myself and am a member of the newly formed
> IAHC which will hopefully resolve this issue.
>
> I think the IANA has backed out of this so you have nothing to fear. It
> is now in the hands of a committee made up of people from ISOC, IETF,
> ITU, INTA, WIPA and what-have-you. The IANA has a minority voice.
>
> So just give us a bit of time, some good input and we will have the new
> iTLDs awarded in no time.
How did the COMMITTEE get the authority?
There was no open process.
There were no public nominations.
There ARE people on the committee (one in particular comes to mind) who have
made a practice of insinuating that people are committing CRIMINAL
acts by supporting eDNS (specifically, allegations of "fraud")
There is no "resume", or curriculum vitae, on the members available.
There is no public process, mechanism for public comment, nor public record
of discussions and vote(s) within the committee.
None of this speaks highly towards this being an "open" process.
Quite to the contrary.
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa00985; 7 Nov 96 11:30 EST
Received: from cnri by ietf.org id aa00913; 7 Nov 96 11:29 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14017;
7 Nov 96 11:29 EST
Received: from hydra_nt_server (hydrainc.com) by venera.isi.edu (5.65c/5.61+local-25)
id <AA29889>; Thu, 7 Nov 1996 08:22:39 -0800
Received: from [206.233.77.6] by hydra_nt_server (NTMail 3.00.06) id aa006198 Thu, 7 Nov 96 16:17:16 -0800 (GMT)
Received: by 206.233.77.2.hydrainc.com with Microsoft Mail
id <01BBCC83.8A77A6E0 at 206.233.77.2.hydrainc.com>; Thu, 7 Nov 1996 08:13:21 -0800
Message-Id: <01BBCC83.8A77A6E0 at 206.233.77.2.hydrainc.com>
Sender:ietf-request at ietf.org
From: Pratima JanakiRam <janakir at acclaiminc.com>
To: "ietf at isi.edu" <ietf at isi.edu>
Subject: RE:
Date: Thu, 7 Nov 1996 08:13:18 -0800
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
unsubscribe comsoc-conferences ietf at isi.edu
Received: from ietf.org by ietf.org id aa01178; 7 Nov 96 11:33 EST
Received: from Kitten.mcs.com by ietf.org id aa01035; 7 Nov 96 11:31 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id KAA00216; Thu, 7 Nov 1996 10:30:38 -0600 (CST)
Received: from Mercury.mcs.net (karl at Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id KAA13732; Thu, 7 Nov 1996 10:30:36 -0600 (CST)
Received: (from karl at localhost) by Mercury.mcs.net (8.8.2/8.8.2) id KAA19324; Thu, 7 Nov 1996 10:30:35 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611071630.KAA19324 at Mercury.mcs.net>
Subject: Re: More iTLD thread
To: rgm3 at chrysler.com
Date: Thu, 7 Nov 1996 10:30:33 -0600 (CST)
Cc: HANK at vm.biu.ac.il, ietf at ietf.org
In-Reply-To: <3.0b36.32.19961107070838.00b52c50 at pop3hub.is.chrysler.com> from "Robert Moskowitz" at Nov 7, 96 07:17:16 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> At 11:21 AM 11/7/96 IDT, Hank Nussbacher wrote:
> >Total agreement. The root nameservers should be funded via money
> >raised in establishing any new iTLDs. That includes hardware, software
> >and manpower to run a true root nameserver. There should be 4-5 in
> >Europe, 2-3 in the Far East and about 6-7 in North America all funded
> >via new iTLDs.
>
> As a member of the FNCAC (carefully watch which hat I am wearing :), I am
> not sure I agree. If there is a reachablity problem with the NASA server,
> that might have to be fixed. But the US gov may want a level of assurance
> that their systems can resolve names. Afterall, currently they have the
> largest # of TLDs!
>
> Robert Moskowitz
> Chrysler Corporation
> (810) 758-8212
I happen to agree with Robert.
The only way you solve the root mess (really fix it) is to have enough
geographic AND line-of-use diversity that everyone is comfortable.
Root-64 is one way to do that (there's not enough of a cohesive policy
statement as of yet for me to know if I like the details in that devil or
not at this point).
IMHO you need to take into account:
1)Net topology (ie: you want multiple roots "close" to you for
performance reasons).
2)Increased count of servers in total (you want fast service, and
since the number of queries is growing, you need to have more of
them. This implies that you MUST have confederations of servers,
since there is that ugly packet-size restriction on the responses
for the "additional info" field).
The funny part of it is that I'm not at all certain that the user has to
stay within the confederation. That is, what happens if you choose 100 root
nameservers to list, and each belongs to a confederation that includes no
more than 13.
Leave aside the synchronization issue, and assume all have the same data in
them.
I'd be quite interested in knowing if BIND will spit up under these
circumstances..... and intend to test it.
I believe the answer is "no, it will not".
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa02211; 7 Nov 96 11:57 EST
Received: from ng.netgate.net by ietf.org id aa01963; 7 Nov 96 11:55 EST
Received: from [205.214.160.114] (d89.netgate.net [205.214.160.125]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id IAA25566; Thu, 7 Nov 1996 08:57:07 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100621aea7c0634dca at [205.214.160.114]>
In-Reply-To: <9611070426.aa10301 at ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 7 Nov 1996 08:42:46 -0800
To: Hank Nussbacher <HANK at vm.biu.ac.il>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: IAHC
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 12:20 AM -0800 11/7/96, Hank Nussbacher wrote:
>I think the IANA has backed out of this so you have nothing to fear. It
>is now in the hands of a committee made up of people from ISOC, IETF,
>ITU, INTA, WIPA and what-have-you. The IANA has a minority voice.
(also speaking strictly personally, though also serving as a member
of the IAHC...)
Let me emphasize Hank's point:
A number of the members of the committee are participating explicitly as
"representatives" of specific organizations. I believe none of the 5
"Internet" appointees are participating with an explicit representational
responsibility more specific than "Internet". For example I was appointed
by IANA but am not serving as its representative. (I couldn't, even if I
wanted to, since I have had no involvement in its operation, ever.
=46urther, I am not consulting IANA about the details of my participation an=
d
they are not requesting me to.)
I think that organizational representations on the IAHC are fine. In the
case of those from the Internet "side" it's simply that the appropriate
scope of the "organization" is Internet-generic, rather than being limited
to any one of its component groups.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from ietf.org by ietf.org id aa02772; 7 Nov 96 12:03 EST
Received: from Kitten.mcs.com by ietf.org id aa02674; 7 Nov 96 12:02 EST
Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.Beta.3) with ESMTP id LAA01612; Thu, 7 Nov 1996 11:00:56 -0600 (CST)
Received: from Mercury.mcs.net (karl at Mercury.mcs.com [192.160.127.80]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id LAA20049; Thu, 7 Nov 1996 11:00:54 -0600 (CST)
Received: (from karl at localhost) by Mercury.mcs.net (8.8.2/8.8.2) id LAA21173; Thu, 7 Nov 1996 11:00:48 -0600 (CST)
Sender:ietf-request at ietf.org
From: Karl Denninger <karl at mcs.net>
Message-Id: <199611071700.LAA21173 at Mercury.mcs.net>
Subject: Re: The cartel begins to crumble?
To: Bill Wohler <wohler at newt.com>
Date: Thu, 7 Nov 1996 11:00:48 -0600 (CST)
Cc: ietf at ietf.org
In-Reply-To: <9611071007.aa26021 at ietf.org> from "Bill Wohler" at Nov 7, 96 10:07:26 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Source-Info: From (or Sender) name not authenticated.
> karl at mcs.net (Karl Denninger) writes:
> >> OK, I'll bite. I hereby claim all TLDs that no one has yet registered with
> >> either Alternic or IANA.
>
> >More reduction to the absurd.
>
> If there isn't central control, it isn't absurd at all. Take the
> real-life example of the thousands of domains that have already gotten
> nuked once billing began. And there was even control in
> place--somewhat.
Let's be real.
Right now you can register a SLD without nameservers operating from IANA's
"sponsored" iTLDs!
You CANNOT do that in .BIZ, .CORP, or .NPO. I do not believe you can do it
in MOST of the eDNS namespace.
What prevents people from doing this is simple -- a rule that you have
to have an OPERATIONAL registry online, and really be taking registrations
within 30 days or you lose the delegation PERMANENTLY.
Second, I do support *rational* limits on the number of delegations an
organziation or related set of organizations can hold (say, 20), with no
more than 3-5 in the pipe at any given time.
All this has been clearly explained in other messages I've posted here and
elsewhere on this topic.
As for synchronizing the roots, what's wrong with a zone transfer? The
Alternic eDNS has been using it -- it WORKS. Unlike FTPing a file around,
which has this ugly habit of failing without telling anyone, the eDNS
servers to date have remained synchronized (within a few hours of an
update, of course).
> Bill Wohler <wohler at newt.com> ph: +1-415-854-1857 fax: +1-415-854-3195
--
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Received: from ietf.org by ietf.org id aa03592; 7 Nov 96 12:12 EST
Received: from drwho.aspect.com.au by ietf.org id aa03473; 7 Nov 96 12:11 EST
Return-Path: Phill.Kelley at aspect.com.au
Received: from cbrgw.aspect.com.au (cbrgw.aspect.com.au [137.76.6.10]) by drwho.aspect.com.au (8.6.12/8.7) with ESMTP id CAA09965 for <ietf at ietf.org>; Fri, 8 Nov 1996 02:52:21 +1100
Received: from [137.76.60.51] (cbrxs1a1.cbr.aspect.com.au [137.76.60.51]) by cbrgw.aspect.com.au (8.6.12/8.7) with ESMTP id CAA14602 for <ietf at ietf.org>; Fri, 8 Nov 1996 02:52:13 +1100
X-Sender: kelleyp at cbrgw.aspect.com.au (Unverified)
Message-Id: <v03007806aea7343c55f8 at [137.76.60.51]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 6 Nov 1996 23:13:00 -0800
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Phill Kelley <Phill.Kelley at aspect.com.au>
Subject: The price of chatter
Source-Info: From (or Sender) name not authenticated.
G'Day!
I have been out of my home town for the past week and have just called
long-distance to clear my email. There were some 170 messages which the
wonderful "check your own bill" service on the hotel TV tells me cost $US35
to download.
Over 100 of the messages were from the IETF list.
I subscribed to the IETF list primarily because I wanted a simple way of
keeping up with new RFCs. I must admit to not being overly interested in
tracking the drafts but I took it that this came with the territory. I will
also admit that I have even gained useful information from watching a
number of the discussions as the regular contributors have stated their
positions.
However, recently I have formed the view that, increasingly, the majority
of the general subject matter has little relevance to my needs.
I have observed that many subscribers to the list simply decide to
unsubscribe. Given that those are the people who write to this list instead
of ietf-request, I assume that these visible departures are merely the tip
of the iceberg.
Before I follow this group who have voted with their e-feet, I want to ask
if it is possible to be subscribed only to the RFC announcements, without
the RFC drafts and without the general discussion?
Regards, PK
Received: from ietf.org by ietf.org id aa05463; 7 Nov 96 12:35 EST
Received: from [207.32.128.130] by ietf.org id aa05250; 7 Nov 96 12:33 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id LAA24665; Thu, 7 Nov 1996 11:22:23 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCC9E.360AD800 at webster.unety.net>; Thu, 7 Nov 1996 11:24:16 -0600
Message-ID: <01BBCC9E.360AD800 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: Hank Nussbacher <HANK at vm.biu.ac.il>, "ietf at ietf.org" <ietf at ietf.org>
Cc: 'New Newdom' <newdom at vrx.net>
Subject: RE: More iTLD thread
Date: Thu, 7 Nov 1996 11:24:15 -0600
Encoding: 56 TEXT
Source-Info: From (or Sender) name not authenticated.
On Thursday, November 07, 1996 6:17 AM, Robert Moskowitz[SMTP:rgm3 at chrysler.com] wrote:
@ At 11:21 AM 11/7/96 IDT, Hank Nussbacher wrote:
@ >In article <01BBC802.B4CACCE0 at webster.unety.net>, JimFleming at unety.net (Jim
@ >Fleming) says:
@ >>In my opinion, I do not think that the NASA server should even be in
@ >>the set of "popular" root name servers because of the following reasons.
@ >> 1. As you have shown, it is not accessible.
@ >> 2. It is in North America, and more International coverage should
@ >> be encouraged.
@ >> 3. It is funded by U.S. taxpayers and as people have seen recently
@ >> as well as during the past few years, the U.S. Government
@ >> (mostly via the NSF) wants the Internet infrastructure to be
@ >> shifted to the commercial sector. Root name servers should
@ >> be no exception.
@ >
@ >Total agreement. The root nameservers should be funded via money
@ >raised in establishing any new iTLDs. That includes hardware, software
@ >and manpower to run a true root nameserver. There should be 4-5 in
@ >Europe, 2-3 in the Far East and about 6-7 in North America all funded
@ >via new iTLDs.
@
@ As a member of the FNCAC (carefully watch which hat I am wearing :), I am
@ not sure I agree. If there is a reachablity problem with the NASA server,
@ that might have to be fixed. But the US gov may want a level of assurance
@ that their systems can resolve names. Afterall, currently they have the
@ largest # of TLDs!
@
@
@ Robert Moskowitz
@ Chrysler Corporation
@ (810) 758-8212
@
@
@
I also think that ISPs need some level of assurance
that their systems can resolve names. While they
might currently enjoy the luxury of using U.S. Government
machines, it is prudent for them to be aware that those
machines are largely run by volunteers who may not
have "signed up" for the commercial requirements
of the Internet.
There are also privacy issues that people do not seem
to be concerned about. Some people, especially
outside of the U.S. may not want the U.S. Government
tracking all of the names people are looking up.
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa07750; 7 Nov 96 13:05 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa07641; 7 Nov 96 13:03 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id MAA72100; Thu, 7 Nov 1996 12:58:03 -0500
Message-Id: <199611071758.MAA72100 at black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Karl Denninger <karl at mcs.net>
Cc: Hank Nussbacher <HANK at vm.biu.ac.il>, ietf at ietf.org
Subject: Re: The cartel begins to crumble?
In-Reply-To: Your message of "Thu, 07 Nov 1996 10:19:02 CST."
<199611071619.KAA18711 at Mercury.mcs.net>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199611071619.KAA18711 at Mercury.mcs.net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1085719768P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 07 Nov 1996 12:58:03 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1085719768P
Content-Type: text/plain; charset=us-ascii
On Thu, 07 Nov 1996 10:19:02 CST, Karl Denninger said:
> If a TLD is desirable, it will have NEW customers.
>
> If it has no customers, there is no disruption when it disappears.
Almost but not quite right.
Something can be desirable for the "latest and greatest" followers, but
not have any staying power.
See pet rocks for an example. Would *you* buy the assets of a now-bankrupt
producer of pet rocks, hoping that continued revenue would keep you afloat?
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1085719768P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMoIjKdQBOOoptg9JAQEcpAP+P2cXO1q/wge6cIYBE2Yhy1x0N/TIh7tr
NOocu9B2mcvBk4PsHKWB+xPYHkAvncyAU45X6IaR1F6ejCtzcmLB0XRj3oh0Y1JZ
riLAjUkthzxHVijImO8rqOlzPVBUWQaaTbsR1HPP2PTIGGeZJ/juXsLT1WTtsGwU
lP4Q+BJM6tg=
=7/Ib
-----END PGP MESSAGE-----
--==_Exmh_-1085719768P--
Received: from ietf.org by ietf.org id aa12092; 7 Nov 96 13:49 EST
Received: from eunet.EU.net by ietf.org id aa11946; 7 Nov 96 13:47 EST
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id TAA10094; Thu, 7 Nov 1996 19:46:51 +0100 (MET)
Received: by jotun.EU.net id AA28484
(5.67a/IDA-1.5); Thu, 7 Nov 1996 19:46:50 +0100
Message-Id: <199611071846.AA28484 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <bilse at eu.net>
Date: Thu, 7 Nov 1996 19:46:50 +0100
In-Reply-To: <199611071622.KAA19008 at Mercury.mcs.net>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Karl Denninger <karl at mcs.net>
Subject: Re: IAHC
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
On Nov 7, 10:22, Karl Denninger <karl at mcs.net> wrote:
> How did the COMMITTEE get the authority?
>
>[...]
>
> None of this speaks highly towards this being an "open" process.
>
> Quite to the contrary.
How does your, Fleming's, et als "process" line up?
--
------ ___ --- Per G. Bilse, Mgr Network Operations
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa14044; 7 Nov 96 14:09 EST
Received: from taunivm.tau.ac.il by ietf.org id aa13805; 7 Nov 96 14:07 EST
Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 5940; Thu, 07 Nov 96 21:06:21 IST
Received: from VM.TAU.AC.IL (NJE origin HANK at TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0339; Thu, 7 Nov 1996 21:06:21 +0200
Date: Thu, 07 Nov 96 21:04:07 IST
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.tau.ac.il>
Subject: Re: More iTLD thread
To: Robert Moskowitz <rgm3 at chrysler.com>,
Hank Nussbacher <HANK at vm.biu.ac.il>, ietf at ietf.org
In-Reply-To: Message of Thu, 07 Nov 1996 07:17:16 -0500 from
<rgm3 at chrysler.com>
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611071408.aa13805 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Thu, 07 Nov 1996 07:17:16 -0500 you said:
>>Total agreement. The root nameservers should be funded via money
>>raised in establishing any new iTLDs. That includes hardware, software
>>and manpower to run a true root nameserver. There should be 4-5 in
>>Europe, 2-3 in the Far East and about 6-7 in North America all funded
>>via new iTLDs.
>
>As a member of the FNCAC (carefully watch which hat I am wearing :), I am
>not sure I agree. If there is a reachablity problem with the NASA server,
>that might have to be fixed. But the US gov may want a level of assurance
>that their systems can resolve names. Afterall, currently they have the
>largest # of TLDs!
You don't agree that new iTLD money should fund the root servers or
you don't agree to have a wide geographical spread (can be even 20)?
Nothing wrong with NASA getting a few bucks to fund the root server
in my opinion. If they choose to relinquish the money - the more root
servers we can add and fund. -Hank
>
>
>Robert Moskowitz
>Chrysler Corporation
>(810) 758-8212
>
Received: from ietf.org by ietf.org id aa14189; 7 Nov 96 14:11 EST
Received: from eunet.EU.net by ietf.org id aa14101; 7 Nov 96 14:10 EST
Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.8.2/8.6.10) with SMTP id UAA11254; Thu, 7 Nov 1996 20:09:34 +0100 (MET)
Received: by jotun.EU.net id AA28589
(5.67a/IDA-1.5); Thu, 7 Nov 1996 20:09:34 +0100
Message-Id: <199611071909.AA28589 at jotun.EU.net>
Sender:ietf-request at ietf.org
From: Per Gregers Bilse <bilse at eu.net>
Date: Thu, 7 Nov 1996 20:09:34 +0100
In-Reply-To: <199611071700.LAA21173 at Mercury.mcs.net>
Organization: EUnet Communications Services BV
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: Karl Denninger <karl at mcs.net>
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
On Nov 7, 11:00, Karl Denninger <karl at mcs.net> wrote:
> What prevents people from doing this is simple -- a rule that you have
> to have an OPERATIONAL registry online, and really be taking registrations
> within 30 days or you lose the delegation PERMANENTLY.
Says who?
> Second, I do support *rational* limits on the number of delegations an
> organziation or related set of organizations can hold (say, 20), with no
> more than 3-5 in the pipe at any given time.
"Rational"? Surely, you mean "subjective".
> All this has been clearly explained in other messages I've posted here and
> elsewhere on this topic.
All of which is your private opinion. You need some recognized
authority to set/enforce whatever rules one will end up with, it
isn't enough that you just say so.
--
------ ___ --- Per G. Bilse, Mgr Network Operations
----- / / / __ ___ _/_ ---- EUnet Communications Services B.V.
---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657
--- ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net
Received: from ietf.org by ietf.org id aa15368; 7 Nov 96 14:24 EST
Received: from taunivm.tau.ac.il by ietf.org id aa15150; 7 Nov 96 14:22 EST
Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 6004; Thu, 07 Nov 96 21:21:40 IST
Received: from VM.TAU.AC.IL (NJE origin HANK at TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0499; Thu, 7 Nov 1996 21:21:40 +0200
Date: Thu, 07 Nov 96 21:15:45 IST
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.tau.ac.il>
Subject: RE: More iTLD thread
To: Jim Fleming <JimFleming at unety.net>,
'Hank Nussbacher' <HANK at vm.biu.ac.il>,
"ietf at ietf.org" <ietf at ietf.org>
cc: 'New Newdom' <newdom at vrx.net>
In-Reply-To: Message of Thu, 7 Nov 1996 08:43:48 -0600 from
<JimFleming at unety.net>
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611071422.aa15150 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Thu, 7 Nov 1996 08:43:48 -0600 you said:
>Also discussed on that list is a "round table" decision
>making model, where the owners of those root name
>servers, in concert with the ISPs and top level domain
>registries, will work together to decide which top level
>domains to support.
That will just cause a balkanization of the Internet. We need
for the roots to have all the iTLDs. The main problem has
been the NSI monopoly and the cramming in .com. Give the IAHC
some time (4 months) and we will solve your problems so that
everyone benefits.
>
>In my opinion, the round table model allows natural
>market forces to control the evolution as opposed to
>a few people. Customers have input into the process
>by the economic support of the ISPs and registries
>via their registration fees.
The round table model can easily be usurped as well as sued.
>If you are interested in following those discussions
>on the newdom list, there is a web site with more
>information.
I am aware of all the arguments but won't have time to monitor
all the newdom lists. The IAHC will have a list out there very
soon for you and others to submit proposals.
>
><http://www.newdom.com/lists/>
>
>Thanks again for your comments.
>
Any time. -Hank
>
>
>--
>Jim Fleming
>UNETY Systems, Inc.
>Naperville, IL
>
>e-mail:
>JimFleming at unety.net
>JimFleming at unety.net.s0.g0 (EDNS/IPv8)
>
Received: from ietf.org by ietf.org id aa16858; 7 Nov 96 14:33 EST
Received: from [207.32.128.130] by ietf.org id aa16755; 7 Nov 96 14:32 EST
Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by doorstep.unety.net (8.6.9/8.6.9) with SMTP id NAA25110; Thu, 7 Nov 1996 13:25:01 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBCCAF.5772B920 at webster.unety.net>; Thu, 7 Nov 1996 13:26:54 -0600
Message-ID: <01BBCCAF.5772B920 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: 'Dave Crocker' <dcrocker at brandenburg.com>,
Hank Nussbacher <HANK at vm.biu.ac.il>
Cc: 'Donald Heath' <heath at linus.isoc.org>, "ietf at ietf.org" <ietf at ietf.org>,
'New Newdom' <newdom at vrx.net>
Subject: RE: IAHC
Date: Thu, 7 Nov 1996 13:26:52 -0600
Encoding: 191 TEXT
Source-Info: From (or Sender) name not authenticated.
On Thursday, November 07, 1996 10:42 AM, Dave Crocker[SMTP:dcrocker at brandenburg.com] wrote:
@ At 12:20 AM -0800 11/7/96, Hank Nussbacher wrote:
@ >I think the IANA has backed out of this so you have nothing to fear. It
@ >is now in the hands of a committee made up of people from ISOC, IETF,
@ >ITU, INTA, WIPA and what-have-you. The IANA has a minority voice.
@
@ (also speaking strictly personally, though also serving as a member
@ of the IAHC...)
@
@ Let me emphasize Hank's point:
@
@ A number of the members of the committee are participating explicitly as
@ "representatives" of specific organizations. I believe none of the 5
@ "Internet" appointees are participating with an explicit representational
@ responsibility more specific than "Internet". For example I was appointed
@ by IANA but am not serving as its representative. (I couldn't, even if I
@ wanted to, since I have had no involvement in its operation, ever.
@ Further, I am not consulting IANA about the details of my participation and
@ they are not requesting me to.)
@
@ I think that organizational representations on the IAHC are fine. In the
@ case of those from the Internet "side" it's simply that the appropriate
@ scope of the "organization" is Internet-generic, rather than being limited
@ to any one of its component groups.
@
@ d/
@
@ --------------------
@ Dave Crocker +1 408 246 8253
@ Brandenburg Consulting fax: +1 408 249 6205
@ 675 Spruce Dr. dcrocker at brandenburg.com
@ Sunnyvale CA 94086 USA http://www.brandenburg.com
@
@ Internet Mail Consortium http://www.imc.org, info at imc.org
@
@
@
Dave,
These are all wonderful comments...please consider the following...
Can you explain why this is November 7, 1996 and as far as
I know, there has not been any formal announcement of the
members of the IAHC ?
Don Heath, the President of the ISOC has stated that he does
not want to use the open forums of the Internet for IAHC deliberations
because he does not want to "waste people's time". He prefers
to announce conclusions that have been reached by the IAHC.
Has Don considered that he is causing a lot of people's time
to be wasted while everyone dances around the issue of who
is on the IAHC, how they were selected, who selected them,
what is their agenda, etc. etc. ?
Now, most people know that Don is relatively new to the
Internet and just recently became President of the ISOC
last Summer. Have any of the members of the IAHC, who are
familiar with the Internet, pointed out to Don that time will be
SAVED using this wonderful tool to host an open forum ?
Rather than having IHAC members flying to Washington, D.C.
or wherever, the Internet can be used to bring those members
together with other experts in the field to discuss the issues.
Speaking of Washington, D.C., rumor has it that there was
an IAHC meeting this week.
Is that true ?
Did you attend ?
If so, are there meeting notes ?
Do you have a list of the IHAC members ?
In summary, why hasn't the Internet been used as a tool to
get things moving with the IAHC ? Why haven't the organizations
that have appointed members used the Internet to notify people?
You point out that you were selected by the IANA (Jon Postel
and Joyce Reynolds). Why hasn't the IANA used the Internet
to notify people ?
I must say that I take my hat off to Brian Carpenter of the IAB,
who after some discussion finally came forward with their
appointments.
I guess my bottom line question is...
Is there any reason why this is taking so long and
why the Internet is NOT being used effectively...?
----------
From: Brian Carpenter CERN-CN[SMTP:brian at dxcoms.cern.ch]
Sent: Thursday, November 07, 1996 2:38 AM
To: Jim Fleming
Cc: iab at isi.edu; newdom at vrx.net
Subject: Re: IAB and the IAHC
Jim,
>--------- Text sent by Jim Fleming follows:
>
> On Thursday, November 07, 1996 2:13 AM, Brian Carpenter CERN-CN[SMTP:brian at dxcoms.cern.ch] wrote:
> @ Jim,
> @
> @ Please address the iab at our email address, iab at iab.org
> @ in future.
> @
> @ > Can members of the IAB clarify the role of the IAB
> @ > and the IAHC...?
> @
> @ The IAB is collegial. Please don't ask for the members
> @ to reply as individuals.
> @
>
> I see. Should we conclude that you are speaking
> for all of the members ?
I always try to indicate clearly when something is my
personal opinion or when it is an IAB consensus. But my
previous message was purely factual in any case.
>
> @ The role of the IAB with respect to the IAHC is
> @ explained in draft-postel-iana-itld-admin-02.txt
> @
> @ >
> @ > Did the IAB approve the members of the IAHC...?
> @
> @ We appointed two members, as explained in
> @ draft-postel-iana-itld-admin-02.txt
> @
>
> Can you tell people who those members are...?
It's no secret:
The IAB considered more than 14 possible candidates
from 10 different countries for the two slots
it was requested to fill on the IAHC, and after
intensive discussion and several rounds of ballotting,
the two candidates nominated by the IAB are
Geoff Huston
Hank Nussbacher
-- Brian Carpenter
----------
From: Brian Carpenter CERN-CN[SMTP:brian at dxcoms.cern.ch]
Sent: Thursday, November 07, 1996 3:09 AM
To: Jim Fleming
Cc: iab at isi.edu; newdom at vrx.net
Subject: Re: IAB and the IAHC
Jim,
>
> Thanks for the update. I am a little surprised that
> people have not announced the complete list of
> IAHC members via the Internet.
I have made this point myself to Don Heath who is
acting as convenor of the IAHC.
>
> Also, can we assume that the 14 candidates, and 10
> countries, and the minutes of the discussions
> as well as the balloting will all be made part of
> the public record according to the guidelines in...?
>
> @@@@@ ftp://ds.internic.net/rfc/rfc2026.txt
>
No, we decided to keep the names confidential, in
line with the guidelines in rfc2027, which were
thoroughly discussed in poised95.
My personal opinion: if we ever have to do it again, we should
also make an open call for nominations, again as in rfc2027.
We were under deadline pressure this time, so we couldn't
consider this.
Brian Carpenter
@@@@@@
--
Jim Fleming
UNETY Systems, Inc.
Naperville, IL
e-mail:
JimFleming at unety.net
JimFleming at unety.net.s0.g0 (EDNS/IPv8)
Received: from ietf.org by ietf.org id aa16927; 7 Nov 96 14:34 EST
Received: from taunivm.tau.ac.il by ietf.org id aa16797; 7 Nov 96 14:33 EST
Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 5968; Thu, 07 Nov 96 21:11:13 IST
Received: from VM.TAU.AC.IL (NJE origin HANK at TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0414; Thu, 7 Nov 1996 21:11:13 +0200
Date: Thu, 07 Nov 96 21:09:57 IST
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.tau.ac.il>
Subject: Re: The cartel begins to crumble?
To: Karl Denninger <karl at mcs.net>,
Hank Nussbacher <HANK at vm.biu.ac.il>
cc: ietf at ietf.org
In-Reply-To: Message of Thu, 7 Nov 1996 10:19:02 -0600 (CST) from
<karl at Mcs.Net>
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611071433.aa16797 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Thu, 7 Nov 1996 10:19:02 -0600 (CST) you said:
>> >Zones are transferrable. Its easily arguable that this is a self-healing
>> >problem to a large extent. A dead registry is going to be a tangible, and
>> >valuable, asset (assuming it has registrants in it -- if not the entire
>> >discussion is moot and irrelavent).
>>
>> Company A sells DNs in their new .biz domain for a $200 one time
>> fee (forever). Three years later they go bankrupt. Company B
>> comes along and is willing to take over the .biz domain but
>> cannot charge any existing customers since they have a piece of
>> paper stating that their domain is cost free forever.
>>
>> An orphaned registry is only valuable if it has enough critical
>> mass and many paying customers.
>
>Bad assumption.
>
>If a TLD is desirable, it will have NEW customers.
>
>If it has no customers, there is no disruption when it disappears.
What do you do with the 100 or so unlucky customers that did sign
up and pay with the "undesirable" TLD that went down the sinkhole?
Do we need to care about them, or just forget it as noise and move on?
Hank
>
>--
>--
>Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
>http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
> | 32 Analog Prefixes, 13 ISDN, Web servers $75/mo
>Voice: +1 312 803-MCS1 x219| Email to "info at mcs.net" WWW: http://www.mcs.net/
>Fax: +1 312 248-9865 | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
>
Received: from ietf.org by ietf.org id aa17670; 7 Nov 96 14:49 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa17574; 7 Nov 96 14:48 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id OAA17494; Thu, 7 Nov 1996 14:47:05 -0500
Message-Id: <199611071947.OAA17494 at black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Phill Kelley <Phill.Kelley at aspect.com.au>
Cc: ietf at ietf.org
Subject: Re: The price of chatter
In-Reply-To: Your message of "Wed, 06 Nov 1996 23:13:00 PST."
<v03007806aea7343c55f8 at [137.76.60.51]>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <v03007806aea7343c55f8 at [137.76.60.51]>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-803792452P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 07 Nov 1996 14:47:03 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-803792452P
Content-Type: text/plain; charset=us-ascii
On Wed, 06 Nov 1996 23:13:00 PST, you said:
> Before I follow this group who have voted with their e-feet, I want to ask
> if it is possible to be subscribed only to the RFC announcements, without
> the RFC drafts and without the general discussion?
Well.. ietf-announce carries a blurb when new drafts are posted. I dont
know of anyplace where *only* RFC announcements are made. I've seen 109
postings to the ietf-announce list since Oct 23, for whatever that is worth.
That compares to 252 on the main IETF list in the same timespan.
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-803792452P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMoI8tdQBOOoptg9JAQEIFgQAkdzv/GH3mNcHPbmoam11I+UvfTyy/fOU
rc4o0Qy5K0L/r89MB+SwAF/50UwjJ66rDsZt0iRIRapeirmlJ/H/dWm0tERumfs4
ObIYZo/Qk4DhBJK0BCMhtT6zlvH9i0A5FNl/5G1hKkKTN0EucrDxPZVwx9uGvbug
zn/w90JsaVg=
=neOI
-----END PGP MESSAGE-----
--==_Exmh_-803792452P--
Received: from ietf.org by ietf.org id aa18109; 7 Nov 96 14:54 EST
Received: from taunivm.tau.ac.il by ietf.org id aa18027; 7 Nov 96 14:53 EST
Received: from VM.TAU.AC.IL by VM.TAU.AC.IL (IBM VM SMTP V2R2)
with BSMTP id 6043; Thu, 07 Nov 96 21:31:34 IST
Received: from VM.TAU.AC.IL (NJE origin HANK at TAUNIVM) by VM.TAU.AC.IL (LMail V1.2a/1.8a) with BSMTP id 0604; Thu, 7 Nov 1996 21:31:14 +0200
Date: Thu, 07 Nov 96 21:24:03 IST
Sender:ietf-request at ietf.org
From: Hank Nussbacher <HANK at vm.tau.ac.il>
Subject: Re: IAHC
To: Karl Denninger <karl at mcs.net>,
Hank Nussbacher <HANK at vm.biu.ac.il>
cc: ietf at ietf.org
In-Reply-To: Message of Thu, 7 Nov 1996 10:22:50 -0600 (CST) from
<karl at Mcs.Net>
MIME-Version: 1.0
Content-Type: Text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Message-ID: <9611071453.aa18027 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
On Thu, 7 Nov 1996 10:22:50 -0600 (CST) you said:
>How did the COMMITTEE get the authority?
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.
