[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
If you mean to say that "Existing holders of network address
assignment don't pay a fee, ever.", then simply say so in your
document. It isn't hard; I'll even type the html for you, and save
your registry some expense.
<P>
<STRONG>
Existing holders of network address assignment don't pay a fee, ever.
</STRONG>
Received: from ietf.org by ietf.org id aa17939; 8 Jan 97 21:51 EST
Received: from cnri by ietf.org id aa17851; 8 Jan 97 21:49 EST
Received: from mailhost1.cac.washington.edu by CNRI.Reston.VA.US id aa28449;
8 Jan 97 21:49 EST
Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58])
by mailhost1.cac.washington.edu (8.8.4+UW96.12/8.8.4+UW96.12) with SMTP
id SAA29673; Wed, 8 Jan 1997 18:47:00 -0800
Date: Wed, 8 Jan 1997 18:45:48 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at tomobiki-cho.cac.washington.edu>
Subject: Re: Just wondering about the silence
To: "David R. Conrad" <davidc at apnic.net>
cc: Valdis.Kletnieks at vt.edu, "David R. Conrad" <davidc at apnic.net>,
Keith Moore <moore at cs.utk.edu>, karl at cavebear.com,
IETF <ietf at CNRI.Reston.VA.US>
In-Reply-To: <199701090033.JAA19970 at moonsky.jp.apnic.net>
Message-ID: <MailManager.852777948.28530.mrc at Tomobiki-Cho.CAC.Washington.EDU>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
The evil naipr at internic.net mailing list bounced my posting, because I "am not
authorized to send mail to it".
This confirms my feeling that it is not an appropriate list for any public
discussion of this issue.
Received: from ietf.org by ietf.org id aa19176; 8 Jan 97 22:06 EST
Received: from cnri by ietf.org id aa18825; 8 Jan 97 22:03 EST
Received: from pax.cavebear.com by CNRI.Reston.VA.US id aa28679;
8 Jan 97 22:03 EST
Received: from localhost by CaveBear.com (SMI-8.6/SMI-SVR4)
id TAA17765; Wed, 8 Jan 1997 19:01:56 -0800
Date: Wed, 8 Jan 1997 19:01:56 -0800 (PST)
Sender:ietf-request at ietf.org
From: Karl Auerbach <karl at cavebear.com>
Reply-To: karl at cavebear.com
To: IETF <ietf at CNRI.Reston.VA.US>
Subject: Summary (and hopeful calming) Was: Re: Just wondering about the silence
In-Reply-To: <Pine.SUN.3.91.970107165402.29986E-100000 at cybercash.com>
Message-ID: <Pine.SOL.3.95.970108184642.17546F-100000 at pax.cavebear.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
I think after the smoke and cinders here's a summary.
(I can't move this to the naipr mailing list because it's list server
seems intent on rejecting all forms of subscription request.)
1. It's become apparent that the ip address charging proposal is not
intended to apply to pre-existing holders of IP address space.
2. It is also apparently the expectation is that there will be fairly few
end-users who obtain allocations, and hence, relatively few people will
bear the higher fee schedule.
3. Under those assumptions, the total revenue stream is significantly more
reasonable. (The magnitude can be small or large, depending on how one
arrives at projections for new allocations.)
4. It would be a useful amendment to the proposal to clearly state those
assumptions.
5. The proposal needs a guiding policy -- I'd suggest the encourgement of
route aggregation.
6. The proposal is a legitimate request to recover legitimate costs.
Assignment of address blocks does have some cost. (The actual amount may
be debatable.)
7. However, there are other groups who incur costs as the result of new
address block assignments (and also by the continuance of non-aggregated
routes). These including the routing arbiters as well as the costs borne
by carriers to equip their core routers with enough memory and horsepower
to cope.
8. These other groups are not compensated by the revenues generated by
this policy.
9. The proposal as it stands has a number of places where it could be
considered biased in favor of large ISPs over small ones and in favor of
ISPs over non-ISPs.
10. Since it is often stated (for example in the recent RFC on address
renumbering) that one does not "own" IP addresses, there is an issue of
how to reconcile the statement that "existing holders do not pay" with the
fact that those holders may be forced to abandon "free" blocks.
--karl--
Received: from ietf.org by ietf.org id aa27529; 8 Jan 97 23:30 EST
Received: from cnri by ietf.org id aa27207; 8 Jan 97 23:17 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa00432; 8 Jan 97 23:17 EST
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA17382 for <@sgi.engr.sgi.com:ietf at nri.reston.va.us>; Wed, 8 Jan 1997 20:15:40 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id VAA15572 for ietf at nri.reston.va.us; Wed, 8 Jan 1997 21:15:35 -0700
Date: Wed, 8 Jan 1997 21:15:35 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199701090415.VAA15572 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: appropriate mailing lists etc.
Source-Info: From (or Sender) name not authenticated.
] > Further dicussions really ought to occur on naipr at internic.net -- the
] > list is managed by listserv, send a message body of help to
] > lists.internic.net to figure out how to subscribe.
]
] That is one of the worst list servers I've ever encountered -- it does not
] send any positive ack.
]
] This is an important issue. It's interesting how the folks who will
] collect the money are trying to hide it and it's effective date.
Until the questions raised have been answer, this issue should be
discussed here, not in some odd corner of a mailing list. Obvious
issues include:
- what is the effective date?
- is this stuff relevant to POISED (or whatever it's called)?
- are there anti-trust implications? This sounds like it could be
viewed as an effort by existing ISP's and registrars to impose
substantial fees on new entrants. Why is that view wrong?
- are the thousands of holders of old class-C's proposed be taxed or
should they be? I'm one. I'd probably be willing to give up my
private class-C to avoid paying a pittance, or even if someone
asked nicely. Note: <<nicely>>.
- what about the corporations with large IP networks behind firewalls?
I know of two Mountain View, California UNIX vendors with big
piles of class C's. I registered a few 100 on behalf of one of
them. Are those outfits to be taxed or not?
- are holders of existing addresses are charged or not? Does it matter
if the addresses are, have been, will be, or might be advertised?
- if existing holders are not to be charged, why not? If I could
convince the big guys to advertise my old class-C, why shouldn't
I have to pay something to someone?
- But why should I have to pay anything to anyone except the ISP that
I deal with?
- what is (are) the charging structure(s) for various sized outfits?
What's this about the size of outfits? Who gets to determine an
outfit's size? I ask that because the old BARRNET and CSNET
fee structures had substantial wealth transfer goals, so it was
important to decide how big your outfit was for the purposes of
connecting to the net, and that size was not necessarily the same
as what the IRS or the stockholders thought.
- how many registeries will there be?
Can we anticipate John Palmer et al setting up their own alternative
North American IP address registeries? Say by buying a block from RIPE?
- who gets the $$$ and for what purposes?
What happened to the money in the previous "infrastructure funds",
both ANS's and NIS's?
- what is that "small annual maintenance fee" in section 2.4 about?
Just how small is small? Computed how?
- just who are the players? Who is pushing this proposal?
I hope this is not a rerun of the NIS or ANS sagas, but from here it
certainly smells similar. Even if you approve of how the NIS saga
happened and its results, it would be wise to at least pretend to get
community-wide consensus.
Maybe those and the other questions raised so far in this thread have
answers that are not controversial. If so, quoting the relevant words
from the proposal(s) would be sufficent. It is not sufficent to assert
that words not present are anwers.
Before complaining that this stuff does not affect Europe and so does
not belong on the main IETF mailing list, please remember that we in
North America listened patiently to the European battles over domain
and IP address registration a few years ago. Note also that what
happens in the U.S. corner of the Internet might have an effect on
Europe.
You really should look at http://rs.internic.net/arin/.
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa28867; 8 Jan 97 23:59 EST
Received: from cnri by ietf.org id aa28755; 8 Jan 97 23:57 EST
Received: from ra4000-p62.qualcomm.com by CNRI.Reston.VA.US id aa01028;
8 Jan 97 23:56 EST
Received: by laptop.ka9q.ampr.org
id m0vi6gZ-000MG3C
(Debian Smail-3.2 1996-Jul-4 #2); Wed, 8 Jan 1997 14:41:27 -0800 (PST)
Message-Id: <m0vi6gZ-000MG3C at laptop.ka9q.ampr.org>
Date: Wed, 8 Jan 1997 14:41:27 -0800 (PST)
Sender:ietf-request at ietf.org
From: Phil Karn <karn at laptop.ka9q.ampr.org>
To: moore at cs.utk.edu
CC: karl at cavebear.com, ietf at CNRI.Reston.VA.US, moore at cs.utk.edu
Reply-To: karn at qualcomm.com
In-reply-to: <199701071951.OAA01621 at ig.cs.utk.edu> (message from Keith Moore
on Tue, 07 Jan 1997 14:51:26 -0500)
Subject: Re: Just wondering about the silence
Source-Info: From (or Sender) name not authenticated.
Just out of curiosity, how is NSI/SAIC going to enforce charges for IP
address blocks? Unlike the DNS root servers they run and/or control,
IP addresses are honored by a lot of backbone routers that they do not
control. What's to keep the net from simply ignoring NSI/SAIC?
Phil
Received: from ietf.org by ietf.org id aa02270; 9 Jan 97 2:07 EST
Received: from cnri by ietf.org id aa01692; 9 Jan 97 1:58 EST
Received: from shell1.aimnet.com by CNRI.Reston.VA.US id aa03057;
9 Jan 97 1:58 EST
Received: from localhost (dwm at localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id WAA06363; Wed, 8 Jan 1997 22:56:51 -0800 (PST)
Date: Wed, 8 Jan 1997 22:56:50 -0800 (PST)
Sender:ietf-request at ietf.org
From: "David W. Morris" <dwm at xpasc.com>
X-Sender: dwm at shell1.aimnet.com
To: Karl Auerbach <karl at cavebear.com>
cc: IETF <ietf at CNRI.Reston.VA.US>, naipr at internic.net
Subject: Re: Just wondering about the silence
In-Reply-To: <Pine.SOL.3.95.970108182048.17546C-100000 at pax.cavebear.com>
Message-ID: <Pine.GSO.3.95.970108225327.4694A-100000 at shell1.aimnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Wed, 8 Jan 1997, Karl Auerbach wrote:
> <P>
> <STRONG>
> Existing holders of network address assignment don't pay a fee, ever.
> </STRONG>
Exactly what is an existing holder ... I paid my former ISP for a ClassC
address ... then they decided to leave the ISP business. DO I have an
IP address to my credit?
I ask this not to get a direct answer but to point out that the situation
is very complex. $2500/year for a ClassC address = 50x the 50 per year
the folks decided to charge for a Domain name. Sure is creative price
escallation.
Dave Morris
Received: from ietf.org by ietf.org id aa08696; 9 Jan 97 9:56 EST
Received: from cnri by ietf.org id aa08211; 9 Jan 97 9:30 EST
Received: from teckla.apnic.net by CNRI.Reston.VA.US id aa10194;
9 Jan 97 9:30 EST
Received: from nostromo.jp.apnic.net (root at dial008.hkt.net [206.161.63.17]) by teckla.apnic.net (8.8.2/8.7.1) with ESMTP id XAA05859; Thu, 9 Jan 1997 23:04:41 +0900 (JST)
Received: from ronin.apnic.net (davidc at localhost [127.0.0.1]) by nostromo.jp.apnic.net (8.7.3/8.7.3) with ESMTP id CAA00866; Thu, 9 Jan 1997 02:01:49 GMT
Message-Id: <199701090201.CAA00866 at nostromo.jp.apnic.net>
To: karl at cavebear.com
cc: IETF <ietf at CNRI.Reston.VA.US>
Subject: Re: Summary (and hopeful calming) Was: Re: Just wondering about the silence
In-reply-to: Your message of "Wed, 08 Jan 1997 19:01:56 PST."
<Pine.SOL.3.95.970108184642.17546F-100000 at pax.cavebear.com>
Date: Thu, 09 Jan 1997 02:01:48 +0000
Sender:ietf-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Source-Info: From (or Sender) name not authenticated.
Karl,
>(I can't move this to the naipr mailing list because it's list server
>seems intent on rejecting all forms of subscription request.)
Sigh.
>1. It's become apparent that the ip address charging proposal is not
>intended to apply to pre-existing holders of IP address space.
Right.
>2. It is also apparently the expectation is that there will be fairly few
>end-users who obtain allocations, and hence, relatively few people will
>bear the higher fee schedule.
Yes, at least that is how things have worked out at both APNIC and RIPE-NCC.
I would be surprised if it was different for the US. If it is however, the
membership will be in a position to modify their policies/procedures as
necessary.
>3. Under those assumptions, the total revenue stream is significantly more
>reasonable. (The magnitude can be small or large, depending on how one
>arrives at projections for new allocations.)
Exactly, and due to the uncertainty over magnitude, I imagine the fees
chosen were done so to be initially consistent with the other registries
with the full expectation that the fees would be adjusted by the membership
based on income/expenses.
>4. It would be a useful amendment to the proposal to clearly state those
>assumptions.
Agreed.
>5. The proposal needs a guiding policy -- I'd suggest the encourgement of
>route aggregation.
On the PAGAN mailing list, there were quite a few suggestions that the
registries should become much more involved in attempting to promote
aggregation. However, at the PAGAN BOF meeting at San Jose, I think it fair
to say the suggestions were roundly trashed -- the problem is that
routability is (almost) exclusively in the domain of the service providers.
This is an on-going discussion and I would recommend anyone interested in
this issue to subscribe (via majordomo, not this fascist listserv stuff :-))
by sending a message body of "subscribe" to pagan-request at apnic.net (BTW:
PAGAN stands for Policies and Guidelines for the Allocation of Network
numbers).
As such, the guiding principle for the registry funding plans has been to
simply derive sufficient money to cover costs. If the Internet community
wishes the registry system to become more involved in aggregation/routability
I believe PAGAN is the appropriate venue to express those interests.
>6. The proposal is a legitimate request to recover legitimate costs.
>Assignment of address blocks does have some cost. (The actual amount may
>be debatable.)
Thank you.
>7. However, there are other groups who incur costs as the result of new
>address block assignments (and also by the continuance of non-aggregated
>routes). These including the routing arbiters as well as the costs borne
>by carriers to equip their core routers with enough memory and horsepower
>to cope.
Agreed, although I'm not sure I see how the "routing arbiters" are affected
-- I suspect its a terminology question. With respect to non-aggregation,
the imposition of fees has proven to discourage organizations from
requesting address blocks directly from the registries. As such the number
of "portable" prefixes allocated has decreased.
>8. These other groups are not compensated by the revenues generated by
>this policy.
The amount and means by which the groups can be compensated would likely be
an "interesting" discussion. I feel it is far more realistic (KISS) to have
the registries simply recover their costs. The route aggregation issue
should be addressed by other mechanisms, such as route settling between
providers.
>9. The proposal as it stands has a number of places where it could be
>considered biased in favor of large ISPs over small ones and in favor of
>ISPs over non-ISPs.
Agreed. However, I would note that (a) it is generally the case that larger
organizations have advantages when it comes to obtaining resources over
smaller organizations, regardless of what the organizations do or the
resources and (b) in the case of APNIC and RIPE-NCC, the definition of an
ISP is anyone who claims to be an ISP (slow-start tends to discourage
organizations who are not ISPs from claiming to be ISPs). APNIC attempts to
handle case (a) by leaving the distinction of "size" entirely up to the
ISP.
>10. Since it is often stated (for example in the recent RFC on address
>renumbering) that one does not "own" IP addresses, there is an issue of
>how to reconcile the statement that "existing holders do not pay" with the
>fact that those holders may be forced to abandon "free" blocks.
Not sure what you mean by the last bit, but yes, I agree there is something
of a contradiction. I tend to view it pragmatically -- there is simply no
other feasible option.
In any event, I don't believe ARIN to be a "finished product" -- there are
all sorts of rough edges and issues that need to be resolved. Assuming the
list server will be cooperative, I imagine (still) these discussions would
be more appropriate on naipr at internic.net.
Regards,
-drc
Received: from ietf.org by ietf.org id aa10294; 9 Jan 97 10:49 EST
Received: from cnri by ietf.org id aa09990; 9 Jan 97 10:44 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa13141; 9 Jan 97 10:44 EST
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA18683 for <@sgi.engr.sgi.com:ietf at nri.reston.va.us>; Thu, 9 Jan 1997 07:42:33 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA16251 for ietf at nri.reston.va.us; Thu, 9 Jan 1997 08:42:27 -0700
Date: Thu, 9 Jan 1997 08:42:27 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199701091542.IAA16251 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Summary (and hopeful calming)
Source-Info: From (or Sender) name not authenticated.
> From: "David R. Conrad" <davidc at apnic.net>
> ...
> Exactly, and due to the uncertainty over magnitude, I imagine the fees
> chosen were done so to be initially consistent with the other registries
> with the full expectation that the fees would be adjusted by the membership
> based on income/expenses.
Exactly who are the people or organizations that constitute this
"membership" that would be adjusting those fees? If the membership is
only the people who collect and spend the fees, why would they pick a
value other than an epsilon smaller than would produce a revolt?
How does this proposal differ from the NIS administration of the .com
domain? Can we anticipate rules concerning trademarks and vanity IP
addresses?
Exactly where is (are) the database(s) whose maintenaince is supported
by these fees, and who is runs it (them)?
Doesn't the IANA "own" all IP addresses, just as it "owns" all TLDs?
Does the IANA support this proposal?
Why shouldn't a multi-registries approach similar to that recently
proposed to handle the TLD problem be applied to IP addresess?
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa12299; 9 Jan 97 11:19 EST
Received: from ietf.ietf.org by ietf.org id aa10539; 9 Jan 97 10:56 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-crocker-wrap-01.txt
Date: Thu, 09 Jan 1997 10:56:49 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701091056.aa10539 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Wrapping MIME Objects: Application/MIME
Author(s) : D. Crocker, L. Lundblade, J. Zawinski
Filename : draft-crocker-wrap-01.txt
Pages : 4
Date : 01/08/1997
MIME permits labeling and aggregating objects into complex hierarchies.
Support for MIME mechanisms is not universal although it is growing
quickly, so that gateways are often required to translate portions of a
MIME object into its constituent pieces, that is, as independent
attachments.
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-crocker-wrap-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-crocker-wrap-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-crocker-wrap-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: <19970108105041.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-crocker-wrap-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-crocker-wrap-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970108105041.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12305; 9 Jan 97 11:19 EST
Received: from ietf.ietf.org by ietf.org id aa10583; 9 Jan 97 10:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: srv-location at tgv.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-svrloc-protocol-15.txt
Date: Thu, 09 Jan 1997 10:56:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701091057.aa10583 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 Service Location Protocol
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Service Location Protocol
Author(s) : J. Veizades, E. Guttman, C. Perkins, S. Kaplan
Filename : draft-ietf-svrloc-protocol-15.txt
Pages : 61
Date : 01/08/1997
The Service Location Protocol provides a scalable framework for the
discovery and selection of network services. Using this protocol,
computers using the Internet no longer need so much static configuration of
network services for network based applications. This is especially
important as computers become more portable, and users less tolerant or
able to fulfill the demands of network system administration.
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-svrloc-protocol-15.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-svrloc-protocol-15.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-svrloc-protocol-15.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: <19970108110448.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-svrloc-protocol-15.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-svrloc-protocol-15.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970108110448.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12311; 9 Jan 97 11:19 EST
Received: from ietf.ietf.org by ietf.org id aa10523; 9 Jan 97 10:56 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-hoffman-mailto-url-00.txt
Date: Thu, 09 Jan 1997 10:56:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701091056.aa10523 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The mailto URL scheme
Author(s) : P. Hoffman, L. Masinter
Filename : draft-hoffman-mailto-url-00.txt
Pages : 4
Date : 01/08/1997
This document defines the format of Uniform Resource Locators (URL) for
designating electronic mail addresses. It is one of a suite of documents
which replace RFC 1738, "Uniform Resource Locators", and RFC 1808,
"Relative Uniform Resource Locators". The syntax of "mailto" URLs from RFC
1738 is extended to allow creation of more RFC 822 messages by allowing the
URL to express additional header and body fields.
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-hoffman-mailto-url-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-hoffman-mailto-url-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-hoffman-mailto-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: <19970108100259.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-hoffman-mailto-url-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hoffman-mailto-url-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970108100259.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12304; 9 Jan 97 11:19 EST
Received: from ietf.ietf.org by ietf.org id aa10713; 9 Jan 97 10:57 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-rfced-info-ryckman-01.txt
Date: Thu, 09 Jan 1997 10:57:12 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701091057.aa10713 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Security Industry Internet Protocol for Alarm
Transmission (SIIPAT)
Author(s) : S. Ryckman
Filename : draft-rfced-info-ryckman-01.txt
Pages : 8
Date : 01/08/1997
This document suggests a method for delivering alarm information over the
Internet. All communication shall use an encryption algorithm for
transmission of the data. An immediate response from the host will be used
for verification of receipt of the message.
This transmission method may be use as a backup transmission method to
traditional dial-up or leased line methods, or as a primary transmission
method with traditional methods becomming the backup.
Due to the required security of the data being transmitted, the encryption
algorithm used will only be released on a need to know basis to software
developers in the Alarm/Security Industry. A non-disclosure agreement will
be required. Terms and conditions of the licensing will depend on the
intended purpose for use and may require a non-competition agreement or
licensing fees.
The Internet Assigned Numbers Authority (IANA) has assigned port 1733
for the registered use of SIIPAT transmissions.
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-rfced-info-ryckman-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rfced-info-ryckman-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rfced-info-ryckman-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: <19970108143703.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rfced-info-ryckman-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rfced-info-ryckman-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970108143703.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12301; 9 Jan 97 11:19 EST
Received: from ietf.ietf.org by ietf.org id aa10697; 9 Jan 97 10:57 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-pppext-eaprsa-03.txt
Date: Thu, 09 Jan 1997 10:57:07 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701091057.aa10697 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 Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP EAP RSA Public Key Authentication Protocol
Author(s) : W. Whelan
Filename : draft-ietf-pppext-eaprsa-03.txt
Pages : 14
Date : 01/08/1997
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authentication its peer
before allowing Network Layer protocols to transmit over the link.
PPP Extensible Authentication Protocol (EAP) [2] provides for a number of
authentication mechanisms. One of these is RSA Public Key Authentication.
This document defines RSA Public Key Authentication Protocol within
PPP EAP.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pppext-eaprsa-03.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eaprsa-03.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-eaprsa-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: <19970108150513.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pppext-eaprsa-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-eaprsa-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970108150513.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa15602; 9 Jan 97 12:21 EST
Received: from ietf.org by CNRI.Reston.VA.US id aa16279; 9 Jan 97 12:21 EST
Received: from ietf.org by ietf.org id aa15580; 9 Jan 97 12:21 EST
Received: from cornpuffs.cisco.com by ietf.org id aa15557; 9 Jan 97 12:21 EST
Received: (rja at localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id JAA26813; Thu, 9 Jan 1997 09:19:06 -0800
Date: Thu, 9 Jan 1997 09:19:06 -0800
Message-Id: <199701091719.JAA26813 at cornpuffs.cisco.com>
To: ietf at ietf.org
Subject: Re: I-D ACTION:draft-rfced-info-ryckman-00.txt
In-Reply-To: <3.0.32.19970108125235.00683de8 at apocalypse.org>
Sender:iesg-request at ietf.org
From: Ran Atkinson <rja at inet.org>
Organization: The Internet
RE: draft-rfced-info-ryckman-00.txt
At 11:51 AM 1/8/97 -0500, Perry E. Metzger wrote:
>I tend to agree with Rens that the draft seems, er, misguided. As soon
>as I saw it I wrote to SAAG and Jeff Schiller since it might logically
>fall into security area considerations.
In article <3.0.32.19970108125235.00683de8 at apocalypse.org> John Romkey wrote:
>I have to strongly agree.
>
>"Due to the required security of the data being transmitted, the encryption
>algorithm must be openly specified and available for review by the
>community at large." would be much more appropriate.
Agreed. See also below on algorithm-independence.
I'd also urge a comment along the lines of:
Strength of the cryptosystem is believed to lie in the strength
and confidentiality of the keys rather than in the confidentiality of
the cryptographic algorithm itself. [paraphrased from Kahn]
>Secret algorithms do not benefit anyone but the secret holders. Any
>security algorithms or techniques for use in the Internet standards process
>should by necessity be openly and clearly specified. If they're so weak
>that discussing them openly puts them at risk of being broken then they're
>inappropriate for use in any setting, let alone the Internet. If they are
>that weak, best it's found out now rather than later after they're widely
>deployed. Security through obscurity is no security at all.
Moreover, I'd argue that the IETF should generally standardise
algorithm-independent security mechanisms. Algorithm-independent mechanisms
let users tune the strength of provided security to their threat environment.
Such mechanisms also mean that if a major breakthrough in cryptanalysis should
appear in the public literature, the IETF could easily move to a new/better
cryptographic algorithm.
>Furthermore, I think that it's highly inappropriate for any
>Internet-related standards documents to specify that an NDA needs to be
>signed in order find out enough informaiton to implement the protocol they
>specify.
I infer from the I-D title that this draft probably is not intended
for standards status. Still, I believe that an IESG comment noting the lack
of standards status and noting the technical issues raised here should be
placed in this draft prior to publication.
Ran
rja at inet.org
Received: from ietf.org by ietf.org id aa20181; 9 Jan 97 13:12 EST
Received: from cnri by ietf.org id aa19924; 9 Jan 97 13:09 EST
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa17778;
9 Jan 97 13:09 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.4/8.8.4) with ESMTP
id NAA31160; Thu, 9 Jan 1997 13:07:30 -0500
Message-Id: <199701091807.NAA31160 at black-ice.cc.vt.edu>
X-Mailer: exmh version 2.0beta 12/23/96
To: naipr at internic.net
Cc: "David R. Conrad" <davidc at apnic.net>, Keith Moore <moore at cs.utk.edu>,
karl at cavebear.com, IETF <ietf at CNRI.Reston.VA.US>
Subject: Re: Just wondering about the silence
In-Reply-To: Your message of "Thu, 09 Jan 1997 08:37:45 +0900."
<199701082337.IAA19595 at moonsky.jp.apnic.net>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199701082337.IAA19595 at moonsky.jp.apnic.net>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-126553950P";
micalg=pgp-md5; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 09 Jan 1997 13:07:30 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-126553950P
Content-Type: text/plain; charset=us-ascii
On Thu, 09 Jan 1997 08:37:45 +0900, "David R. Conrad" said:
> Valdis,
> >Is there really 10 hours a week of work involved in maintaining 1 /16?
>
> Maintaining, no. Reviewing justifying documentation, discussing the
> request with the requestor, teaching them how to decribe their network
> in a way the registry can understand, explaing CIDR to them, telling
> them that yes, most router vendors support supernetting, subnetting,
> and variable length subnet masks, and no, they can use a subnet mask
> of 255.255.255.0 for 2 hosts, explaining why they can't simply pay $X
> and not have to go through this justification rigamarole, yes.
Please decouple your *REGISTRY* fees for acutally registering it
from your consulting fees.
(As an aside, are you saying "yes they can", or "no they cant"? Who
ever had a problem with 255.255.255.0 as a subnet mask for 2 hosts?
The only "gotcha" here is that 255.255.255.254 isn't usable, you have
to drop back to 255.255.255.252 because of the all-zeros and all-ones
addresses)
> >If $50/year for a domain registration is
> >considered "high", what are *these* (given that I don't see much technical
> >difference between the amount of work needed for the 2 registries)?
>
> Yeah, right. There is no difference in explaining CIDR to a newbie
> and explaining why they have to have a secondary line on their domain
> name request. Perhaps you should work in a registry for a while
> before making assumptions about how much work it entails?
OK. I don't work in a registry. However, I've worked in system
support since 1982, and had to explain both nameservers and
subnetting/CIDR multiple times, both to end users and to our User
Services staffers.
Let's do some simple math.
A domain registration costs $50. Now, let's say that of that, $25 is
actually doing the registration, and $25 is covering your education costs.
Now, let's say that of the $2,500 *minimum* you wish to charge, $50 goes
to actually doing the registration. This means that you are charging
$2,450 dollars to explain CIDR. Are you saing that CIDR is on the order
of 100 times more complicated to explain than secondary nameservers?
Hell, *INTEROP* doesn't charge that for a 3 day tutorial.
I won't comment on the wisdom of charging MIT $2,559,950 to explain
CIDR to them. I strongly suspect that they already understand.
> >Anybody want to place bets whether MIT will shell out $2.56M for its
> >18.x.x.x net? ;)
>
> Irrelevant.
Not at *ALL* irrelevant. Our organization stands to get nailed for at
least 2 /16s.. We're not an ISP. We don't need lectures on CIDR. We don't
need to get charged $20K for registry fees.
I just poked 'whois' for the nets between 1.0.0.0 and 126.0.0.0.
After filtering out the reserved ones, and the people on net 24, there
are 43 organizations that seem to have class A address spaces between
3.x.x.x and 57.x.x.x (list appended). Which of them are ISP's and
only pay $20K, and which will be socked for $2.5M? And how many of
the organizations on the attached list need any education?
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--- list of addresses follows
General Electric Company (NET-GE-INTERNET) GE-INTERNET 3.0.0.0
BBN Planet (NET-SATNET) SATNET 4.0.0.0
Army Information Systems Center (NET-YPG-NET) YUMA-NET 6.0.0.0
Bolt Beranek and Newman Inc. (NET-BBN-NET-TEMP) BBNCCNET 8.0.0.0
IBM Corporation (NET-IBM) IBM 9.0.0.0
DoD Intel Information Systems (NET-DODIIS) DODIIS 11.0.0.0
AT&T ITS (NET-ATT) ATT 12.0.0.0
Xerox Palo Alto Research Center (NET-XEROX-NET) XEROX-NET 13.0.0.0
Public Data Network (NET-PDN) PDN 14.0.0.0
Hewlett-Packard Company (NET-HP-INTERNET) HP-INTERNET 15.0.0.0
Digital Equipment Corporation (NET-DEC-INTERNET) DEC-INTERNET 16.0.0.0
Apple Computer, Inc. (NET-APPLE-WWNET) APPLE-WWNET 17.0.0.0
Massachusetts Institute of Technology (NET-MIT-TEMP) MIT 18.0.0.0
Ford Motor Company (NET-FINET) FINET 19.0.0.0
Computer Sciences Corporation (NET-CSC) CSC 20.0.0.0
DDN-RVN (NET-DDN-RVN) DDN-RVN 21.0.0.0
Defense Information Systems Agency (NET-DISNET) DISNET 22.0.0.0
IANA (NET-DDN-TC-NET) RESERVED-23 23.0.0.0
Royal Signals and Radar Establishment (NET-RSRE-EXP) RSRE-EXP 25.0.0.0
Defense Information Systems Agency (NET-MILNET) MILNET 26.0.0.0
ARPA DSI JPO (NET-DSI-NORTH) DSI-NORTH2 28.0.0.0
Defense Information Systems Agency (NET-MILX25-TEMP) MILX25-TEMP 29.0.0.0
Defense Information Systems Agency (NET-ARPAX25-TEMP) ARPAX25-TEMP 30.0.0.0
Norsk Informasjonsteknologi (NET-NORGESNETT) NORGESNETT 32.0.0.0
DLA Systems Automation Center (NET-DCMC) DCMC 33.0.0.0
Halliburton Company (NET-HALLIBURTON) HALLIBURTON 34.0.0.0
Merit Network Inc. (NET-MERIT) MERIT 35.0.0.0
Stanford University (NET-SU-NET-TEMP) SU-NET-TEMP 36.0.0.0
Performance Systems International (NET-PSINETA) PSINETA 38.0.0.0
Eli Lilly and Company (NET-LILLY-NET) LILLY-NET 40.0.0.0
Japan Inet (NET-JAPAN-A) JAPAN-A 43.0.0.0
Amateur Radio Digital Communications (NET-AMPRNET) AMPRNET 44.0.0.0
Interop Show Network (NET-SHOWNETA) SHOWNETA 45.0.0.0
Bolt Beranek and Newman Inc. (NET-BBNNET) BBNNET 46.0.0.0
Bell-Northern Research (NET-BNR)BNR 47.0.0.0
Prudential Securities Inc. (NET-PRUBACHE) PRUBACHE 48.0.0.0
Department of Social Security of UK (NET-ITSANET) ITSANET 51.0.0.0
E.I. duPont de Nemours and Co., Inc. (NET-DUPONT1) DUPONT1 52.0.0.0
cap debis ccs (NET-DB-NET2) DB-NET2 53.0.0.0
Merck and Co., Inc. (NET-MERCK2)MERCK2 54.0.0.0
Army National Guard Bureau (NET-RCAS2) RCAS 55.0.0.0 - 55.255.255.255
U.S. Postal Service (NET-USPS1) USPS1 56.0.0.0
SITA-Societe Internationale de Telecommunications Aeronautiques (NET-SITA2)
SITA-A 57.0.0.0
--==_Exmh_-126553950P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMtUz39QBOOoptg9JAQEbrgP8C93o0Flgm42gO4Tlhi5ogHRyLuhro6XK
B+Bg+kEot6OODGg9DjN+JvwsVh+O08Ev0l7GpWFaKVwK42RPNsEpwOpsSxgXuFT5
wmXdPgG2ghbb+3AeD16xA/E40ESs5L1wmo1rsNWE96CZroOx3mSae0Gg+x1kF9Ix
OpcgDKHAgPI=
=953q
-----END PGP MESSAGE-----
--==_Exmh_-126553950P--
Received: from ietf.org by ietf.org id aa24347; 9 Jan 97 14:18 EST
Received: from cnri by ietf.org id aa23926; 9 Jan 97 14:12 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa19649;
9 Jan 97 14:12 EST
Received: from brind.isi.edu (old-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA26255>; Thu, 9 Jan 1997 11:10:08 -0800
Sender:ietf-request at ietf.org
From: davidk at isi.edu
Posted-Date: Thu, 9 Jan 1997 11:10:06 -0800 (PST)
Message-Id: <9701091910.AA08308 at brind.isi.edu>
Received: by brind.isi.edu (4.1/4.0.3-6)
id <AA08308>; Thu, 9 Jan 97 11:10:06 PST
Subject: Re: Summary (and hopeful calming)
To: Vernon Schryver <vjs at mica.denver.sgi.com>
Date: Thu, 9 Jan 1997 11:10:06 -0800 (PST)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <199701091542.IAA16251 at mica.denver.sgi.com> from "Vernon Schryver" at Jan 9, 97 08:42:27 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1504
Source-Info: From (or Sender) name not authenticated.
Vernon,
> Vernon Schryver writes :
>
> Why shouldn't a multi-registries approach similar to that recently
> proposed to handle the TLD problem be applied to IP addresess?
IP registries and TLD registries are not quite the same. TLD space is
virtually unlimited (or can be made that way) while IPv4 address space is
certainly not.
While there might be ways to use some of the ideas as developed for the
TLD issues it is rather early to apply them for IP registries. There is
no operational experience with these shared registries at all. I don't
think it is a good idea to start experimenting with the two most
important resources on the Internet at the same time.
The ARIN proposal is more an organizational change within the current
registry for the Americas that will bring the IP registry of the Americas
more in line with what is happening in the rest of the world. Of course
organizational changes have impact on the Internet since people will
certainly behave different when service is not free anymore. However, as
I understand it correctly from Kim Hubbard, the actual allocation
criteria will stay the same.
Bringing competition in the whole scheme might be considered desirable
but that is a global issue and has little to do with an organizational
change happening at the IP registry for the Americas. Please keep these
issues seperate since they are both already complicated enough and
discuss matters related to the ARIN proposal on
<naipr at lists.internic.net> maillist.
David K.
---
Received: from ietf.org by ietf.org id aa26055; 9 Jan 97 14:51 EST
Received: from cs.columbia.edu by ietf.org id aa25831; 9 Jan 97 14:47 EST
Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.3/8.6.6) with ESMTP id OAA11606; Thu, 9 Jan 1997 14:45:14 -0500 (EST)
Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.3/8.6.6) with SMTP id OAA03315; Thu, 9 Jan 1997 14:45:09 -0500 (EST)
X-Orig-Sender: hgs at cs.columbia.edu
Message-ID: <32D54AC4.5A89 at cs.columbia.edu>
Date: Thu, 09 Jan 1997 14:45:08 -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: Ran Atkinson <rja at inet.org>
CC: ietf at ietf.org, sryckman at pobox.com
Subject: Re: I-D ACTION:draft-rfced-info-ryckman-00.txt
References: <199701091719.JAA26813 at cornpuffs.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Ran,
I have the suspicion you are preaching to the choir here. Maybe cc'ing
the author(s) on this exchange would help? (They might even be willing
to go through the normal IETF BOF/WG route...)
Thanks.
Henning
Ran Atkinson wrote:
>
> RE: draft-rfced-info-ryckman-00.txt
>
> At 11:51 AM 1/8/97 -0500, Perry E. Metzger wrote:
> >I tend to agree with Rens that the draft seems, er, misguided. As soon
> >as I saw it I wrote to SAAG and Jeff Schiller since it might logically
> >fall into security area considerations.
>
> In article <3.0.32.19970108125235.00683de8 at apocalypse.org> John Romkey wrote:
> >I have to strongly agree.
> >
> >"Due to the required security of the data being transmitted, the encryption
> >algorithm must be openly specified and available for review by the
> >community at large." would be much more appropriate.
>
> Agreed. See also below on algorithm-independence.
>
> I'd also urge a comment along the lines of:
> Strength of the cryptosystem is believed to lie in the strength
> and confidentiality of the keys rather than in the confidentiality of
> the cryptographic algorithm itself. [paraphrased from Kahn]
>
> >Secret algorithms do not benefit anyone but the secret holders. Any
> >security algorithms or techniques for use in the Internet standards process
> >should by necessity be openly and clearly specified. If they're so weak
> >that discussing them openly puts them at risk of being broken then they're
> >inappropriate for use in any setting, let alone the Internet. If they are
> >that weak, best it's found out now rather than later after they're widely
> >deployed. Security through obscurity is no security at all.
>
> Moreover, I'd argue that the IETF should generally standardise
> algorithm-independent security mechanisms. Algorithm-independent mechanisms
> let users tune the strength of provided security to their threat environment.
> Such mechanisms also mean that if a major breakthrough in cryptanalysis should
> appear in the public literature, the IETF could easily move to a new/better
> cryptographic algorithm.
>
> >Furthermore, I think that it's highly inappropriate for any
> >Internet-related standards documents to specify that an NDA needs to be
> >signed in order find out enough informaiton to implement the protocol they
> >specify.
>
> I infer from the I-D title that this draft probably is not intended
> for standards status. Still, I believe that an IESG comment noting the lack
> of standards status and noting the technical issues raised here should be
> placed in this draft prior to publication.
>
> Ran
> rja at inet.org
--
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 cnri by ietf.org id aa26920; 9 Jan 97 15:11 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21775;
9 Jan 97 15:11 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <RAA05401 at pad-thai.cam.ov.com>; Thu, 9 Jan 1997 17:56:32 GMT
Message-Id: <199701091756.MAA14001 at gza-client1.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Reminder: ftpsec-09 WG Last-Call expiring 10 January
Date: Thu, 09 Jan 1997 12:56:25 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
------- Forwarded Message
Received: from gza-client1.cam.ov.com by pad-thai.cam.ov.com (8.7.5/) with SMTP
id <OAA08657 at pad-thai.cam.ov.com>; Mon, 16 Dec 1996 14:09:51 GMT
Received: from localhost by gza-client1.cam.ov.com (8.6.10/4.7) id JAA26487; Mon, 16 Dec 1996 09:09:51 -0500
Message-Id: <199612161409.JAA26487 at gza-client1.cam.ov.com>
To: cat-ietf at mit.edu
cc: linn at cam.ov.com
Subject: WG Last-Call: draft-ietf-cat-ftpsec-09.txt
Date: Mon, 16 Dec 1996 09:09:50 -0500
From: John Linn <linn at cam.ov.com>
CAT/FTPsec fanciers:
Per discussion at last week's IETF meeting, this message is to
declare a WG Last-Call on draft-ietf-cat-ftpsec-09.txt, targeting
a recommendation of advancement to Proposed Standard. Given the
upcoming holiday period, I'm extending the customary WG Last-Call
period for this case to Friday, 10 January 1997.
- --jl
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa29244; 9 Jan 97 15:40 EST
Received: from cnri by ietf.org id aa28646; 9 Jan 97 15:36 EST
Received: from mail1.digital.com by CNRI.Reston.VA.US id aa22548;
9 Jan 97 15:35 EST
Received: from bindmaster.zko.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
id AA32316; Thu, 9 Jan 1997 12:06:14 -0800
Received: from samson by zkons1.zko.dec.com; (5.65v3.2/1.1.8.2/28Oct95-0953AM)
id AA13237; Thu, 9 Jan 1997 15:00:38 -0500
Received: from localhost by samson.zko.dec.com; (5.65/1.1.7.2/16Nov94-0157PM)
id AA21132; Thu, 9 Jan 1997 15:00:12 -0500
Message-Id: <9701092000.AA21132 at samson.zko.dec.com>
To: cabernet-events at ncl.ac.uk, cellular at dfv.rwth-aachen.edu,
cnom at maestro.bellcore.com, commsoft at cc.bellcore.com,
comsoc.bog at tab.ieee.org, comsoc-gicb at ieee.org, comsoc.tac at tab.ieee.org,
comsoc-tcii at ieee.com, comswtc at gmu.edu, cost237-transport at comp.lancs.ac.uk,
ctc-members at redbank.tinac.com, dbworld at cs.wisc.edu, enternet at bbn.com,
giga at tele.pitt.edu, globecom at signet.com.sg, hipparch at sophia.inria.fr,
ieeetcpc at ccvm.sunysb.edu, ieee.announce at bellcore.com,
ietf at CNRI.Reston.VA.US, ifip-nm at bbn.com, isadsoc at fokus.gmd.de,
itc at fokus.gmd.de, kuvs-elg at fokus.gmd.de, multicomm at cc.bellcore.com,
nmf-members at nmf.com, osimcast at bbn.com, reres at laas.fr,
sc6wg4 at ntd.comsat.com, sigmedia at bellcore.com, sig-dsm at doc.ic.ac.uk,
testnet at canarie.ca, tccc at cs.umass.edu, xtp-relay at cs.concordia.ca
Cc: dec_wireless at samson.zko.dec.com,
"pradeepb at microsoft.com"@us2rmc.enet.dec.com
Subject: CFP - Special issue on Mobile Multimedia Communication (ACM MONET)
Date: Thu, 09 Jan 97 15:00:12 -0500
Sender:ietf-request at ietf.org
From: "Victor Bahl, (603) 881-2321" <bahl at samson.zko.dec.com>
X-Mts: smtp
Source-Info: From (or Sender) name not authenticated.
...Please accept our apologies if you get this mail multiple times...
As a reminder, the call-for-papers for a special issue of ACM
MONET on mobile multimedia communications is attached. We hope you
will submit your contributions for consideration.
(This CFP was previously mailed in September 1996)
Thanks.
+----------------------------------------------------------------------
Dear Mobile Experts:
We invite you to submit research papers for consideration
to be published in a special issue of the ACM Mobile Networks and
Applications Journal on "Mobile Multimedia Communications". We
are soliciting papers that address a wide variety of problems
ranging from low-bit rate video codec design to mobility management,
transmission protocols, and mobile-aware applications.
The URL version of the attached CFP is available @:
http://www.baltzer.nl/nomad/nomad.html#calls
or http://bcn.bu.edu/monet_cfp.html
Thanks,
Victor Bahl
Guest Editor, ACM MONET Journal
Digital Equipment Corporation
+-----
CALL FOR PAPERS
Baltzer Science Publishers in cooperation with ACM announce a
special issue of The Mobile Networks and Applications Journal
on
MOBILE MULTIMEDIA COMMUNICATIONS
with guest editors
Victor Bahl, Hamid Aghvami Fumio Watanabie
Digital Equipment King's College London Kokusai Denshin Denwa
Corporation, USA London, U.K. Co., Ltd (KDD), Japan
OVERVIEW
Few subjects have attracted as much attention in engineering and computer
science in the recent years as have multimedia communications and mobile
networking. Propelled by the powerful vision of being able to communicate
from anywhere at anytime with anytype of data, a natural meshing between
these two fields has been in progress these past few years. The symbiosis
that has lead to research in mobile multimedia communications has brought
with it an interesting and unique set of challenges. While on one hand
researchers work towards providing traditional wireline multimedia services
over wireless channels with a level of service that will please even the
most skeptic consumers, on the other hand, there has been an emergence of
new opportunites as mobile specific multimedia services suitable and
desirable only for the mobile enviornment have risen.
TOPICS
The aim of this issue is to focus attention on the fundamental problems and
potential solutions for creating mobile multimedia networks. Since robust
mobile multimedia communications (real-time and otherwise) is possible when
applications, operating systems and networks cooperate with one another,
prospective authors are invited to submit papers on topics related to such
issues and ones that specifically address the communications aspect. Papers
that provide insights into the simultaneous support of voice, data and
digital video and the innovative use of such technologies are particularly
encourged. Possible topics include but are not limited to:
A) Network
* Network architectures for wireless multimedia
* Protocols for simultaneous support of voice, video, and data
* Media access control for integrated services
* Internetworking with high speed networks
* Flow-control and handover
* Intelligent network which supports mobile multimedia service
* SMS (Service Management System) for mobile multimedia
* Security issues for wireless multimedia services
B) Transmission
* Performance of multimedia on Mobile-IP, CDPD, GSM, etc
* Error tolerance, recovery, and concealment in wireless visual
communications
* Bandwidth allocation, reservation, and guarantees for multi-rate
traffic
* Scheduling of real-time and non-real time multimedia traffic over radio
networks
* Ad-hoc and multi-hop mobile multimedia radio networks
* Video codecs for the wireless environment
* Broadcasting techniques for wireless multimedia service
C) Services and Application
* Support of integrated services via wireless ATM
* Mobile aware multimedia applications
* Algorithms for admission control with QoS guarantees
* Service integration with existing terrestrial multimedia services
D) Software
* Software issues for mobile multimedia
* Mobile Agent and its application
E) Mobile Terminals
* Reconfigurable terminals
* Software and hardware design and implementation.
SUBMISSION and SCHEDULE
Researchers and practitioners are invited to submit original, unpublished,
and thought provoking research articles for consideration. All articles will
be evaluated on the basis of technical content, originality, and relevance.
Authors should email an electronic Postscript copy of their paper to one of
the guest editors by February 15, 1997. Submissions should be limited to 20
double spaced pages, excluding figures, graphs, and illustrations. If email
submission is impossible, then six (6) copies of the paper (double-sided if
possible) should be sent by the due date to one of the guest editors.
Commitment notification is anticipated for June 1, 1997. The anticipated
publication date for this issue is 4th Quarter, 1997.
MANUSCRIPT DUE: February 15, 1997
ACCEPTANCE NOTIFICATION: June 1, 1997
FINAL MANUSCRIPT DUE: August 1, 1997
GUEST EDITORS
Victor Bahl Hamid Aghvami
Video Codecs & Mobile Department of Electrical and
Computing Laboratory Electronic Engineering
Digital Equipment Corporation King's College London
110 Spitbrook Road, ZK1-1/E37 Strand
Nashua, NH 03062, U.S.A London WC2R2LS, U. K
Tel: 603 881 0331 Tel: +44 171 873 2898
Fax: 603 881 0585 Fax: +44 171 873 2664
bahl at crl.dec.com h.aghvami at bay.cc.kcl.ac.uk
Fumio Watanabe
Mobile Communications Laboratory
Kokusai Denshin Denwa Co., Ltd. (KDD)
2-1-15 Ohara Kamifukuoka-shi,
SAITAMA 356 Japan
Tel: +81 492 78 7860
Fax: +81 492 78 7521
watanabe at lab.kdd.co.jp
----------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa02757; 9 Jan 97 16:28 EST
Received: from cnri by ietf.org id aa02419; 9 Jan 97 16:24 EST
Received: from jazz.internic.net by CNRI.Reston.VA.US id aa23972;
9 Jan 97 16:24 EST
Received: (kimh at localhost) by jazz.internic.net (8.8.3/SLAM-1) id QAA29871; Thu, 9 Jan 1997 16:28:52 -0500 (EST)
Sender:ietf-request at ietf.org
From: Kim Hubbard <kimh at internic.net>
Message-Id: <199701092128.QAA29871 at jazz.internic.net>
Subject: Re: Just wondering about the silence
To: Valdis.Kletnieks at vt.edu
Date: Thu, 9 Jan 1997 16:28:52 -0500 (EST)
Cc: naipr at internic.net, davidc at apnic.net, moore at cs.utk.edu,
karl at cavebear.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <199701091807.NAA31160 at black-ice.cc.vt.edu> from "Valdis.Kletnieks at vt.edu" at Jan 9, 97 01:07:30 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
> >
>
Valdis,
> Not at *ALL* irrelevant. Our organization stands to get nailed for at
> least 2 /16s.. We're not an ISP. We don't need lectures on CIDR. We don't
> need to get charged $20K for registry fees.
Is Virginia Tech planning on requesting an additional /15? If not, than
they won't be charged a registration fee since the proposal is only
for *new* registrations.
>
> I just poked 'whois' for the nets between 1.0.0.0 and 126.0.0.0.
> After filtering out the reserved ones, and the people on net 24, there
> are 43 organizations that seem to have class A address spaces between
> 3.x.x.x and 57.x.x.x (list appended). Which of them are ISP's and
> only pay $20K, and which will be socked for $2.5M? And how many of
> the organizations on the attached list need any education?
Again, these are grandfathered.
Regards,
Kim Hubbard
>
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
>
> --- list of addresses follows
> General Electric Company (NET-GE-INTERNET) GE-INTERNET 3.0.0.0
> BBN Planet (NET-SATNET) SATNET 4.0.0.0
> Army Information Systems Center (NET-YPG-NET) YUMA-NET 6.0.0.0
> Bolt Beranek and Newman Inc. (NET-BBN-NET-TEMP) BBNCCNET 8.0.0.0
> IBM Corporation (NET-IBM) IBM 9.0.0.0
> DoD Intel Information Systems (NET-DODIIS) DODIIS 11.0.0.0
> AT&T ITS (NET-ATT) ATT 12.0.0.0
> Xerox Palo Alto Research Center (NET-XEROX-NET) XEROX-NET 13.0.0.0
> Public Data Network (NET-PDN) PDN 14.0.0.0
> Hewlett-Packard Company (NET-HP-INTERNET) HP-INTERNET 15.0.0.0
> Digital Equipment Corporation (NET-DEC-INTERNET) DEC-INTERNET 16.0.0.0
> Apple Computer, Inc. (NET-APPLE-WWNET) APPLE-WWNET 17.0.0.0
> Massachusetts Institute of Technology (NET-MIT-TEMP) MIT 18.0.0.0
> Ford Motor Company (NET-FINET) FINET 19.0.0.0
> Computer Sciences Corporation (NET-CSC) CSC 20.0.0.0
> DDN-RVN (NET-DDN-RVN) DDN-RVN 21.0.0.0
> Defense Information Systems Agency (NET-DISNET) DISNET 22.0.0.0
> IANA (NET-DDN-TC-NET) RESERVED-23 23.0.0.0
> Royal Signals and Radar Establishment (NET-RSRE-EXP) RSRE-EXP 25.0.0.0
> Defense Information Systems Agency (NET-MILNET) MILNET 26.0.0.0
> ARPA DSI JPO (NET-DSI-NORTH) DSI-NORTH2 28.0.0.0
> Defense Information Systems Agency (NET-MILX25-TEMP) MILX25-TEMP 29.0.0.0
> Defense Information Systems Agency (NET-ARPAX25-TEMP) ARPAX25-TEMP 30.0.0.0
> Norsk Informasjonsteknologi (NET-NORGESNETT) NORGESNETT 32.0.0.0
> DLA Systems Automation Center (NET-DCMC) DCMC 33.0.0.0
> Halliburton Company (NET-HALLIBURTON) HALLIBURTON 34.0.0.0
> Merit Network Inc. (NET-MERIT) MERIT 35.0.0.0
> Stanford University (NET-SU-NET-TEMP) SU-NET-TEMP 36.0.0.0
> Performance Systems International (NET-PSINETA) PSINETA 38.0.0.0
> Eli Lilly and Company (NET-LILLY-NET) LILLY-NET 40.0.0.0
> Japan Inet (NET-JAPAN-A) JAPAN-A 43.0.0.0
> Amateur Radio Digital Communications (NET-AMPRNET) AMPRNET 44.0.0.0
> Interop Show Network (NET-SHOWNETA) SHOWNETA 45.0.0.0
> Bolt Beranek and Newman Inc. (NET-BBNNET) BBNNET 46.0.0.0
> Bell-Northern Research (NET-BNR)BNR 47.0.0.0
> Prudential Securities Inc. (NET-PRUBACHE) PRUBACHE 48.0.0.0
> Department of Social Security of UK (NET-ITSANET) ITSANET 51.0.0.0
> E.I. duPont de Nemours and Co., Inc. (NET-DUPONT1) DUPONT1 52.0.0.0
> cap debis ccs (NET-DB-NET2) DB-NET2 53.0.0.0
> Merck and Co., Inc. (NET-MERCK2)MERCK2 54.0.0.0
> Army National Guard Bureau (NET-RCAS2) RCAS 55.0.0.0 - 55.255.255.255
> U.S. Postal Service (NET-USPS1) USPS1 56.0.0.0
> SITA-Societe Internationale de Telecommunications Aeronautiques (NET-SITA2)
> SITA-A 57.0.0.0
>
>
>
> --==_Exmh_-126553950P
> Content-Type: application/pgp-signature
>
> -----BEGIN PGP MESSAGE-----
> Version: 2.6.2
>
> iQCVAwUBMtUz39QBOOoptg9JAQEbrgP8C93o0Flgm42gO4Tlhi5ogHRyLuhro6XK
> B+Bg+kEot6OODGg9DjN+JvwsVh+O08Ev0l7GpWFaKVwK42RPNsEpwOpsSxgXuFT5
> wmXdPgG2ghbb+3AeD16xA/E40ESs5L1wmo1rsNWE96CZroOx3mSae0Gg+x1kF9Ix
> OpcgDKHAgPI=
> =953q
> -----END PGP MESSAGE-----
>
> --==_Exmh_-126553950P--
>
Received: from ietf.org by ietf.org id aa06816; 9 Jan 97 22:51 EST
Received: from cnri by ietf.org id ab06292; 9 Jan 97 22:38 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa24755; 9 Jan 97 16:52 EST
Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA15836 for <@sgi.engr.sgi.com:ietf at cnri.reston.va.us>; Thu, 9 Jan 1997 13:50:11 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA17521 for ietf at cnri.reston.va.us; Thu, 9 Jan 1997 14:49:54 -0700
Date: Thu, 9 Jan 1997 14:49:54 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199701092149.OAA17521 at mica.denver.sgi.com>
Subject: Re: Summary (and hopeful calming)
Cc: ietf at CNRI.Reston.VA.US
Source-Info: From (or Sender) name not authenticated.
> From: davidk at ISI.EDU
> To: vjs (Vernon Schryver)
> Cc: ietf at cnri.reston.va.us
> > Why shouldn't a multi-registries approach similar to that recently
> > proposed to handle the TLD problem be applied to IP addresess?
>
> IP registries and TLD registries are not quite the same. TLD space is
> virtually unlimited (or can be made that way) while IPv4 address space is
> certainly not.
Really? I thought there were only about a gross of TLD's, even including
the controversial efforts of John Palmer and his friends. Down a level,
don't we still have fewer domains in .com than classical/classful IP
network numbers?
> While there might be ways to use some of the ideas as developed for the
> TLD issues it is rather early to apply them for IP registries. There is
> no operational experience with these shared registries at all. I don't
> think it is a good idea to start experimenting with the two most
> important resources on the Internet at the same time.
You don't figure that imposing fees for IP addresses is as much or as
big an experiment as having more than one domain registry?
> The ARIN proposal is more an organizational change within the current
> registry for the Americas that will bring the IP registry of the Americas
> more in line with what is happening in the rest of the world. Of course
> organizational changes have impact on the Internet since people will
> certainly behave different when service is not free anymore. However, as
> I understand it correctly from Kim Hubbard, the actual allocation
> criteria will stay the same.
Mere organizational changes do not imply imposing new fee structures.
Or do you figure the switch from SRI to NIS has been only an
organizational change?
> Bringing competition in the whole scheme might be considered desirable
> but that is a global issue and has little to do with an organizational
> change happening at the IP registry for the Americas. Please keep these
> issues seperate since they are both already complicated enough and
Please consider why the competition thing was brought into the TLD
business. It was not because 5 or 10 years ago anyone imagined
competition in name registration was other than silly nonsense. The
competition thing is purely a reaction to recent history, to the
actions and inactions of what appears to be the main proponent of the
idea of charging holders of IP addresses. We all remember that the
$50/domain fee was advertised to generate only a pittance, and that the
claims to the contrary were ridiculed. We also remember that trademark
laws were to be applied rationally.
Given history, one should exect plenty of skepticism about the purpose,
advocates, and actual operation of this proposal. That skepticism is
not reduced by statements that are obviously false, whether about the
words in the proposal, the number of TLDs, or the shortage of IP
networks. (I trust the false statements were unintentional.)
> discuss matters related to the ARIN proposal on
> <naipr at lists.internic.net> maillist.
The repeated demands that this stuff be discussed only on a special
mailing list that reportedly does not accept subscribers is not a
confidence builder. I believe that is evidence of other than malice,
but that belief requires a conscious effort.
In principle, charging for services rendered is obviously a good idea.
I've been told privately that people I trust like the basic idea but
that a flawed draft was released prematurely. Based on that, I'll be
quiet. I'll also control my cynical speculations that the next step
will be for someone to implement the premature draft including its fee
structures and send current owners of IP networks bills amounting to
a few $100M, and saying "these are the IETF approved rules; if you
don't like them, complain to the IETF. When the final rules are
approved, we'll of course change, but until then, we must use the
initial rules. And never mind that hell will freeze over we let the
final rules be adopted." (That would not be a naughty thing to do,
but only good business.)
Vernon Schryver, vjs at sgi.com
*$dOI*2z
.pdefaults
.loc-cshrc
.nevotinit
.gamtables
.signature
.sgihelprc
.insightrc
.Xdefaults
Received: from ietf.org by ietf.org id aa13472; 9 Jan 97 23:53 EST
Received: from cnri by ietf.org id aa13208; 9 Jan 97 23:49 EST
Received: from cu.nih.gov by CNRI.Reston.VA.US id aa00934; 9 Jan 97 23:49 EST
To: vjs at mica.denver.sgi.com
cc: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Roger Fajman <RAF at cu.nih.gov>
Date: Thu, 09 Jan 1997 23:44:47 EST
Subject: Re: Summary (and hopeful calming)
Message-ID: <9701092349.aa00934 at CNRI.Reston.VA.US>
Source-Info: From (or Sender) name not authenticated.
(snip)
> > discuss matters related to the ARIN proposal on
> > <naipr at lists.internic.net> maillist.
>
> The repeated demands that this stuff be discussed only on a special
> mailing list that reportedly does not accept subscribers is not a
> confidence builder. I believe that is evidence of other than malice,
> but that belief requires a conscious effort.
(snip)
> Vernon Schryver, vjs at sgi.com
You've said this several times now, so I decided to try to subscribe
to see what the problem is. I had no trouble. Please tell me in
private email what error you got and I will help you get around it.
Here are the results of my attempt to subscribe:
Date: Thu, 9 Jan 1997 23:04:44 -0500
From: "L-Soft list server at InterNIC Registration Services (1.8b)"
<LISTSERV at lists.internic.net>
Subject: Output of your job "RAF"
To: Roger Fajman <RAF at CU.NIH.GOV>
> ok
Confirming:
> SUBSCRIBE NAIPR Roger Fajman
You have been added to the NAIPR list.
Received: from ietf.org by ietf.org id aa19245; 10 Jan 97 5:08 EST
Received: from cnri by ietf.org id aa18751; 10 Jan 97 4:59 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa05903; 10 Jan 97 4:59 EST
Received: from Bill.Simpson.DialUp.Mich.Net (pm002-13.dialip.mich.net [141.211.7.149]) by merit.edu (8.8.4/merit-2.0) with SMTP id EAA17559 for <ietf at CNRI.Reston.VA.US>; Fri, 10 Jan 1997 04:57:26 -0500 (EST)
Date: Fri, 10 Jan 97 09:47:11 GMT
Sender:ietf-request at ietf.org
From: William Allen Simpson <wsimpson at greendragon.com>
Message-ID: <5600.wsimpson at greendragon.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Summary (and hopeful calming)
Source-Info: From (or Sender) name not authenticated.
I've been on the NAIPR list since Tuesday, but it took 4 tries, after
Kim Hubbard announced it on NANOG list Jan 2. It has problems. Others
on the NANOG list had trouble, too, so it's not an isolated incident.
And I needed the "ok ####" confirmation technique, whereas you seem to
have gotten in with just "ok".
Anyway, Kim assures us that although she is going to name the 5 member
board next week, the charter/incorporation is not cast in stone, and
will be modified section by section until we are happy.
> From: Roger Fajman <RAF at cu.nih.gov>
> You've said this several times now, so I decided to try to subscribe
> to see what the problem is. I had no trouble. Please tell me in
> private email what error you got and I will help you get around it.
>
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 aa20269; 10 Jan 97 5:51 EST
Received: from THOR.INNOSOFT.COM by ietf.org id aa20093; 10 Jan 97 5:48 EST
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-8 #8694)
id <01IE070C1W2OA8DQAA at INNOSOFT.COM>; Fri, 10 Jan 1997 02:45:58 -0800 (PST)
Date: Fri, 10 Jan 1997 02:43:57 -0800 (PST)
Sender:ietf-request at ietf.org
From: Ned Freed <Ned.Freed at innosoft.com>
Subject: Re: I-D ACTION:draft-rfced-info-ryckman-00.txt
In-reply-to: "Your message dated Wed, 08 Jan 1997 14:12:45 -0500 (EST)"
<199701081912.AA247490767 at martigny.ai.mit.edu>
To: "Philip J. Nesser II" <pjnesser at martigny.ai.mit.edu>
Cc: John Romkey <romkey at apocalypse.org>, ietf at ietf.org
Message-id: <01IE167QJ0OKA8DQAA at INNOSOFT.COM>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <3.0.32.19970108125235.00683de8 at apocalypse.org>
Source-Info: From (or Sender) name not authenticated.
> > "Due to the required security of the data being transmitted, the encryption
> > algorithm must be openly specified and available for review by the
> > community at large." would be much more appropriate.
> >
> > Secret algorithms do not benefit anyone but the secret holders. Any
> > security algorithms or techniques for use in the Internet standards process
> > should by necessity be openly and clearly specified. If they're so weak
> > that discussing them openly puts them at risk of being broken then they're
> > inappropriate for use in any setting, let alone the Internet. If they are
> > that weak, best it's found out now rather than later after they're widely
> > deployed. Security through obscurity is no security at all.
> >
> > Furthermore, I think that it's highly inappropriate for any
> > Internet-related standards documents to specify that an NDA needs to be
> > signed in order find out enough informaiton to implement the protocol they
> > specify.
> >
> > - john romkey romkey at apocalypse.org
> > http://www.apocalypse.org/pub/u/romkey/
> >
> >
> I normally don't post messages agreeing with others, but John has stated
> the points so clearly that it seems unnecessary to try and rephrase them.
> However, I think that this is such a critical point that I want to
> publically agree.
I also agree, to the point where I don't think this should even be published as
an informational document in its present form. We're in enough trouble with
security issues already, thank you -- we don't need to bless something this
broken with RFC publication. (Remember that RFC carries status regardless of
the document's actual standing.)
Ned
Received: from ietf.org by ietf.org id aa03395; 10 Jan 97 10:02 EST
Received: from ietf.ietf.org by ietf.org id aa01993; 10 Jan 97 9:34 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-rekhter-tagswitch-arch-00.txt
Date: Fri, 10 Jan 1997 09:33:59 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701100934.aa01993 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Tag Switching Architecture - Overview
Author(s) : Y. Rekhter, B. Davie, D. Katz,
E. Rosen, G. Swallow, D. Farinacci
Filename : draft-rekhter-tagswitch-arch-00.txt
Pages : 21
Date : 01/09/1997
This document provides an overview of tag switching. Tag switching is a way
to combine the label-swapping forwarding paradigm with network layer
routing. This has several advantages. Tags can have a wide spectrum of
forwarding granularities, so at one end of the spectrum a tag could be
associated with a group of destinations, while at the other a tag could be
associated with a single application flow. At the same time forwarding
based on tag switching, due to its simplicity, is well suited to high
performance forwarding. These factors facilitate the development of a
routing system which is both functionally rich and scalable. Finally, tag
switching simplifies integration of routers and ATM switches by employing
common addressing, routing, and management procedures.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rekhter-tagswitch-arch-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rekhter-tagswitch-arch-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rekhter-tagswitch-arch-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970109133819.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rekhter-tagswitch-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-tagswitch-arch-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970109133819.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa03879; 10 Jan 97 10:07 EST
Received: from ietf.ietf.org by ietf.org id aa01963; 10 Jan 97 9:33 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-casey-url-ftp-00.txt
Date: Fri, 10 Jan 1997 09:33:53 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701100933.aa01963 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A FTP URL Format
Author(s) : J. Casey
Filename : draft-casey-url-ftp-00.txt
Pages : 5
Date : 01/09/1997
This document defines the format of Uniform Resource Locators (URL)
for the File Transfer Protocol (FTP) using the general URL syntax
defined in RFC xxxx, "Uniform Resource Locators (URL)".
It is a one of a suite of documents which replace RFC 1738,
"Uniform Resource Locators", and RFC 1808, "Relative Uniform
Resource Locators".
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-casey-url-ftp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-casey-url-ftp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-casey-url-ftp-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: <19970109113313.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-casey-url-ftp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-casey-url-ftp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970109113313.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa09245; 10 Jan 97 12:15 EST
Received: from ietf.ietf.org by ietf.org id aa08707; 10 Jan 97 12:05 EST
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: mhtml at segate.sunet.se
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Protocol Action: MIME E-mail Encapsulation of Aggregate Documents,
such as HTML (MHTML) to Proposed Standard
Date: Fri, 10 Jan 1997 12:05:40 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9701101205.aa08707 at ietf.org>
The IESG has approved the following Internet-Drafts as Proposed Standards:
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-03.txt>
3. The MIME Multipart/Related Content-type
<draft-ietf-mhtml-related-00.txt>
These documents are the product of the MIME Encapsulation of Aggregate
HTML Documents Working Group. The IESG contact persons are Keith Moore
and Harald Alvestrand.
Technical Summary
These documents together form a well-defined mechanism for sending
sets of objects that contain pointers to each other, for instance a
Web page with its associated images and sub-pages, in an E-mail
message.
Working Group Summary
There was complete WG consensus on the solution documented here.
Protocol Quality
There is already one implementation that sends and receives such
E-mail messages. Others are planned. The spec has been reviewed for
the IESG by Harald Tveit Alvestrand
Received: from ietf.org by ietf.org id aa09533; 10 Jan 97 12:20 EST
Received: from ietf.ietf.org by ietf.org id aa09362; 10 Jan 97 12:17 EST
To: IETF-Announce: ;
cc: srv-location at tgv.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Service Location Protocol to Proposed Standard
Reply-to: iesg at ietf.org
Date: Fri, 10 Jan 1997 12:17:47 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9701101217.aa09362 at ietf.org>
The IESG has received a request from the Service Location Protocol
Working Group to consider "Service Location Protocol"
<draft-ietf-svrloc-protocol-15.txt> for the status of Proposed
Standard.
This is a revised version of the protocol, covering changes made as a
result of the previous last call AND changes made as a result of recent
interoperability testing. The changes between this version and the
previously last-called version are:
- Lifetime of service registrations are in seconds not minutes.
- Clarification: Strings in the protocol are NOT null terminated.
- Change in the semantics of Scopes: DAs which have a scope do NOT
accept unscoped service registrations or requests. This changed
many explanations and the 'requirements' section.
- Clarification: Language id and Character type MUST be set in
the header.
- The 'recent changes section' from the last call #2 has been
removed.
- 3 typographical errors remain, summarized below in the email.
We request these be changed by the RFC editor rather than
issuing draft 16.
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 January 22, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa09753; 10 Jan 97 12:23 EST
Received: from ietf.ietf.org by ietf.org id aa09603; 10 Jan 97 12:21 EST
To: IETF-Announce: ;
cc: dns-security at tis.com
Sender:ietf-announce-request at ietf.org
From: The IESG <iesg-secretary at ietf.org>
Subject: Last Call: Secure Domain Name System Dynamic Update to Proposed
Standard
Reply-to: iesg at ietf.org
Date: Fri, 10 Jan 1997 12:21:41 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9701101221.aa09603 at ietf.org>
The IESG has received a request from the Domain Name System Security
Working Group to consider "Secure Domain Name System Dynamic Update"
<draft-ietf-dnssec-update-03.txt> for the status of Proposed
Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at ietf.org or ietf at ietf.org mailing lists by January 23, 1997.
Files can be obtained via ftp://ds.internic.net/internet-drafts/<filename>
Received: from ietf.org by ietf.org id aa12325; 10 Jan 97 13:10 EST
Received: from zephyr.isi.edu by ietf.org id aa12146; 10 Jan 97 13:05 EST
Received: from nam.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA13646>; Fri, 10 Jan 1997 10:03:16 -0800
Message-Id: <199701101803.AA13646 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2079 on URI Attribute Type and Object Class
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Jan 97 10:08:53 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 2079
Title: Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers
(URIs)
Author: M. Smith
Date: January 1997
Mailbox: mcs at netscape.com
Pages: 5
Characters: 8757
Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2079.txt
A number of independent groups are already experimenting with the
inclusion of URLs in LDAP and X.500 directories. This document builds
on the experimentation to date and defines a new attribute type and an
auxiliary object class to allow URIs, including URLs, to be stored in
directory entries in a standard way.
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: <970110094833.RFC at ISI.EDU>
SEND /rfc/rfc2079.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2079.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970110094833.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa12747; 10 Jan 97 13:18 EST
Received: from zephyr.isi.edu by ietf.org id aa12370; 10 Jan 97 13:11 EST
Received: from nam.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA13815>; Fri, 10 Jan 1997 10:08:54 -0800
Message-Id: <199701101808.AA13815 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2081 on RIP-2 Applicability
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Jan 97 10:14:32 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 2081
Title: RIPng Protocol Applicability Statement
Author: G. Malkin
Date: January 1997
Mailbox: gmalkin at xylogics.com
Pages: 4
Characters: 6821
Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2081.txt
As required by Routing Protocol Criteria (RFC 1264), this report
defines the applicability of the RIPng protocol within the Internet.
This report is a prerequisite to advancing RIPng on the standards
track.
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: <970110101006.RFC at ISI.EDU>
SEND /rfc/rfc2081.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2081.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970110101006.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13051; 10 Jan 97 13:21 EST
Received: from zephyr.isi.edu by ietf.org id aa12785; 10 Jan 97 13:18 EST
Received: from nam.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA14156>; Fri, 10 Jan 1997 10:16:10 -0800
Message-Id: <199701101816.AA14156 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2077 on Model Primary MIME Types
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Jan 97 10:21:48 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 2077
Title: The Model Primary Content Type for
Multipurpose Internet Mail Extensions
Author: S. Nelson, C. Parks, Mitra
Date: January 1997
Mailbox: nelson18 at llnl.gov, parks at eeel.nist.gov,
mitra at earth.path.net
Pages: 13
Characters: 30158
Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2077.txt
The purpose of this memo is to propose an update to Internet RFC 2045
to include a new primary content-type to be known as "model". RFC
2045 [1] describes mechanisms for specifying and describing the format
of Internet Message Bodies via content-type/subtype pairs. We believe
that "model" defines a fundamental type of content with unique
presentational, hardware, and processing aspects. Various subtypes of
this primary type are immediately anticipated but will be covered
under separate documents.
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: <970110101605.RFC at ISI.EDU>
SEND /rfc/rfc2077.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2077.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970110101605.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa13811; 10 Jan 97 13:35 EST
Received: from zephyr.isi.edu by ietf.org id aa13367; 10 Jan 97 13:30 EST
Received: from nam.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA15238>; Fri, 10 Jan 1997 10:27:39 -0800
Message-Id: <199701101827.AA15238 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2080 on RIPng for IPv6
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Jan 97 10:33: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 2080
Title: RIPng for IPv6
Author: G. Malkin, R. Minnear
Date: January 1997
Mailbox: gmalkin at Xylogics.COM, minnear at ipsilon.com
Pages: 19
Characters: 47534
Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2080.txt
This document specifies a routing protocol for an IPv6 internet. It
is based on protocols and algorithms currently in wide use in the IPv4
Internet. This document is a product of the Routing Information
Protocol Working Group.
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: <970110102426.RFC at ISI.EDU>
SEND /rfc/rfc2080.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2080.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970110102426.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa14224; 10 Jan 97 13:42 EST
Received: from zephyr.isi.edu by ietf.org id aa14069; 10 Jan 97 13:41 EST
Received: from nam.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA15702>; Fri, 10 Jan 1997 10:37:43 -0800
Message-Id: <199701101837.AA15702 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2082 on RIP-2 MD5 Authentication
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Jan 97 10:43:20 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 2082
Title: RIP-2 MD5 Authentication
Author: F. Baker, R. Atkinson
Date: January 1997
Mailbox: fred at cisco.com, rja at cisco.com
Pages: 12
Characters: 25436
Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2082.txt
We propose that RIP-2 use an authentication algorithm, as was
originally proposed for SNMP Version 2, augmented by a sequence
number. This is a product of the RIP Working Group.
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: <970110103501.RFC at ISI.EDU>
SEND /rfc/rfc2082.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2082.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970110103501.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa15016; 10 Jan 97 13:58 EST
Received: from zephyr.isi.edu by ietf.org id aa14354; 10 Jan 97 13:49 EST
Received: from nam.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA16022>; Fri, 10 Jan 1997 10:45:01 -0800
Message-Id: <199701101845.AA16022 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2078 on GSS-API
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Jan 97 10:50:37 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 2078
Title: Generic Security Service Application Program
Interface, Version 2
Author: J. Linn
Date: January 1997
Mailbox: John.Linn at ov.com
Pages: 85
Characters: 185990
Obsoletes: 1508
URL: ftp://ds.internic.net/rfc/rfc2078.txt
This memo revises RFC-1508, making specific, incremental changes in
response to implementation experience and liaison requests. It is
intended, therefore, that this memo or a successor version thereto
will become the basis for subsequent progression of the GSS-API
specification on the standards track. This document is a product of
the Common Authentication Technology Working Group.
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: <970110104500.RFC at ISI.EDU>
SEND /rfc/rfc2078.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2078.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970110104500.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa19301; 10 Jan 97 14:58 EST
Received: from ietf.ietf.org by ietf.org id aa19177; 10 Jan 97 14:56 EST
To: ietf at ietf.org
Subject: Re: Just wondering about the silence
Sender:ietf-request at ietf.org
From: David Olson <dolson at more.net>
Date: Fri, 10 Jan 1997 14:56:25 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9701101456.aa19177 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
Probably don't know about it--the InterNIC seems to be pretty good at
trying to slide things by....
Received: from ietf.org by ietf.org id aa19302; 10 Jan 97 14:58 EST
Received: from cnri by ietf.org id aa18938; 10 Jan 97 14:53 EST
Received: from gatekeeper.chbs.ciba.com by CNRI.Reston.VA.US id aa20182;
10 Jan 97 14:53 EST
Received: from cgchm.is.chbs by gatekeeper.chbs.ciba.com; (5.65v3.2/1.1.8.2/12Mar96-0208PM)
id AA02991; Fri, 10 Jan 1997 20:58:17 +0100
Received: from mta1.is.chbs by Central.CHBS.CIBA.COM
id AA01437; Fri, 10 Jan 1997 13:49:53 +0100 (5.65c8/Ciba2.0-C1.1)
Received: by mta1.is.chbs (5.65v3.2/DEC-Ultrix/4.3)
id AA10177; Fri, 10 Jan 1997 13:49:44 +0100
X400-Received: by mta chbs-mta1 in /PRMD=ciba/ADMD=attmail/C=ch/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 10 Jan 1997 12:49:44 +0000
X400-Received: by /PRMD=CIBA/ADMD=ATTMAIL/C=CH/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 10 Jan 1997 07:47:01 +0500
Date: 10 Jan 1997 07:47:01 +0500
X400-Originator: raymond.obrien at usgr-msm3.ustc.mhs.ciba.com
X400-Mts-Identifier: [/PRMD=CIBA/ADMD=ATTMAIL/C=CH/;970110024701]
Sender:ietf-request at ietf.org
From: O'Brien Raymond MSM TCAD US <raymond.obrien at ustc.mhs.ciba.com>
To: Tim Weeks <ietf at CNRI.Reston.VA.US>
Subject: E-Mail
Importance: normal
Autoforwarded: FALSE
Message-Id: <"000BEFE0.MAI*/PN=raymond.obrien/OU=usgr-msm3/OU=ustc/O=ciba/PRMD=CIBA/ADMD=ATTMAIL/C=CH/"@MHS>
Original-Encoded-Information-Types: (2) (6) (3) (4) (11)
Content-Identifier: CSI NC V3.0
X400-Content-Type: P2-1988 (22)
Priority: normal
Source-Info: From (or Sender) name not authenticated.
Just want to see if this message system works.
Received: from ietf.org by ietf.org id aa19821; 10 Jan 97 15:03 EST
Received: from ietf.ietf.org by ietf.org id aa19670; 10 Jan 97 15:02 EST
To: ietf at ietf.org
Sender:ietf-request at ietf.org
From: Bob Packer <bob at packeteer.com>
Subject: Re: RSVP Can't Handle Spikes??
Date: Fri, 10 Jan 1997 15:02:09 -0500
X-Orig-Sender: scoya at ietf.org
Message-ID: <9701101502.aa19670 at ietf.org>
Source-Info: From (or Sender) name not authenticated.
karl -
i do apologize for the lack of good info on our web site. but don't
burn us quite yet. we are working hard to get better info out.
packeteer does not treat all http connections in the same fashion. it
is a web aware bandwidth management device. Packetshaper policies can
be set for URLs (with wild card matching), and may typically be
different for *.html and *.gif and *.jpg files.
a web manager can distinguish a pseudo-interactive activity, e.g. a
browser driven download of a .wav file,from an interactive pull of an
index file or an image file.
Packetshaper also senses path capacity in real time and allows for
explict policies for high and low speed populations.
Policies are set in terms of guaranteed rate (in bps, scaled to user
speed) and excess rate, in terms of a prioritized demand vector for
excess rate. Traffic which does not burst may be assigned a priority in
the unreserved portion of the bandwidth. Note that a typical policy
for *.html will assign unreserved high pri bandwidth.
Packeteer does not require that traffic classification be fully
enumerated - merely classify the traffic of concern and the rest will
be fit into the complementary space.
Packeteer allows for isolation of traffic classes as well - logical
channels.
So a single http tcp connection may hit a different policy for each
http get operation.
TCP traffic is controlled both inbound and outbound. TCP rate control
has lots of nice characteristics, like not requiring packet tossing,
shaping traffic to enhance mulitplexing gain, and effecting smooth
interactive delivery.
It also doesn't require buffering at the Packetshaper - buffering is
done at the leaves of the network.
UDP traffic may be controlled via leaky buckets, also with assignable
guaranteed rate and prioritized access to eir.
and how about bandwidth allocation by referrer ? how about serving
bifurcated content based on on the fly speed detection ?
We believe http is interactive. And we believe network resource owners
have the right to shape the traffic going into and out of their sites.
And we think we have provided the first in a series of tools to do
this.
Not, its not 3 bits of TOS.
To see fred say this is fud is a little troubling, as i don't believe
he is acquainted with all the details.
in short, rsvp solves some problems. this solves some other problems.
it is a totally TRANSPARENT solution as well.
so cry havoc, and let meet and write the dogs of war...
regards,
bp
Karl Auerbach wrote:
>
> > > Problem is, it can't keep up with HTTP (hypertext transfer
> > > protocol) traffic, which spikes and falls radically. "
> >
> > seems to me like sales FUD. I don't see any reason that congestion
> > management mechanisms underlying RSVP couldn't handle spikes of
congestion.
>
> I took at look at the data comm thing. They may be trying to say that
> http connections, because they are so short lived, are not amenable to
> RSVP because the connection is nearly over by the time the reservation is
> established.
>
> (And I doubt that that packeteer product can do much for short http
> connections because they are self throttling by slow start algorithms and
> there often won't even be any ACK bits for rackateer to finagle until the
> connection is getting ready to close.)
>
> I certainly think the article got off onto some wrong tangent about
> traffic "spikes".
>
> It would be worthwhile to write a note to the editors of datacom setting
> them straight.
>
> By-the-way, I do rememember that at the last IETF we decided to write an
> "applicability statement" about RSVP (and I also remember saying that I
> would help write it.)
>
> --karl--
Received: from ietf.org by ietf.org id aa26754; 10 Jan 97 16:56 EST
Received: from cnri by ietf.org id aa26621; 10 Jan 97 16:53 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa23785;
10 Jan 97 16:53 EST
Received: from brind.isi.edu (old-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA25671>; Fri, 10 Jan 1997 13:51:13 -0800
Sender:ietf-request at ietf.org
From: davidk at isi.edu
Posted-Date: Fri, 10 Jan 1997 13:51:12 -0800 (PST)
Message-Id: <9701102151.AA10498 at brind.isi.edu>
Received: by brind.isi.edu (4.1/4.0.3-6)
id <AA10498>; Fri, 10 Jan 97 13:51:12 PST
Subject: Re: Summary (and hopeful calming)
To: Vernon Schryver <vjs at mica.denver.sgi.com>
Date: Fri, 10 Jan 1997 13:51:12 -0800 (PST)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <199701092149.OAA17521 at mica.denver.sgi.com> from "Vernon Schryver" at Jan 9, 97 02:49:54 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 6148
Source-Info: From (or Sender) name not authenticated.
Vernon,
> Vernon Schryver writes :
>
> David kessens writes:
> >
> > IP registries and TLD registries are not quite the same. TLD space is
> > virtually unlimited (or can be made that way) while IPv4 address space is
> > certainly not.
>
> Really? I thought there were only about a gross of TLD's, even including
> the controversial efforts of John Palmer and his friends. Down a level,
> don't we still have fewer domains in .com than classical/classful IP
> network numbers?
Domain name space has room for growth. IPv4 space certainly has not.
In fact TLD name space is being extended (we can discuss by who exactly ;-)).
Furthermore, talking as if domain names and IP numbers have comparable
meaning for the Internet is not appropriate since the nature and purpose
of the two resources is quite different.
> > While there might be ways to use some of the ideas as developed for the
> > TLD issues it is rather early to apply them for IP registries. There is
> > no operational experience with these shared registries at all. I don't
> > think it is a good idea to start experimenting with the two most
> > important resources on the Internet at the same time.
>
> You don't figure that imposing fees for IP addresses is as much or as
> big an experiment as having more than one domain registry?
This has nothing to do with an experiment. Charging for IP registration
services is done in the rest of the world for over two years.
> Mere organizational changes do not imply imposing new fee structures.
> Or do you figure the switch from SRI to NIS has been only an
> organizational change?
Fine with me, let's say, there are organizational changes and fees will
be introduced at the same time since funding for IPv4 address
registration services by NSF has stopped. However, there is nothing that
you can do about the fact that there will be fees since NSF will not fund
that activity anymore. Of course there can be discussion on how much the
fees need to be and what kind of fee structure will be used.
Whether you like or dislike NSI, why should a commercial company (NSI) be
paying for your IP registration? NSF doesn't fund these activities
anymore.
> > Bringing competition in the whole scheme might be considered desirable
> > but that is a global issue and has little to do with an organizational
> > change happening at the IP registry for the Americas. Please keep these
> > issues seperate since they are both already complicated enough and
>
> Please consider why the competition thing was brought into the TLD
> business. It was not because 5 or 10 years ago anyone imagined
> competition in name registration was other than silly nonsense. The
> competition thing is purely a reaction to recent history, to the
> actions and inactions of what appears to be the main proponent of the
> idea of charging holders of IP addresses. We all remember that the
> $50/domain fee was advertised to generate only a pittance, and that the
> claims to the contrary were ridiculed. We also remember that trademark
> laws were to be applied rationally.
>
> Given history, one should exect plenty of skepticism about the purpose,
> advocates, and actual operation of this proposal.
If you are talking about the fees:
You can be skeptical but that will still not change anything to the fact
that fees are necessary to cope with the costs of IPv4 registration
services in the Americas. NSF will simply not pay for this anymore.
You might want to provide contructive input (on the naipr maillist) to
avoid errors that you claim that you have seen happening in the past.
Being skeptical is always the easy way out. I can as well tell you 10
years from now that you said that there were problems with the proposal
but *refused* to tell what the problems were and didn't propose
alternatives.
> That skepticism is
> not reduced by statements that are obviously false, whether about the
> words in the proposal, the number of TLDs, or the shortage of IP
> networks. (I trust the false statements were unintentional.)
I am sorry but I don't accept this accusation.
Nothing has been said by me about the amount of TLDs or a shortage of
IPv4 network numbers. How could I have made false statements then ?
I talked about a *property* of the two different spaces. IPv4 space is
limited (to 32-bit numbers) while the TLD name space can and will be
extended and is thus not a fixed number.
> > discuss matters related to the ARIN proposal on
> > <naipr at lists.internic.net> maillist.
>
> The repeated demands that this stuff be discussed only on a special
> mailing list that reportedly does not accept subscribers is not a
> confidence builder. I believe that is evidence of other than malice,
> but that belief requires a conscious effort.
While 'listserv' mail servers are not the easiest to use, I didn't have
such problems.
> In principle, charging for services rendered is obviously a good idea.
> I've been told privately that people I trust like the basic idea but
> that a flawed draft was released prematurely.
It was the intention that everybody had the chance to provide comments in
an early stage of the draft. There are of course flaws in the draft and
they are being discussed on the 'naipr' maillist. Everybody can
participate in that discussions and it is good to see that many people
indeed took the effort to subscribe and participate in the discussions.
Kim Hubbard announced that she would publish a revised draft soon that
will clarify part of the questions and might satisfy a lot of the
concerns that many people have.
> Based on that, I'll be quiet.
> I'll also control my cynical speculations that the next step
> will be for someone to implement the premature draft including its fee
> structures and send current owners of IP networks bills amounting to
> a few $100M, and saying "these are the IETF approved rules; if you
> don't like them, complain to the IETF. When the final rules are
> approved, we'll of course change, but until then, we must use the
> initial rules.
Of course this can happen. Of course this might not happen.
Of course you could refuse to pay such a bill.
David K.
---
Received: from ietf.org by ietf.org id aa28290; 10 Jan 97 17:17 EST
Received: from cnri by ietf.org id aa28072; 10 Jan 97 17:15 EST
Received: from cu.nih.gov by CNRI.Reston.VA.US id aa24464; 10 Jan 97 17:15 EST
To: wsimpson at greendragon.com
cc: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Roger Fajman <RAF at cu.nih.gov>
Date: Fri, 10 Jan 1997 17:12:45 EST
Subject: Re: Summary (and hopeful calming)
Message-ID: <9701101715.aa24464 at CNRI.Reston.VA.US>
Source-Info: From (or Sender) name not authenticated.
> And I needed the "ok ####" confirmation technique, whereas you seem to
> have gotten in with just "ok".
If the reply function of your email client preserves the confirmation
code in the subject, you don't need to put the code in the OK command.
LISTSERV will pick up the code if it's in the subject, otherwise you
have to explicity enter it.
Received: from ietf.org by ietf.org id aa00410; 10 Jan 97 17:55 EST
Received: from cnri by ietf.org id aa00127; 10 Jan 97 17:52 EST
Received: from SGI.COM by CNRI.Reston.VA.US id aa25389; 10 Jan 97 17:52 EST
Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA03423 for <@sgi.engr.sgi.com:ietf at cnri.reston.va.us>; Fri, 10 Jan 1997 14:41:15 -0800
Received: from mica.denver.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI)
for <@sgi.engr.sgi.com:ietf at cnri.reston.va.us> id OAA07659; Fri, 10 Jan 1997 14:41:12 -0800
Received: (from vjs at localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id PAA21594 for ietf at cnri.reston.va.us; Fri, 10 Jan 1997 15:34:15 -0700
Date: Fri, 10 Jan 1997 15:34:15 -0700
Sender:ietf-request at ietf.org
From: Vernon Schryver <vjs at mica.denver.sgi.com>
Message-Id: <199701102234.PAA21594 at mica.denver.sgi.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Summary (and hopeful calming)
Source-Info: From (or Sender) name not authenticated.
> From: davidk at ISI.EDU
> ...
> David kessens writes:
[more things that would raise my suspicions if I were not working so
hard on keeping them under control. oh, well.]
> ...
> Kim Hubbard announced that she would publish a revised draft soon that
> will clarify part of the questions and might satisfy a lot of the
> concerns that many people have.
I hope so. But what is this about announcing the membership of the
board next week, before the first tolerable draft?
>. ...
> > I'll also control my cynical speculations that the next step
> > will be for someone to implement the premature draft including its fee
> > structures and send current owners of IP networks bills amounting to
> > a few $100M, and saying "these are the IETF approved rules; if you
> > don't like them, complain to the IETF. When the final rules are
> > approved, we'll of course change, but until then, we must use the
> > initial rules.
>
> Of course this can happen. Of course this might not happen.
How can you be so cavalier about the possiblity? If it really could
happen, we have a crisis. Have you not been watching the TLD saga?
Do you really not realize the damage that saga has done? The vast
quatities of time, money, confidence, and trust that soap opera has
utterly trashed? I'm not talking about the $50 .com fees themselves,
but the lawyer and technical time, media ink, etc.
> Of course you could refuse to pay such a bill.
And have my reverse maps and primary .com DNS entries removed for
non-payment? sheesh.
The claims that IP address allocations and DNS naming, including TLDs,
are independent, uncoupled, and not vulnerable to very similar
mistakes, mistaken policies, or abuses are at best mistaken.
Do you really not remember how the other saga began? Do you not see
the parallels?--a small group announces a fait accompli of a fee
structure, and then offers exactly the same reasons for the process
creating the structure the fees and of the fees? Do you not know that
some of the same players are involved? double sheesh.
Modest proposal: tell this new fee collecting board to go get real
jobs, disband its support group by ignoring it, and require the new TLD
registries to fund the allocation and registration of IP addresses.
The talk about educating new ISP is nonsense. None of the IETF, ISOC,
TLD registries or people doling out class-C's have any business
educating anyone on the meanings of netmaskes, CIDR, or BGR4. If ISPs
want to have a trade group that provides education, let them. Don't
give them the registery that predated domain names to fund their
education--no doubt in the form of educational seminars in Hawaii and
on cruise ships.
Vernon Schryver, vjs at sgi.com
Received: from ietf.org by ietf.org id aa03623; 10 Jan 97 19:18 EST
Received: from cnri by ietf.org id aa03268; 10 Jan 97 19:07 EST
Received: from relay.hq.tis.com by CNRI.Reston.VA.US id aa27179;
10 Jan 97 19:07 EST
Received: by relay.hq.tis.com; id TAA08836; Fri, 10 Jan 1997 19:08:23 -0500 (EST)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2)
id xma008804; Fri, 10 Jan 97 19:08:02 -0500
Received: from sol.hq.tis.com (sol [10.33.1.100]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id TAA17775; Fri, 10 Jan 1997 19:01:41 -0500 (EST)
Received: from sol.hq.tis.com by sol.hq.tis.com (4.1/SMI-4.1)
id AA23417; Fri, 10 Jan 97 19:01:40 EST
Message-Id: <9701110001.AA23417 at sol.hq.tis.com>
To: cat-ietf at mit.edu, e-payment at bellcore.com, firewalls at greatcircle.com,
ids at uow.edu.au, ietf-otp at bellcore.com, ietf-pkix at tandem.com,
ietf-tls at w3.org, ietf at CNRI.Reston.VA.US, ipsec at ans.net, pem-dev at tis.com,
psrg at isi.edu, sndss-authors at isi.edu, sndss-chairs at tis.com, spki at c2.net,
virus-l at lehigh.edu, www-buyinfo at allegra.att.com,
www-security at ns2.rutgers.edu
Subject: 2ND ANNOUNCEMENT: ISOC 97 SYMP NETWORK & DISTRIBUTED SYSTEM SECURITY
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <23400.852940884.1 at tis.com>
Date: Fri, 10 Jan 1997 19:01:26 -0500
Sender:ietf-request at ietf.org
From: "David M. Balenson" <balenson at tis.com>
Source-Info: From (or Sender) name not authenticated.
PLEASE NOTE THE EARLY REGISTRATION AND HOTEL ROOM AVAILABILITY AND SPECIAL
RATES DEADLINES ARE APPROACHING!! RESERVATIONS AT THE PRINCESS RESORT
MUST BE MADE NO LATER THAN JAN 13TH FOR THE GOVERNMENT RATE, AND NO LATER
THAN JAN 20TH FOR THE REDUCED GROUP RATE. EARLY REGISTRATION FOR THE
SYMPOSIUM MUST BE POSTMARKED NO LATER THAN JAN 22ND.
---------------------------------------------------------------------------
THE INTERNET SOCIETY 1997 SYMPOSIUM ON
NETWORK AND DISTRIBUTED SYSTEM SECURITY
(NDSS '97)
10-11 FEBRUARY 1997
SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA
This fourth annual symposium will bring together researchers,
implementors, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges. It will provide a mix of technical papers and panel
presentations that describe promising new approaches to security
problems that are practical, and to the extent possible, have
been implemented. We hope to foster the exchange of technical
information and encourage the Internet community to deploy
available security technologies and develop new solutions to
unsolved problems.
WHY YOU SHOULD ATTEND
The use of the Internet is rapidly growing and expanding into
all aspects of our society. Commercial organizations are coming
under increasing pressure to make their services available on-line.
This in turn is increasing the need for rapid and widespread
deployment of usable and effective network and distributed system
security technologies. High visibility attacks on the Internet
underscore the vulnerabilities of the Internet and the need to
solve its security problems. There is growing concern for securing
the network infrastructure itself. Recent trends in software
distribution (such as Java and ActiveX technologies) have made
certain attacks easier to carry out. Privacy has become an
important issue for the Internet.
NDSS '97 will bring together researchers, implementors, and users
of network and distributed system technologies to discuss today's
important security issues and challenges. We have selected the
technical papers and panel presentations that describe promising
new approaches to security problems that are practical, and to
the extent possible, have been implemented. Topics to be addressed
include Internet infrastructure and routing security, security
for the World Wide Web, Java and ActiveX security, cryptographic
protocols, public key management, and protection of privacy.
The symposium will have a positive impact on the state of Internet
security. You will have the opportunity to actively participate
in the dialog. Ask questions of the speakers, raise your important
issues during the panel sessions, and let other participants know
of your requirements, observations, and experience in this
important area. We hope to encourage the wide-scale deployment
of security technologies and to promote new research that can
address the currently unmet security needs of the Internet
community.
CONTENTS
Preliminary Program
Organizing Committee
San Diego Princess Resort
Registration Information
Registration Form
---------------------------------------------------------------------------
P R E L I M I N A R Y P R O G R A M
SUNDAY, FEBRUARY 9
6:00 P.M. - 8:00 P.M.
RECEPTION
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MONDAY, FEBRUARY 10
7:30 A.M.
CONTINENTAL BREAKFAST
8:30 A.M.
OPENING REMARKS
9:00 A.M.
SESSION 1: THINGS THAT GO BUMP IN THE NET
Chair: Stephen T. Kent (BBN Corporation, USA)
Experimental Results of Covert Channel Elimination in One-Way
Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard
Schroeppel, Sean O'Malley, and Oliver Spatscheck (University
of Arizona, USA)
Blocking Java Applets at the Firewall, David M. Martin Jr.,
Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA)
Continuous Assessment of a Unix Configuration: Integrating
Intrusion Detection & Configuration Analysis, Abdelaziz Mounji
and Baudouin Le Charlier (Institut D'Informatique, Namur,
BELGIUM)
10:30 A.M.
BREAK
11:00 A.M.
SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT
Chair: Aviel Rubin (AT&T Research Labs, USA)
Panelists: Li Gong (JavaSoft, USA), Jim Roskind (Netscape, USA),
Edward W. Felten (Princeton University, USA) and Peter G. Neumann
(SRI International, USA)
12:30 NOON
LUNCH
2:00 P.M.
SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS
Chair: Christoph Schuba (Purdue University, USA)
An Interface Specification Language for Automatically Analyzing
Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA)
Probable Plaintext Cryptanalysis of the IP Security Protocols,
Steven M. Bellovin (AT&T Research, USA)
Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun
Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford
(Purdue University, USA)
3:30 P.M.
BREAK
4:00 P.M.
SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE
Chair: Russ Mundy (Trusted Information Systems, USA)
Panelists: Paul Lambert (Oracle, USA), Jeff Schiller (MIT, USA),
Olafur Gudmundsson (Trusted Information Systems, USA)
7:00 P.M.
DINNER BANQUET
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TUESDAY, FEBRUARY 11
7:30 A.M.
CONTINENTAL BREAKFAST
8:30 A.M.
SESSION 5: ROUTING SECURITY
Chair: Hilarie Orman (DARPA, USA)
Securing the Nimrod Routing Architecture, Karen E. Sirois and
Stephen T. Kent (BBN Corporation, USA)
Securing Distance-Vector Routing Protocols, Bradley R. Smith,
Shree Murthy and J.J. Garcia-Luna-Aceves (University of California
Santa Cruz, USA)
Reducing the Cost of Security in Link-State Routing, R. Hauser,
A. Przygienda and G. Tsudik (IBM and USC/ISI, USA)
10:00 A.M.
BREAK
10:30 A.M.
SESSION 6: SECURITY FOR THE WORLD WIDE WEB
Chair: Win Treese (OpenMarket, USA)
Securing Web Access with DCE, Brian C. Schimpf (Gradient
Technologies, USA)
PANEL: SECURITY FOR THE WORLD WIDE WEB
Chair: Win Treese (OpenMarket, USA)
12:00 A.M.
LUNCH
1:30 P.M.
SESSION 7: PUBLIC KEY MANAGEMENT
Chair: Jonathan Trostle (CyberSafe, USA)
Hierarchical Organization of Certification Authorities for
Secure Environments, Lourdes Lopez and Justo Carracedo
(Universidad Politecnica de Madrid, SPAIN)
Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic
(Univeristy of Salford, UNITED KINGDOM)
Distributed Authentication in Kerberos Using Public Key
Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie
Mellon University, USA)
3:00 P.M.
BREAK
3:30 P.M.
SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY
Chair: Clifford Neuman (USC Information Sciences Institute, USA)
---------------------------------------------------------------------------
O R G A N I Z I N G C O M M I T T E E
GENERAL CHAIR
David Balenson, Trusted Information Systems
PROGRAM CHAIRS
Clifford Neuman, USC Information Sciences Institute
Matt Bishop, University of California at Davis
PROGRAM COMMITTEE
Steve Bellovin, AT&T Research
Tom Berson, Anagram Laboratories
Doug Engert, Argonne National Laboratory
Warwick Ford, Verisign
Richard Graveman, Bellcore
Li Gong, JavaSoft
Burt Kaliski, RSA Laboratories
Steve Kent, BBN Corporation
Tom Longstaff, CERT
Doug Maughan, National Security Agency
Dan Nessett, 3Com Corporation
Hilarie Orman, DARPA/ITO
Michael Roe, University of Cambridge
Christoph Schuba, Purdue University
Jonathan Trostle, CyberSafe
Theodore Ts'o, Massachusetts Institute of Technology
Doug Tygar, Carnegie Mellon University
Vijay Varadharajan, University of W. Sydney
Roberto Zamparo, Telia Research
PUBLICATIONS CHAIR
Steve Welke, Institute for Defense Analyses
LOCAL ARRANGEMENTS CHAIR
Thomas Hutton, San Diego Supercomputer Center
REGISTRATIONS CHAIR
Torryn Brazell, Internet Society
STEERING GROUP
Internet Research Task Force, Privacy and Security Research Group
SPONSORED BY THE INTERNET SOCIETY
Donald M. Heath, President & CEO
Martin Burack, Executive Director
---------------------------------------------------------------------------
S A N D I E G O P R I N C E S S R E S O R T
LOCATION
The Symposium venue is the San Diego Princess Resort, a tropical
paradise on a forty-four acre island in Mission Bay, ten minutes
from the international airport. Lush gardens landscaped with
hundreds of species of tropical and subtropical plants are
always ablaze with color and perfect for themed group events.
Charming pathways wander among sparkling waterfalls, across
quaint footbridges and sleepy lagoons filled with water lilies
and waterfowl. A white sand beach curves around the island
for over a mile, and the award-winning grounds encompass five
swimming pools and six lighted tennis courts.
Spouses and family members can catch a convenient Harbor Hopper
for a quick trip to Sea World. Plan to visit La Jolla, the world
famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley.
HOUSING INFORMATION
We have reserved a special block of sleeping rooms at the San Diego
Princess Resort at the following rates:
Lanai Patio Rooms $ 81*
Lanai Garden Rooms $114
* This represents the Government Rate for San Diego. A limited
number of rooms are available at this rate. Reservations must
be made no later than January 13, 1997. You must present a
valid government id upon check-in.
Based on room type and space availability, the special group
rates are applicable two days prior to and two days after the
symposium. Current Room Tax is 10.5%.
Check-in availability cannot be committed prior to 4:00 p.m.
Check-out time is 12:00 noon. The San Diego Princess Resort
will make every effort to accommodate any early arrivals, so
make sure you give them your arrival time when you make your
reservation.
TO MAKE A RESERVATION
Contact the San Diego Princess Resort at +1-800-344-2626
(+1-619-274-4630 if outside the United States). To receive
the special group rates, reservations must be made no later
than January 20, 1997. To receive the special goverment
rate, you must make your reservation by January 13, 1997.
CLIMATE
February weather in San Diego is normally very pleasant. Early
morning temperatures average 55 degrees while afternoon
temperatures average 67 degrees. Generally, a light jacket or
sweater is adequate, although, occasionally it rains.
---------------------------------------------------------------------------
R E G I S T R A T I O N I N F O R M A T I O N
FEES ISOC Non-
Members Member*
Early registration
(postmarked on/before Jan. 22) $305 $345
Late registration $375 $415
REGISTRATION INCLUDES
- Attendance - Symposium Proceedings - Two luncheons
- Reception - Banquet - Coffee Breaks
* Non-Member fee includes one year Internet Society membership.
FOR MORE INFORMATION
Contact Carol Gray at the Internet Society at +1-703-648-9888
or send E-mail to Ndss97reg at isoc.org.
WEB PAGE
Additional information about the symposium and San Diego, plus
on-line registration, are available via the Web at:
http://www.isoc.org/conferences/ndss97
SPONSORSHIP OPPORTUNITIES AVAILABLE!
Contact Torryn Brazell at the Internet Society at +1-703-648-9888
or send E-mail to Ndss97reg at isoc.org.
---------------------------------------------------------------------------
R E G I S T R A T I O N F O R M
INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY
10-11 FEBRUARY, 1997 SAN DIEGO, CALIFORNIA, USA
Fill out this form and FAX it to NDSS'97 Registration at +1-703-648-9887,
send it via E-mail to Ndss97reg at isoc.org, or mail it to NDSS97,
12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA
PERSONAL INFORMATION
__Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle
First Name: ________________________________ MI: ____________________
Family Name: ___________________________________ __Sr __Jr __II __III
Badge Name: __________________________________________________________
Please enter your name as you would like it to appear on your name tag.
CONTACT INFORMATION
Title: _______________________________________________________________
Organization: ________________________________________________________
Street address: ______________________________________________________
______________________________________________________________________
City: ________________________________________________________________
State/Province: ___________________________ Postal Code: ____________
Country: _____________________________________________________________
Telephone Number (work): _____________________________________________
Telephone Number (home): _____________________________________________
Fax Number: __________________________________________________________
E-mail address: ______________________________________________________
SPECIAL NEEDS? (Vegetarian meals, wheelchair access, etc?)
______________________________________________________________________
______________________________________________________________________
APPEAR ON REGISTRANTS LIST?
___ Please check here if you would NOT like your name included
in the list of registrants.
PAYMENT INFORMATION
All Payments must be in United States Dollars.
Conference Fee
--------------
If you are an Internet Society member, you are eligible for a
reduced conference registration fee. Non-member symposium
attendees will receive a one year Internet Society membership
as part of the non-member registration fees.
Check one: On/Before After
January 22 January 22
---------- ----------
___ Internet Society Member Fee US$ 305.00 US$ 375.00
___ Non-Member Fee US$ 345.00 US$ 415.00
Method of Payment
-----------------
Payment must be received on/before February 7, 1997 or we will
be unable to pre-register you.
1. ___ Check. Make payable to the Internet Society.
2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard
Name on Credit Card: ____________________________________
Credit Card Number: _____________________________________
Expiration Date: ________________________________________
3. ___ CyberCash. Account Number: _____________________________
4. ___ First Virtual. Account Number: _________________________
5. ___ Wire Transfer*
Bank ABA Number: 054000030
Account Number: Internet Society 148 387 10
Riggs National Bank of Virginia
950 Herndon Parkway
Herndon, VA 20171 USA
Wire Transfer Confirmation Number: ______________________
* Please process wire transfer before sending registration
form.
6. ___ U.S. Government Purchase Order*
P.O. Number: ____________________________________________
* Please fax or mail a copy of your purchase order along
with your registration form.
Cancellation Policy
-------------------
Refunds (less a $25 processing fee) will be issued for cancellations
received on/before February 7, 1997. No refunds will be issued
after February 7, 1997.
------------------------------------------------------------------------
Received: from ietf.org by ietf.org id aa05479; 10 Jan 97 20:18 EST
Received: from cnri by ietf.org id aa05364; 10 Jan 97 20:12 EST
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa28359;
10 Jan 97 20:11 EST
Received: from brind.isi.edu (old-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA08060>; Fri, 10 Jan 1997 17:10:02 -0800
Sender:ietf-request at ietf.org
From: davidk at isi.edu
Posted-Date: Fri, 10 Jan 1997 17:10:01 -0800 (PST)
Message-Id: <9701110110.AA10962 at brind.isi.edu>
Received: by brind.isi.edu (4.1/4.0.3-6)
id <AA10962>; Fri, 10 Jan 97 17:10:01 PST
Subject: Re: Summary (and hopeful calming)
To: Vernon Schryver <vjs at mica.denver.sgi.com>
Date: Fri, 10 Jan 1997 17:10:01 -0800 (PST)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <199701102234.PAA21594 at mica.denver.sgi.com> from "Vernon Schryver" at Jan 10, 97 03:34:15 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 3880
Source-Info: From (or Sender) name not authenticated.
Vernon,
> Vernon Schryver writes :
>
> [more things that would raise my suspicions if I were not working so
> hard on keeping them under control. oh, well.]
That saves me some work in replying and the others on this list some
reading. I am happy that you try to keep your paranoia under control.
> > Kim Hubbard announced that she would publish a revised draft soon that
> > will clarify part of the questions and might satisfy a lot of the
> > concerns that many people have.
>
> I hope so. But what is this about announcing the membership of the
> board next week, before the first tolerable draft?
Do you want to do a ballot ?!? Among who ? I am afraid that the first
board will need to be elected in a non-democratic way since there is no
electorate yet. Of course this is *not* satisfactory but where are your
proposals to do this in a better way ?
> > Of course you could refuse to pay such a bill.
>
> And have my reverse maps and primary .com DNS entries removed for
> non-payment? sheesh.
Forward domains are handled by the DNS registries (which charge much
lower fees for initial registration then the IP registries) while reverse
mapping is done by an IP registry. They are different registries.
People that don't have the courage to act will never win. We are talking
about a possibility that could happen. If it happens; organize yourself
and act. I am sure that the law (in the US) would be at your side if
(non-profit) IP registries would make big profits in a monopoly
situation.
Please contribute at the 'naipr' forum with ideas to make sure that the
membership of the IP registry has enough power to avoid any like this.
> The claims that IP address allocations and DNS naming, including TLDs,
> are independent, uncoupled, and not vulnerable to very similar
> mistakes, mistaken policies, or abuses are at best mistaken.
Of course the same mistakes can be made. Please contribute to the 'naipr'
forum to help avoiding this.
> Do you really not remember how the other saga began? Do you not see
> the parallels?--a small group announces a fait accompli of a fee
> structure, and then offers exactly the same reasons for the process
> creating the structure the fees and of the fees?
The fee structure is not fixed yet. The fees are different. The fee
structure is different. There is no 30% tax for a special fund. There is
no tax for domain name owners to subsidize IP registrations. There will
be a published budget instead of the secrecy of a private corporation.
Please contribute to the 'naipr' forum to help make decisions on the fee
structures.
> Do you not know that
> some of the same players are involved? double sheesh.
What a surprise: The IP registrations and DNS registrations for the
Americas are still done by the same organization ...
> Don't give them the registery that predated domain names to fund their
> education--no doubt in the form of educational seminars in Hawaii and
> on cruise ships.
There will be a published budget this time. You can raise your voice at
the 'naipr' forum to make sure that the membership will have a say and
that the membership will be open. Please shout at them only *after*
decisions are made that are wrong (in your opinion) and try to influence
the decisions making process with useful comments instead of shouting on
the wrong mailing list since you might not be heard by the people who are
writing the next draft,
David K.
PS1 I am not saying that I do agree with the complete draft and that I
don't have suspicions but suspicions alone don't change the draft ...
comments on the 'naipr' mailing list have a better chance.
many suspicious people already subscribed to the mailing list and
shared their comments and are waiting if the next draft will address
some of their suspicions ;-).
PS2 This is probably my last mail in this series ...
---
Received: from ietf.org by ietf.org id aa17442; 11 Jan 97 1:36 EST
Received: from cnri by ietf.org id aa17326; 11 Jan 97 1:31 EST
Received: from teckla.apnic.net by CNRI.Reston.VA.US id aa02597;
11 Jan 97 1:31 EST
Received: from nostromo.jp.apnic.net (root at dial021.hkt.net [206.161.63.30]) by teckla.apnic.net (8.8.2/8.7.1) with ESMTP id PAA03996; Sat, 11 Jan 1997 15:27:02 +0900 (JST)
Received: from ronin.apnic.net (davidc at localhost [127.0.0.1]) by nostromo.jp.apnic.net (8.7.3/8.7.3) with ESMTP id TAA01629; Thu, 9 Jan 1997 19:55:03 GMT
Message-Id: <199701091955.TAA01629 at nostromo.jp.apnic.net>
To: Valdis.Kletnieks at vt.edu
cc: naipr at internic.net, Keith Moore <moore at cs.utk.edu>, karl at cavebear.com,
IETF <ietf at CNRI.Reston.VA.US>
Subject: Re: Just wondering about the silence
In-reply-to: Your message of "Thu, 09 Jan 1997 13:07:30 EST."
<199701091807.NAA31160 at black-ice.cc.vt.edu>
Date: Thu, 09 Jan 1997 19:55:03 +0000
Sender:ietf-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Source-Info: From (or Sender) name not authenticated.
Valdis,
>Please decouple your *REGISTRY* fees for acutally registering it
>from your consulting fees.
This has been discussed in the past within the APNIC community and the
consensus of that community is that this would not be in the best interests
of promoting the Internet in the region. The problem is that the people who
most need the "consulting" are the new ISPs and if the "consulting fees" were
assessed, the costs for new ISPs would be significantly higher than those
for existing ISPs. At least within the AP region, it was felt that the
simplicity of a flat fee, plus the fact that the new ISPs generally connect
to existing members and those existing members actually appreciated APNIC
providing help in this area, resulted in support for the existing funding
plan, even though it meant the well established ISPs were subsidizing the
less established ISPs.
However, this decision is clearly likely to vary across regions and even in
the AP region is not set in concrete. I imagine it would be up to the ARIN
membership to modify the way ARIN supports itself appropriately as the APNIC
community can do.
>(As an aside, are you saying "yes they can", or "no they cant"?
They can't and expect to have additional space allocated without an
explanation for the rather dramatic waste.
>Who ever had a problem with 255.255.255.0 as a subnet mask for 2 hosts?
The registries.
>Now, let's say that of the $2,500 *minimum* you wish to charge, $50 goes
>to actually doing the registration. This means that you are charging
>$2,450 dollars to explain CIDR. Are you saing that CIDR is on the order
>of 100 times more complicated to explain than secondary nameservers?
Please re-read my previous note and focus on the various things the
registries are required to discuss with appliacants. CIDR is a large part,
but there are many other topics we are required to "consult" on.
>I won't comment on the wisdom of charging MIT $2,559,950 to explain
>CIDR to them. I strongly suspect that they already understand.
See Kim's note.
Regards,
-drc
Received: from ietf.org by ietf.org id aa21418; 11 Jan 97 5:06 EST
Received: from cnri by ietf.org id aa21279; 11 Jan 97 5:01 EST
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa05558;
11 Jan 97 5:01 EST
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(8.7.5/UW-NDC Revision: 2.28 ) id BAA02071; Sat, 11 Jan 1997 01:58:58 -0800 (PST)
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA25069; Sat, 11 Jan 97 01:58:53 -0800
Date: Sat, 11 Jan 1997 01:28:43 -0800 (PST)
Sender:ietf-request at ietf.org
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: Just wondering about the silence
To: Internet Engineering Task Force <ietf at CNRI.Reston.VA.US>
In-Reply-To: <199701091955.TAA01629 at nostromo.jp.apnic.net>
Message-Id: <MailManager.852974923.24955.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Thu, 09 Jan 1997 19:55:03 +0000, David R. Conrad wrote:
> >Please decouple your *REGISTRY* fees for actually registering it
> >from your consulting fees.
>
> This has been discussed in the past within the APNIC community and the
> consensus of that community is that this would not be in the best interests
> of promoting the Internet in the region.
I respectfully point out that the telecommunications culture and history in
North America is very different from that in Asia/Pacific (or Europe); and
suggest that it is unwise to assume that lessons from the Asian or European
experience are necessarily applicable to North America.
It is difficult to imagine a more effective way of stifling Internet in North
America than by slavishly copying the Asian (or European) model.
Received: from ietf.org by ietf.org id aa22458; 11 Jan 97 5:33 EST
Received: from cnri by ietf.org id aa22378; 11 Jan 97 5:32 EST
Received: from [207.32.130.1] by CNRI.Reston.VA.US id aa05960;
11 Jan 97 5: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 EAA26725; Sat, 11 Jan 1997 04:22:01 -0600
Received: by webster.unety.net with Microsoft Mail
id <01BBFF77.A8774340 at webster.unety.net>; Sat, 11 Jan 1997 04:26:47 -0600
Message-ID: <01BBFF77.A8774340 at webster.unety.net>
Sender:ietf-request at ietf.org
From: Jim Fleming <JimFleming at unety.net>
To: Internet Engineering Task Force <ietf at CNRI.Reston.VA.US>,
'Mark Crispin' <MRC at panda.com>
Cc: 'Multiple recipients of list NAIPR' <NAIPR at lists.internic.net>
Subject: RE: Just wondering about the silence
Date: Sat, 11 Jan 1997 04:26:46 -0600
Encoding: 58 TEXT
Source-Info: From (or Sender) name not authenticated.
On Friday, January 10, 1997 7:28 PM, Mark Crispin[SMTP:MRC at panda.com] wrote:
@ On Thu, 09 Jan 1997 19:55:03 +0000, David R. Conrad wrote:
@ > >Please decouple your *REGISTRY* fees for actually registering it
@ > >from your consulting fees.
@ >
@ > This has been discussed in the past within the APNIC community and the
@ > consensus of that community is that this would not be in the best interests
@ > of promoting the Internet in the region.
@
@ I respectfully point out that the telecommunications culture and history in
@ North America is very different from that in Asia/Pacific (or Europe); and
@ suggest that it is unwise to assume that lessons from the Asian or European
@ experience are necessarily applicable to North America.
@
@ It is difficult to imagine a more effective way of stifling Internet in North
@ America than by slavishly copying the Asian (or European) model.
@
@
@
I agree 100%...although I am not sure North America is all the same...
This reminds me of some meetings I had the pleasure of attending
back in the late 70's in Canada as a representative of AT&T (before
it was broken up twice)...
We were visiting with the Minister of Communication and he was
explaining that in Canada, the government must play a very active
role in holding the hands of their key technical "gladiators" (as he
called them). He pointed out that the U.S. has the luxury of having
many gladiators in the arena and everyone battles to the death and
the best companies win.
He claimed that in Canada, because they have less people, they
can not risk having ANY of their gladiators destroyed because each
one is a precious national resource. Instead, he claimed that the
Canadian government spends a fortune protecting its technologists
from failing, in Canada, as well as the rest of the world.
I have no idea if this is still the case, but I would caution that
the U.S., Canada and Mexico are all very different places with
very different cultures and history. To apply broad brush "Internet
ideals" across the board would be a mistake, even in North America...
P.S. In the registry arena, it is interesting to note that Canada used
to handle some of its own "InterNIC-like" functions. Because of what
some informed Canadians claim was incompetence, those functions
were transferred BACK to the U.S. not long ago. This is one small
piece of evidence that Canada and the U.S. are not the same.
--
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 aa29070; 11 Jan 97 10:04 EST
Received: from cnri by ietf.org id aa28845; 11 Jan 97 9:53 EST
Received: from relay.hq.tis.com by CNRI.Reston.VA.US id aa09567;
11 Jan 97 9:53 EST
Received: by relay.hq.tis.com; id JAA14836; Sat, 11 Jan 1997 09:54:26 -0500 (EST)
Received: from dhcp0.hq.tis.com(192.94.214.120) by relay.hq.tis.com via smap (3.2)
id xma014834; Sat, 11 Jan 97 09:53:58 -0500
Message-Id: <2.2.32.19970111145134.006dc5d4 at popsrvr.hq.tis.com>
X-Sender: ogud at popsrvr.hq.tis.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 11 Jan 1997 09:51:34 -0500
To: ietf at CNRI.Reston.VA.US
Sender:ietf-request at ietf.org
From: Olafur Gudmundsson <ogud at tis.com>
Subject: Washington Post article on Network Solutions track record
Cc: ogud at tis.com
Source-Info: From (or Sender) name not authenticated.
This mornings biz section of the Washington Post carried an article about the
track record of Network Solutions.
You can read the full story at:
http://www.washingtonpost.com/wp-srv/WPlate/1997-01/11/142L-011197-idx.html
My Summary: Network Solution has problem collecting fees, and has problem
attributing who paid what.
The 30% that is to be spent on the Internet good, not one $0.02 has been spent
Olafur
ps: Now I can understand what they want to collect money for addresses.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Olafur Gudmundsson ogud at tis.com
3060 Washington Road 301-854-5700
Glenwood MD 21738 301-854-5363
Received: from ietf.org by ietf.org id aa14990; 11 Jan 97 18:07 EST
Received: from pax.cavebear.com by ietf.org id aa14123; 11 Jan 97 17:58 EST
Received: from localhost by CaveBear.com (SMI-8.6/SMI-SVR4)
id OAA25773; Sat, 11 Jan 1997 14:56:04 -0800
Date: Sat, 11 Jan 1997 14:56:03 -0800 (PST)
Sender:ietf-request at ietf.org
From: Karl Auerbach <karl at cavebear.com>
Reply-To: karl at cavebear.com
To: Bob Packer <bob at packeteer.com>
cc: ietf at ietf.org
Subject: Re: RSVP Can't Handle Spikes??
In-Reply-To: <9701101502.aa19670 at ietf.org>
Message-ID: <Pine.SOL.3.95.970111142657.25705A-100000 at pax.cavebear.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Hi -- Please don't think that we are attacking your product. It actually
sounds rather interesting. The Data Comm article did contain some
language that certainly conveyed, to me anyway, some questionable
statements about TCP/IP networks and RSVP.
> packeteer does not treat all http connections in the same fashion. it
> is a web aware bandwidth management device. Packetshaper policies can
> be set for URLs (with wild card matching), and may typically be
> different for *.html and *.gif and *.jpg files.
I have a number of concerns:
First, I'm concerned about the possibility of uncoordinated algorithms
interacting in unexpected and undesirable ways. (Although I don't
immediately see any sources of trouble from ack-bit supression by a
relaying device.)
I don't know if you/Packateer are doing more than simply ack-bit
supression in TCP streams. Are you going to be doing TCP window size
manipulation or any packet delaying on SYN bearing packets?
As for tools such as a UDP stream shaper -- I think that is a potentially
very useful tool. In my work at Precept Software, we find that when we
snap off a video frame we can end up sending a burst of closely spaced
packets -- the network equivalent of water hammer. In some cases we
insert artificial spacing, but that isn't always possible given the
platform we are running on. A "filter" out on the net that does packet
spacing could be useful in some circumstances.
I believe that Cisco has a traffic shaping mechanism in the works. And I
believe that Microsoft may be doing some similar work in their drivers.
What your product raises is an interesting question (to me anyway) -- Our
current Quality of Service protocols (RSVP and ST-II) essentially
communicate router-to-router. We are starting to think about the issue of
pushing the RSVP-conveyed QoS request information down into the things
that attach routers to one another (these being things like hubs and atm
switches and such). If products such as yours prove useful it seems that
they should fit into the QoS scheme so that it won't be necessary to
twiddle a number of distinct control points.
> To see fred say this is fud is a little troubling, as i don't believe
> he is acquainted with all the details.
Whether the Data Comm article was the result of overexhuberant marketing
or misapprehension by the reporter, I don't know. The net result is that
there are people now walking the streets who think that the net is somehow
in danger of "spikes". Given the various algorithms now found in most TCP
engines, the only "spike" I see with web traffic is the still enormous
number of TCP connection set-up/teardown (or reset) cycles caused by http
1.0. And I don't see how your product deals with those at all.
--karl--
Received: from ietf.org by ietf.org id aa15345; 11 Jan 97 18:15 EST
Received: from cnri by ietf.org id aa15256; 11 Jan 97 18:12 EST
Received: from pax.cavebear.com by CNRI.Reston.VA.US id aa17594;
11 Jan 97 18:13 EST
Received: from localhost by CaveBear.com (SMI-8.6/SMI-SVR4)
id PAA25814; Sat, 11 Jan 1997 15:10:54 -0800
Date: Sat, 11 Jan 1997 15:10:53 -0800 (PST)
Sender:ietf-request at ietf.org
From: Karl Auerbach <karl at cavebear.com>
Reply-To: karl at cavebear.com
To: Olafur Gudmundsson <ogud at tis.com>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Washington Post article on Network Solutions track record
In-Reply-To: <2.2.32.19970111145134.006dc5d4 at popsrvr.hq.tis.com>
Message-ID: <Pine.SOL.3.95.970111150422.25705B-100000 at pax.cavebear.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
> http://www.washingtonpost.com/wp-srv/WPlate/1997-01/11/142L-011197-idx.html
> The 30% that is to be spent on the Internet good, not one $0.02 has been spent
I see that the article says that the reason is that NSF believes there is
a "lack of concensus".
Given the likelihood that a concensus-call will result in our typical
flurry of opinions, there is a substantial chance that the pool will
forever grow and never be used.
Perhaps the 30% should no longer be collected and current fund be returned
to those who paid.
--karl--
Received: from ietf.org by ietf.org id aa18898; 11 Jan 97 20:00 EST
Received: from cnri by ietf.org id aa18779; 11 Jan 97 19:56 EST
Received: from access.netaxs.com by CNRI.Reston.VA.US id aa19142;
11 Jan 97 19:56 EST
Received: from unix1.netaxs.com (mail at unix1.netaxs.com [207.8.186.3])
by access.netaxs.com (8.8.4/8.8.4) with ESMTP
id TAA09169; Sat, 11 Jan 1997 19:54:31 -0500 (EST)
Received: (from cook at localhost)
by unix1.netaxs.com (8.8.4/8.8.4)
id TAA16769; Sat, 11 Jan 1997 19:54:30 -0500 (EST)
Date: Sat, 11 Jan 1997 19:54:29 -0500 (EST)
Sender:ietf-request at ietf.org
From: Gordon Cook <cook at netaxs.com>
To: Karl Auerbach <karl at cavebear.com>
cc: Olafur Gudmundsson <ogud at tis.com>, ietf at CNRI.Reston.VA.US
Subject: Re: Washington Post article on Network Solutions track record
In-Reply-To: <Pine.SOL.3.95.970111150422.25705B-100000 at pax.cavebear.com>
Message-ID: <Pine.SUN.3.95.970111184825.5661D-100000 at unix1.netaxs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sat, 11 Jan 1997, Karl Auerbach wrote:
>
> > http://www.washingtonpost.com/wp-srv/WPlate/1997-01/11/142L-011197-idx.html
>
> > The 30% that is to be spent on the Internet good, not one $0.02 has been spent
>
> I see that the article says that the reason is that NSF believes there is
> a "lack of concensus".
I wonder how many people in the community even realize that there is $10
million in the fund waiting to be applied to internet intellectual
infrastructure?
NSF has had i believe a couple of Kennedy School meetings, and a CIX
meeting in washington DC to explore ideas as to what should be done with
the money. Indeed i gather there was no consensus. Damn shame! because
I think that NSF might soon do exactly as Karl suggests -- order the
money be returned. Too bad if this happens. $30 back for each hundred
paid....back to a few hundred thousand different people. What a
logistical night mare for an NSI that still hasn't got its billing
procedures worked out.
I have my own example. I have never received a bill for
cook at cookreport.com registered back in november 1994. I have let NSI
know this and a very high ranking person there said about 6 weeks ago that
he would find out what happened and get back to me..... BY NSI's own
reckoning I SHOULD have gotten a bill in september 1996.
So I have to wonder how accurate the return of the 10 million would be?
And what the over head extracted by NSI to do the returns would be? I'll
bet at least $10 of each 30 due to be refunded. (unless NSI would be
willing to eat the administrative cost of the refunds.) So tell me why,
to name just one possibility, it would be objectionable to have the
infrastructure fund pay for the maintenance of the IETF secretariat???
>
> Given the likelihood that a concensus-call will result in our typical
> flurry of opinions, there is a substantial chance that the pool will
> forever grow and never be used.
>
> Perhaps the 30% should no longer be collected and current fund be returned
> to those who paid.
>
> --karl--
>
Seems to me if the 30% were to be refunded that NSF SHOULD give the
community
advance notice that this is its intention to do so and give the IAB notice
that it had say 180 days to come up with a plan that the community would
accept. If no plan OR no acceptance by that time, then the community
would be forewarned that NSI would be told to make the refund. I would
hope that the very thought of the negligible return to individuals and
the waste involved in the over head of the return, plus the likelihood
that the process would never be audited, would be enough to cause folk to
accept - if necessary- reasonable compromises in the use of the money. I
would like to see the money used to strengthen the IETF rather than
returned.
PS. I do not mean anything that I have written to be interpreted as a
swipe against NSI. their role in the DNS dispute is something i have
steered clear of in the past and desire to do so in the future
************************************************************************
The COOK Report on Internet For subsc. pricing & more than
431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material
(609) 882-2572 (phone & fax) visit http://pobox.com/cook/
Internet: cook at cookreport.com For NEW study: EVOLVING INTER-
NET ARCHITECTURE, a 222 page Handbook http://pobox.com/cook/evolving.html
************************************************************************
Received: from ietf.org by ietf.org id aa20052; 11 Jan 97 20:30 EST
Received: from cnri by ietf.org id aa19896; 11 Jan 97 20:27 EST
Received: from rip.psg.com by CNRI.Reston.VA.US id aa19707; 11 Jan 97 20:27 EST
Received: by rip.psg.com
id m0vjEgI-0007zaC; Sat, 11 Jan 97 17:25 PST (Smail3.1.29.1#1)
Message-Id: <m0vjEgI-0007zaC at rip.psg.com>
Date: Sat, 11 Jan 97 17:25 PST
Sender:ietf-request at ietf.org
From: Randy Bush <randy at psg.com>
To: Gordon Cook <cook at netaxs.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Washington Post article on Network Solutions track record
References: <Pine.SOL.3.95.970111150422.25705B-100000 at pax.cavebear.com>
<Pine.SUN.3.95.970111184825.5661D-100000 at unix1.netaxs.com>
Source-Info: From (or Sender) name not authenticated.
If you have ever tried to use a significant amount of point of contact
information from any part of the infrastructure, whois, radb, ... you
would have deep sympathy for NSI.
See Suzanne's and Bill's whines from ire, cidrd, ... when trying to find
POCs for swamp owners.
randy
Received: from ietf.org by ietf.org id aa03947; 12 Jan 97 2:04 EST
Received: from cnri by ietf.org id aa03743; 12 Jan 97 1:56 EST
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa03340;
12 Jan 97 1:56 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1])
by black-ice.cc.vt.edu (8.8.4/8.8.4) with ESMTP
id BAA20120; Sun, 12 Jan 1997 01:54:03 -0500
Message-Id: <199701120654.BAA20120 at black-ice.cc.vt.edu>
To: "David R. Conrad" <davidc at apnic.net>
cc: naipr at internic.net, IETF <ietf at CNRI.Reston.VA.US>
Subject: Re: Just wondering about the silence
In-reply-to: Your message of "Thu, 09 Jan 1997 19:55:03 GMT."
<199701091955.TAA01629 at nostromo.jp.apnic.net>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
Pgp-Action: PGP/MIME-signclear; rfc822=off; originator="<Valdis.Kletnieks at vt.edu>"
X-URL: http://black-ice.cc.vt.edu/~valdis/
References: <199701091955.TAA01629 at nostromo.jp.apnic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28560.853052042.1 at black-ice.cc.vt.edu>
Date: Sun, 12 Jan 1997 01:54:02 -0500
Source-Info: From (or Sender) name not authenticated.
On Thu, 09 Jan 1997 19:55:03 GMT, "David R. Conrad" said:
> >(As an aside, are you saying "yes they can", or "no they cant"?
> They can't and expect to have additional space allocated without an
> explanation for the rather dramatic waste.
Ahh.. Now I start seeing why the rates are so high. You want
to spend time looking over the network plan and see if they are
being "optimal" or not.
Is a /24 a waste if they're using one SLIP connetion, since it
"could" fit into a /30? Maybe. Maybe not. What happens NEXT
month, when they connect another office in another city, and THAT
one needs a local /28 for existing machines? Oh, wait, a /28 has
to be on a /28 boundary, so we probably end up allocating a /30
for the first SLIP, a /30 for the second, waste a /30, and then we're
back on a /28 boundary.
Of course, if they can't *commit* to saying 'Yes, we will wire
the 3rd city office", and hem and haw, I could see how you
could spend a lot of money trying to decide if there's "waste".
> >Who ever had a problem with 255.255.255.0 as a subnet mask for 2 hosts?
> The registries.
Umm.. why do the registries *care*? The owner paid for a /24, give
them a /24. Explain why a registry cares if it's a /24 for 1 slip
line, or a /24 for 64 slip lines, or a /24 for an ethernet that
only has 2 hosts on it currently, or....
ESPECIALLY since the registry doesn't list any rates for smaller than
a /24 ANYHOW. There's no incentive at all for people to conserve
under a /24.
I don't remember seeing any incentive for not hopping to a /16 if
you don't fit inside a /24. (I may be wrong, being unable to access
the (moved) WWW page, but I remember being struck by the lack of
a price point at /20).
You want them to *register*, just take the payment and *register* them.
Experience with the nameservers has shown that *that* is challenge
enough. You want them to *conserve*, give them a reason to conserve.
You want them to *learn*, charge them seperately.
That's 3 different goals. Make sure you're after the right ones.
> >Now, let's say that of the $2,500 *minimum* you wish to charge, $50 goes
> >to actually doing the registration. This means that you are charging
> >$2,450 dollars to explain CIDR. Are you saing that CIDR is on the order
> >of 100 times more complicated to explain than secondary nameservers?
>
> Please re-read my previous note and focus on the various things the
> registries are required to discuss with appliacants. CIDR is a large part,
> but there are many other topics we are required to "consult" on.
My prior commentary still stands. There's good RFC's written. There's
good commercially published old-style-printed books. There's
good educational classes available. Please cut back on the
"consulting", build a checklist of "If you don't understand point XYZ,
here are resources to help you learn".
I can accept that in the Pacific Rim, and in Africa, and in parts of
Europe, the general clue level regarding networking is low enough
that hand-holding is needed. But in the US, with it's current
glut of ISP's, and AT&T advertising "Catch the wave" with a visual
of a banking-district street growing into a tsunami of asphalt,
the *registry's* business is to *register*.
If they are an ISP, and need that level of handholding, they'll
get eaten for lunch *anyhow*, and you'll just have to do the
paperwork when they return their address space or assign it to
the people who bought them out. If they are a private concern,
and need that level of handholding, they'll realize it soon enough
and find a rent-a-netadmin someplace. If not, they'll either
bankrupt themselves, or their ISP will get fed up and pull the
plug. In any case, in the US, networking cluelessness is self-correcting.
"Consider it evolution in action". When I apply for a driver's
license, the Commonwealth of Virginia doesn't give driving lessons,
they merely give the standard tests and issue a piece of plastic
if you fill the blanks in correctly. When I order a phone line,
the local telco doesn't give classes on how to use a phone, they
just (if needed) pull cable, provide a dial tone, a phone book,
and I don't hear from them again until the monthly bill. Other
services (such as actually installing interior wiring and phones)
*are* available, but only on request and payment of additional fees.
I'm having a hard time thinking of any *other* registries that
need to do consulting just because a significant proportion of
applicants cannot manage to get it right by themselves. On the
other hand, at least in Virginia, you cannot close a real estate
transaction without a lawyer's assistance (the theory being that
the average citizen can't get it right by themselves, but a lawyer
is trained to do this). All the same, the only thing the
county clerk does is shuffle papers, and if they find a problem,
hand it back to the lawyers and say "Fix this".
Correction: I *can* think of an example - if you find yourself
unable to complete the IRS tax forms, you can call the IRS
toll-free, no-charge, and ask them for assistance. Of course,
there *have* been those studies showing that up to 30% of the
dispensed assistance is incorrect...
Maybe there's a lesson here.
> >I won't comment on the wisdom of charging MIT $2,559,950 to explain
> >CIDR to them. I strongly suspect that they already understand.
>
> See Kim's note.
My commentary still stands. I severely doubt that any players will
be emerging that will *want* a /8 sized address, and all the operational
requirements that implies, that will need CIDR explained to them.
If there was a desire to give financial disincentives to grabbing
large wasted space in the IPv4 address space, this would be a way
to approach it. I wouldn't even mind it very much if that was how
it was *documented*. However, trying to claim that it's to support
"consulting" and the like strikes me as almost an insult to our
collective intelligence. Especially given the astronomical rates
that will be charged to non-ISP large networks.
/Valdis (*still* waiting for a *straight* answer on why a /8 will
cost $2.5M to a non-ISP, especially when it's only $20K to an ISP).
Received: from ietf.org by ietf.org id aa05166; 12 Jan 97 2:44 EST
Received: from cnri by ietf.org id aa05046; 12 Jan 97 2:42 EST
Received: from flying.penguin.net by CNRI.Reston.VA.US id aa04129;
12 Jan 97 2:42 EST
Received: from localhost (ron at localhost) by flying.penguin.net (8.8.3/8.6.12) with SMTP id CAA09282; Sun, 12 Jan 1997 02:40:18 -0500
Date: Sun, 12 Jan 1997 02:40:17 -0500 (EST)
Sender:ietf-request at ietf.org
From: Ron Fitzherbert <ron at penguin.net>
To: Valdis.Kletnieks at vt.edu
cc: "David R. Conrad" <davidc at apnic.net>, naipr at internic.net,
IETF <ietf at CNRI.Reston.VA.US>
Subject: Re: Just wondering about the silence
In-Reply-To: <199701120654.BAA20120 at black-ice.cc.vt.edu>
Message-ID: <Pine.LNX.3.95.970112023405.9253B-100000 at flying.penguin.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
On Sun, 12 Jan 1997 Valdis.Kletnieks at vt.edu wrote:
> /Valdis (*still* waiting for a *straight* answer on why a /8 will
> cost $2.5M to a non-ISP, especially when it's only $20K to an ISP).
Especially considering that the non-ISP is probably going to *use* the
addresses themselves while the ISP is going to *resell* them for $2.5M
(more or less).... gee, what a concept -- my ISP will "buy" a /8 for $20K
and then sell it to a large corp for say $2.25M (it'll save them $250K).
"Charging" for address space is just plain SILLY. Charging for providing
a service (such as in-addr/whois) could be argued as reasonable -- but
when we're talking about IP's we're talking about a very small "cost".
The only "fair" way (IMHO) to charge for IPs would be if it were on an
individual IP basis (and let's see how quickly we melt-down if we start
host-routing all of the IP space!).
Ron
---------------- Ronald J. Fitzherbert, President ---------------
Flying Penguin Productions Limited - Arlington, VA (USA)
*** finger isoc at penguin.net for ISOC Nomination Petition Info ***
1.703.358.9219 (voice) 1.703.522.2798 (telefax)
-------------------- http://www.penguin.net/ --------------------
Received: from ietf.org by ietf.org id aa17239; 13 Jan 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa15290; 13 Jan 97 9:48 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.edu
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ospf-version2-09.txt
Date: Mon, 13 Jan 1997 09:48:37 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701130948.aa15290 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 Open Shortest Path First IGP
Working Group of the IETF.
Title : OSPF Version 2
Author(s) : J. Moy
Filename : draft-ietf-ospf-version2-09.txt
Pages : 225
Date : 01/10/1997
This memo documents version 2 of the OSPF protocol. OSPF is a link-state
routing protocol. It is designed to be run internal to a single Autonomous
System. Each OSPF router maintains an identical database describing the
Autonomous System's topology. From this database, a routing table is
calculated by constructing a shortest-path tree.
OSPF recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic. OSPF provides
support for equal-cost multipath. Separate routes can be calculated
for each IP Type of Service. An area routing capability is provided,
enabling an additional level of routing protection and a reduction in
routing protocol traffic. In addition, all OSPF routing protocol
exchanges are authenticated.
The differences between this memo and RFC 1583 are explained in
Appendix G. All differences are backward-compatible in nature.
Implementations of this memo and of RFC 1583 will interoperate.
Please send comments to ospf at gated.cornell.edu.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ospf-version2-09.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ospf-version2-09.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ospf-version2-09.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970110173202.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ospf-version2-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-version2-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970110173202.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17222; 13 Jan 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa15289; 13 Jan 97 9:48 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: dhcp-v4 at bucknell.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-dhc-timezone-01.txt
Date: Mon, 13 Jan 1997 09:48:36 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701130948.aa15289 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 Dynamic Host Configuration
Working Group of the IETF.
Title : DHCP Option for IEEE 1003.1 POSIX Timezone
Specifications
Author(s) : M. Carney
Filename : draft-ietf-dhc-timezone-01.txt
Pages : 2
Date : 01/10/1997
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for
passing configuration information to hosts on a TCP/IP network. This
document defines a new option to extend the available option codes [3].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-dhc-timezone-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-timezone-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dhc-timezone-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: <19970110145815.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dhc-timezone-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dhc-timezone-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970110145815.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17215; 13 Jan 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa15363; 13 Jan 97 9:50 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-rekhter-tagswitch-arch-00.txt
Date: Mon, 13 Jan 1997 09:50:05 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701130950.aa15363 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Tag Switching Architecture - Overview
Author(s) : Y. Rekhter, B. Davie, E. Rosen,
G. Swallow, D. Farinacci
Filename : draft-rekhter-tagswitch-arch-00.txt
Pages : 21
Date : 01/09/1997
This document provides an overview of tag switching. Tag switching is a way
to combine the label-swapping forwarding paradigm with network layer
routing. This has several advantages. Tags can have a wide spectrum of
forwarding granularities, so at one end of the spectrum a tag could be
associated with a group of destinations, while at the other a tag could be
associated with a single application flow. At the same time forwarding
based on tag switching, due to its simplicity, is well suited to high
performance forwarding. These factors facilitate the development of a
routing system which is both functionally rich and scalable. Finally, tag
switching simplifies integration of routers and ATM switches by employing
common addressing, routing, and management procedures.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-rekhter-tagswitch-arch-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rekhter-tagswitch-arch-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rekhter-tagswitch-arch-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970109133819.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rekhter-tagswitch-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rekhter-tagswitch-arch-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970109133819.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17223; 13 Jan 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa15288; 13 Jan 97 9:48 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-ncache-00.txt
Date: Mon, 13 Jan 1997 09:48:32 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701130948.aa15288 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 DNS IXFR, Notification, and
Dynamic Update Working Group of the IETF.
Title : Negative Caching of DNS Queries (DNS NCACHE)
Author(s) : M. Andrews
Filename : draft-ietf-dnsind-ncache-00.txt
Pages : 3
Date : 01/10/1997
When [RFC1034] was written there were no DNS servers that implemented
negative caching [RFC1034 Section 4.3.4]. This document replaces [RFC1034
Section 4.3.4] in the light of experience.
Negative caching is a optional part of the DNS specification and deals with
the caching of the non-existence of a RRset or domainname.
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-ncache-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-dnsind-ncache-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-dnsind-ncache-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: <19970110111757.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-dnsind-ncache-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dnsind-ncache-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970110111757.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa17229; 13 Jan 97 10:18 EST
Received: from ietf.ietf.org by ietf.org id aa15322; 13 Jan 97 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-rauschenbach-pop3-framework-00.txt
Date: Mon, 13 Jan 1997 09:48:41 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701130948.aa15322 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : POP3 Service Extensions
Author(s) : D. Rauschenbach
Filename : draft-rauschenbach-pop3-framework-00.txt
Pages : 5
Date : 01/10/1997
This memo defines a framework for extending the POP3 service by defining a
means whereby a POP3 server can inform a client as to the service
extensions it supports.
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-rauschenbach-pop3-framework-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-rauschenbach-pop3-framework-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-rauschenbach-pop3-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: <19970110175407.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-rauschenbach-pop3-framework-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-rauschenbach-pop3-framework-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970110175407.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from cnri by ietf.org id aa21763; 13 Jan 97 11:01 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa13447;
13 Jan 97 11:01 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <OAA06727 at pad-thai.cam.ov.com>; Mon, 13 Jan 1997 14:18:13 GMT
Message-Id: <199701131418.JAA22662 at gza-client1.cam.ov.com>
To: cat-ietf at mit.edu
Cc: linn at cam.ov.com
Subject: Fwd: RFC 2078 on GSS-API
Date: Mon, 13 Jan 1997 09:18:08 -0500
From: John Linn <linn at cam.ov.com>
Precedence: bulk
Forwarding for the benefit of CAT-WG subscribers who aren't
subscribers to the general IETF announcement list.
--jl
------- Forwarded Message
Received: from ietf.org by pad-thai.cam.ov.com (8.8.4/) with SMTP
id <UAA02611 at pad-thai.cam.ov.com>; Fri, 10 Jan 1997 20:46:00 GMT
Received: from ietf.org by ietf.org id aa14579; 10 Jan 97 13:51 EST
Received: from zephyr.isi.edu by ietf.org id aa14354; 10 Jan 97 13:49 EST
Received: from nam.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA16022>; Fri, 10 Jan 1997 10:45:01 -0800
Message-Id: <199701101845.AA16022 at zephyr.isi.edu>
To: ;@IETF-Announce
Subject: RFC 2078 on GSS-API
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 Jan 97 10:50:37 PST
Sender: ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
Status: U
- --NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2078
Title: Generic Security Service Application Program
Interface, Version 2
Author: J. Linn
Date: January 1997
Mailbox: John.Linn at ov.com
Pages: 85
Characters: 185990
Obsoletes: 1508
URL: ftp://ds.internic.net/rfc/rfc2078.txt
This memo revises RFC-1508, making specific, incremental changes in
response to implementation experience and liaison requests. It is
intended, therefore, that this memo or a successor version thereto
will become the basis for subsequent progression of the GSS-API
specification on the standards track. This document is a product of
the Common Authentication Technology Working Group.
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: <970110104500.RFC at ISI.EDU>
SEND /rfc/rfc2078.txt
- --OtherAccess
Content-Type: Message/External-body;
name="rfc2078.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <970110104500.RFC at ISI.EDU>
- --OtherAccess--
- --NextPart--
------- End of Forwarded Message
Received: from ietf.org by ietf.org id aa22649; 13 Jan 97 11:43 EST
Received: from cnri by ietf.org id aa22148; 13 Jan 97 11:12 EST
Received: from gatekeeper.chbs.ciba.com by CNRI.Reston.VA.US id aa13790;
13 Jan 97 11:12 EST
Received: from cgchm.is.chbs by gatekeeper.chbs.ciba.com; (5.65v3.2/1.1.8.2/12Mar96-0208PM)
id AA03220; Mon, 13 Jan 1997 16:07:40 +0100
Received: from mta1.is.chbs by Central.CHBS.CIBA.COM
id AA15335; Mon, 13 Jan 1997 16:01:13 +0100 (5.65c8/Ciba2.0-C1.1)
Received: by mta1.is.chbs (5.65v3.2/DEC-Ultrix/4.3)
id AA00006; Mon, 13 Jan 1997 16:00:58 +0100
X400-Received: by mta chbs-mta1 in /PRMD=ciba/ADMD=attmail/C=ch/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 13 Jan 1997 15:00:58 +0000
X400-Received: by /PRMD=CIBA/ADMD=ATTMAIL/C=CH/;
converted ((1) (0) (10021) (7) (1) (0) (1), (1) (0) (10021) (7) (1) (0) (6));
Relayed; 13 Jan 1997 09:26:23 +0500
Date: 13 Jan 1997 09:26:23 +0500
X400-Originator: raymond.obrien at usgr-msm3.ustc.mhs.ciba.com
X400-Mts-Identifier: [/PRMD=CIBA/ADMD=ATTMAIL/C=CH/;970113042623]
Sender:ietf-request at ietf.org
From: O'Brien Raymond MSM TCAD US <raymond.obrien at ustc.mhs.ciba.com>
To: "'TWEEKS at PSEG.COM'" <ietf at CNRI.Reston.VA.US>
Subject: Internet
Importance: normal
Autoforwarded: FALSE
Message-Id: <"000BFD68.MAI*/PN=raymond.obrien/OU=usgr-msm3/OU=ustc/O=ciba/PRMD=CIBA/ADMD=ATTMAIL/C=CH/"@MHS>
Original-Encoded-Information-Types: (2) (6) (3) (4) (11)
Content-Identifier: CSI NC V3.0
X400-Content-Type: P2-1988 (22)
Priority: normal
Source-Info: From (or Sender) name not authenticated.
This is a internet mail message to T. Weeks @ PSE&G
Received: from ietf.org by ietf.org id aa22652; 13 Jan 97 11:43 EST
Received: from cnri by ietf.org id aa22134; 13 Jan 97 11:12 EST
Received: from gatekeeper.chbs.ciba.com by CNRI.Reston.VA.US id aa13785;
13 Jan 97 11:12 EST
Received: from cgchm.is.chbs by gatekeeper.chbs.ciba.com; (5.65v3.2/1.1.8.2/12Mar96-0208PM)
id AA03202; Mon, 13 Jan 1997 16:07:28 +0100
Received: from mta1.is.chbs by Central.CHBS.CIBA.COM
id AA15315; Mon, 13 Jan 1997 16:01:02 +0100 (5.65c8/Ciba2.0-C1.1)
Received: by mta1.is.chbs (5.65v3.2/DEC-Ultrix/4.3)
id AA02802; Mon, 13 Jan 1997 16:00:47 +0100
X400-Received: by mta chbs-mta1 in /PRMD=ciba/ADMD=attmail/C=ch/;
converted ((1) (0) (10021) (7) (1) (0) (1));
Relayed; 13 Jan 1997 15:00:46 +0000
X400-Received: by /PRMD=CIBA/ADMD=ATTMAIL/C=CH/;
converted ((1) (0) (10021) (7) (1) (0) (1));
Relayed; 13 Jan 1997 09:24:46 +0500
Date: 13 Jan 1997 09:24:46 +0500
X400-Originator: raymond.obrien at usgr-msm3.ustc.mhs.ciba.com
X400-Mts-Identifier: [/PRMD=CIBA/ADMD=ATTMAIL/C=CH/;970113042446]
Sender:ietf-request at ietf.org
From: O'Brien Raymond MSM TCAD US <raymond.obrien at ustc.mhs.ciba.com>
To: Tim Weeks <ietf at CNRI.Reston.VA.US>
Importance: normal
Autoforwarded: FALSE
Message-Id: <"000BFD5D.MAI*/PN=raymond.obrien/OU=usgr-msm3/OU=ustc/O=ciba/PRMD=CIBA/ADMD=ATTMAIL/C=CH/"@MHS>
Original-Encoded-Information-Types: (2) (6) (3) (4) (11)
Content-Identifier: CSI NC V3.0
X400-Content-Type: P2-1988 (22)
Priority: normal
Source-Info: From (or Sender) name not authenticated.
Received: from cnri by ietf.org id aa01159; 13 Jan 97 16:44 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa21853;
13 Jan 97 16:38 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <TAA18852 at pad-thai.cam.ov.com>; Mon, 13 Jan 1997 19:09:50 GMT
Message-Id: <199701131909.OAA30529 at postman.osf.org>
X-Mailer: exmh version 1.6.9 8/22/96
To: cat-ietf at mit.edu
Subject: NSPW call for papers
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 13 Jan 1997 14:09:31 -0500
From: Mary Ellen Zurko <zurko at osf.org>
Precedence: bulk
PRELIMINARY CALL FOR PAPERS
NEW SECURITY PARADIGMS '97
A workshop sponsored by ACM and the University of Newcastle upon Tyne.
Langdale Hotel
Great Langdale, Cumbria, UK
23 - 26 September 1997
Paradigm shifts disrupt the status quo, destroy outdated ideas, and open the
way to new possibilities. This workshop explores deficiencies of current
computer security paradigms and examines radical new models which address
those deficiencies. Previous years' workshops have identified problematic
aspects of traditional security paradigms and explored a variety of possible
alternatives. Participants have discussed alternative models for access
control, intrusion detection; new definitions of security, privacy, secrecy
and trust; biological and economic models of security; multiple policies;
and a wide variety of other topics. The 1997 workshop will strike a balance
between building on the foundations laid in past years and exploring in new
directions.
We offer a creative and constructive workshop environment for about
25 participants at the Langdale Hotel in the English Lake District.
Because of the workshop format, the organizers urge submitters to arrange to
be present for all three days of the conference; authors' ability to attend
for the duration of the workshop will be considered when evaluating
submissions for acceptance.
Dress is casual. The tone of the workshop is exploratory rather than
critical. The refereed papers will be printed in a workshop proceedings.
To participate, please submit the following, preferably via e-mail, to both
Program Chairs (Mary Ellen Zurko and Catherine Meadows) at the e-mail
addresses listed below by 4 April 1997:
(1) Your paper
This should be either a research paper or a 5-10 page position paper.
Softcopy submissions should be in Postscript or ASCII format.
Papers may be submitted in hardcopy. To submit hardcopy, please mail
five (5) copies to Program co-chair Mary Ellen Zurko at the address
listed below; please allow adequate time for delivery; the hardcopy
deadline is 28 March 1997.
(2) A justification
This should describe, in one page or less, why you think your paper
is appropriate for the New Security Paradigms Workshop. A good
justification will describe which aspects of the status-quo security
paradigm your paper rejects and which new model or models your paper
proposes or extends.
(3) An attendance statement
This should state how many authors wish to attend the workshop, and
should indicate whether at least one author will be able to attend for
the entire duration of the workshop.
The Program Committee will referee the papers and notify authors of
acceptance status by 13 June 1997.
We expect a limited number of scholarships to be available.
More information will be provided on-line as it becomes available.
E-mail to: newparadigms97 at opengroup.org
use anonymous FTP from: ftp.cs.uwm.edu
in directory: /pub/new-paradigms
Use World Wide Web from: http://www.cs.uwm.edu/~new-paradigms
NEW SECURITY PARADIGMS '97 WORKSHOP ORGANIZERS
Steering Committee: Tom Haigh, Bob Blakley, Mary Ellen Zurko,
Catherine Meadows, John Dobson, Hilary Hosmer
Workshop Co-Chair: Tom Haigh
voice: +1 (612) 628-2738
fax : +1 (612) 628-2701
email: Haigh at sctc.com
post : Tom Haigh
Secure Computing Corp.
2678 Long Lake Road
Roseville, MN 55113 USA
Workshop Co-Chair: Bob Blakley
voice: +1 (512) 838-8133
fax : +1 (512) 838-0156
email: blakley at vnet.ibm.com
post : Bob Blakley
IBM
11400 Burnet Road, Mail Stop 9134
Austin, TX 78758 USA
Program Committee Co-Chair: Mary Ellen Zurko
voice: +1 (617) 621-7231
fax : +1 (617) 621-8696
email: zurko at osf.org
post : Mary Ellen Zurko
The Open Group Research Institute
11 Cambridge Center
Cambridge, MA 02142 USA
Program Committee Co-Chair: Catherine Meadows
voice: +1 (202) 767-3490
fax : +1 (202) 404-7942
email: Meadows at itd.nrl.navy.mil
post : Catherine Meadows
Naval Research Laboratory
Code 5543
Washington, DC 20375 USA
Program Committee:
Shaw Chuang University of Cambridge
John Dobson University of Newcastle
Steven Greenwald Naval Research Laboratory
Steven Hofmeyr University of New Mexico
Hilary Hosmer Data Security, Inc.
Sverker Janson Swedish Institute of Computer Science
Audun Josang Norwegian University of Science and Technology
Darrell Kienzle University of Virginia
Tom Lincoln Rand Corporation
Ruth Nelson Information Systems Security
Pierangela Samarati Universita di Milano
Cristina Serban Bell Labs (Lucent Technology)
Marvin Schaefer Arca Systems
Chenxi Wang University of Virginia
Mike Williams
Local Arrangements: John Dobson (Univ. of Newcastle) +44 (191) 222 8228
Scholarships: chair to be announced; contact workshop co-chairs
Publications: chair to be announced; contact workshop co-chairs
Publicity: Yvo Desmedt (Univ. of Wisconsin) +1 (414) 229-6762
Treasurer and Registration Chair: Dixie Baker (SAIC) +1 (310) 613-3606
ACM SIGSAC Chair: Ravi Sandhu (George Mason Univ.) +1 (703) 993-1659
ACM Senior Program Director: Julie Goetz (ACM) +1 (212) 626-0610
Received: from ietf.org by ietf.org id aa02850; 13 Jan 97 17:58 EST
Received: from cnri by ietf.org id aa02542; 13 Jan 97 17:44 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa23824;
13 Jan 97 17:44 EST
Received: from dworkin.wustl.edu by venera.isi.edu (5.65c/5.61+local-26)
id <AA28463>; Mon, 13 Jan 1997 14:42:16 -0800
Received: (from milind at localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA15444 for ietf at venera.isi.edu; Mon, 13 Jan 1997 16:44:35 -0600
Date: Mon, 13 Jan 1997 16:44:35 -0600
Sender:ietf-request at ietf.org
From: "Milind M. Buddhikot" <milind at dworkin.wustl.edu>
Message-Id: <199701132244.QAA15444 at dworkin.wustl.edu>
To: ietf at isi.edu
Subject: Last CFP for NOSSDAV97: (Sub. Deadline Jan 15, 1997)
Source-Info: From (or Sender) name not authenticated.
Hi:
Enclosed please find the last cirulation of 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 note that the deadline for submissions is Jan 15, 1997 (fast
approaching). I will like to urge you to consider submitting some
of your best work for this workshop.
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
Dilip Kandlur, IBM, TJ Watson 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
Hideyuki Tokuda, Keio University, Japan
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 aa05159; 13 Jan 97 20:20 EST
Received: from SOUTH-STATION-ANNEX.MIT.EDU by ietf.org id aa05026;
13 Jan 97 20:07 EST
Received: from DCL.MIT.EDU by MIT.EDU with SMTP
id AA08427; Mon, 13 Jan 97 20:05:19 EST
Received: by dcl.MIT.EDU (5.x/4.7) id AA00882; Mon, 13 Jan 1997 20:05:20 -0500
Date: Mon, 13 Jan 1997 20:05:20 -0500
Message-Id: <9701140105.AA00882 at dcl.MIT.EDU>
Sender:ietf-request at ietf.org
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: karl at cavebear.com
Cc: Bob Packer <bob at packeteer.com>, ietf at ietf.org
In-Reply-To: Karl Auerbach's message of Sat, 11 Jan 1997 14:56:03 -0800 (PST),
<Pine.SOL.3.95.970111142657.25705A-100000 at pax.cavebear.com>
Subject: Re: RSVP Can't Handle Spikes??
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Source-Info: From (or Sender) name not authenticated.
Date: Sat, 11 Jan 1997 14:56:03 -0800 (PST)
From: Karl Auerbach <karl at cavebear.com>
I don't know if you/Packateer are doing more than simply ack-bit
supression in TCP streams. Are you going to be doing TCP window size
manipulation or any packet delaying on SYN bearing packets?
I believe that Cisco has a traffic shaping mechanism in the works. And I
believe that Microsoft may be doing some similar work in their drivers.
Note that Linux has a relatively simple traffic shaper included in the
2.1 development series, which people who are interested in this sort of
thing might want to take a quick look at.
- Ted
Received: from ietf.org by ietf.org id aa22750; 14 Jan 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa21610; 14 Jan 97 9:33 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: roamops at tdmx.rutgers.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-roamops-roamreq-02.txt
Date: Tue, 14 Jan 1997 09:33:18 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701140933.aa21610 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 Roaming Operations Working
Group of the IETF.
Title : Dialup Roaming Requirements
Author(s) : B. Aboba, G. Zorn
Filename : draft-ietf-roamops-roamreq-02.txt
Pages : 15
Date : 01/13/1997
This document describes the features required for the provision of "roaming
capability" for dialup Internet users, as well as offering some suggestions
for future protocol standardization work. "Roaming capability" is defined
as the ability to use any one of multiple Internet service providers
(ISPs), while maintaining a formal, customer-vendor relationship with only
one. Examples of cases where roaming capability might be required include
ISP "confederations" and ISP-provided corporate network access support.
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-roamops-roamreq-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-roamops-roamreq-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-roamops-roamreq-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: <19970113161458.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-roamops-roamreq-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-roamops-roamreq-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970113161458.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa22758; 14 Jan 97 9:58 EST
Received: from ietf.ietf.org by ietf.org id aa21594; 14 Jan 97 9:33 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-aboba-rtpscale-01.txt
Date: Tue, 14 Jan 1997 09:33:14 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701140933.aa21594 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Alternatives for Enhancing RTP Scalability
Author(s) : B. Aboba
Filename : draft-aboba-rtpscale-01.txt
Pages : 10
Date : 01/13/1997
This document discusses current issues with RTP scalability as well as
describing the advantages and disadvantages of possible solutions.
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-aboba-rtpscale-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-aboba-rtpscale-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-aboba-rtpscale-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: <19970113155715.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-aboba-rtpscale-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-aboba-rtpscale-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970113155715.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa00869; 14 Jan 97 15:10 EST
Received: from callandor.cybercash.com by ietf.org id aa00343;
14 Jan 97 14:55 EST
Received: by callandor.cybercash.com; id OAA00890; Tue, 14 Jan 1997 14:46:34 -0500
Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2)
id xma000867; Tue, 14 Jan 97 14:46:30 -0500
Received: by cybercash.com (4.1/SMI-4.1)
id AA07396; Tue, 14 Jan 97 14:50:09 EST
Date: Tue, 14 Jan 1997 14:50:08 -0500 (EST)
Sender:ietf-request at ietf.org
From: "Donald E. Eastlake 3rd" <dee at cybercash.com>
To: Ned Freed <Ned.Freed at innosoft.com>
Cc: ietf at ietf.org
Subject: Re: I-D ACTION:draft-rfced-info-ryckman-00.txt
In-Reply-To: <01IE167QJ0OKA8DQAA at INNOSOFT.COM>
Message-Id: <Pine.SUN.3.91.970110131352.18651C-100000 at cybercash.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Ned,
The Informational RFC is intended to be an open process and does not imply
any blessing whatsoever. If ignorant people believe that publishing
something as an RFC, in and of itself, means much, the answer is not to
change the RFC process so as to make their false assumptions true but to make
changes such as those proposed in draft-ietf-poisson-ietfdoc-01.txt. If we
were to now change the criterion for being an Informational RFC to imply
review and approval, this would tend to retroactively give such approval to
all the earlier Informational RFCs that were published without collective
review.
John Romkey's comments on the general advisability of publishing
algorithms are fine and I agree with them. And there are many
legitimate reasons why one might want to block an Informational RFC such
as copyright violations, being unrelated to networking, incorporating
false statements about IETF standards, etc.
But I am opposed to censoring Informational RFCs merely because of flaws in
the protocols or procedures they document.
Donald
On Fri, 10 Jan 1997, Ned Freed wrote:
> Date: Fri, 10 Jan 1997 02:43:57 -0800 (PST)
> From: Ned Freed <Ned.Freed at innosoft.com>
> To: "Philip J. Nesser II" <pjnesser at martigny.ai.mit.edu>
> Cc: John Romkey <romkey at apocalypse.org>, ietf at ietf.org
>
> > I normally don't post messages agreeing with others, but John has stated
> > the points so clearly that it seems unnecessary to try and rephrase them.
> > However, I think that this is such a critical point that I want to
> > publically agree.
>
> I also agree, to the point where I don't think this should even be published as
> an informational document in its present form. We're in enough trouble with
> security issues already, thank you -- we don't need to bless something this
> broken with RFC publication. (Remember that RFC carries status regardless of
> the document's actual standing.)
>
> Ned
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
Received: from ietf.org by ietf.org id aa02160; 14 Jan 97 15:58 EST
Received: from ng.netgate.net by ietf.org id aa02082; 14 Jan 97 15:55 EST
Received: from [205.214.160.123] (d29.netgate.net [205.214.160.61]) by ng.netgate.net (8.8.4/8.6.9) with ESMTP id MAA25994; Tue, 14 Jan 1997 12:52:38 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v03100e1caf019d816a37 at [205.214.160.123]>
In-Reply-To: <Pine.SUN.3.91.970110131352.18651C-100000 at cybercash.com>
References: <01IE167QJ0OKA8DQAA at INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 14 Jan 1997 12:32:48 -0800
To: "Donald E. Eastlake 3rd" <dee at cybercash.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: I-D ACTION:draft-rfced-info-ryckman-00.txt
Cc: ietf at ietf.org
Source-Info: From (or Sender) name not authenticated.
At 11:50 AM -0800 1/14/97, Donald E. Eastlake 3rd wrote:
>The Informational RFC is intended to be an open process and does not imply
>any blessing whatsoever. If ignorant people believe that publishing
>something as an RFC, in and of itself, means much, the answer is not to
Don, a small qualifier on your assessment:
It is reasonable and it is not uncommon to attempt a negotiation with the
author of a "questioned" document, to see if they will make alterations,
fold their work in with related IETF work, or otherwise seek a more
productive and integrated outcome. Pure blocking is not in the rule book,
as you note, but "coordination" with the relevant IETF activities is.
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 cnri by ietf.org id aa16344; 15 Jan 97 1:02 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa02402;
15 Jan 97 1:02 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <EAA09748 at pad-thai.cam.ov.com>; Wed, 15 Jan 1997 04:23:03 GMT
Date: Tue, 14 Jan 1997 23:22:58 -0500
Message-Id: <9701150422.AA01386 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu, Martin.Rex at sap-ag.de
In-Reply-To: Martin Rex's message of Fri, 13 Dec 1996 11:03:42 -0800,
<32B1A88E.69A at sap-ag.de>
Subject: Re: your implementation of acquire_cred(BOTH,NO_NAME)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Date: Fri, 13 Dec 1996 11:03:42 -0800
From: Martin Rex <Martin.Rex at sap-ag.de>
I'm wondering what current implementation practice is for Kerberos
and Kerberos-derived mechanisms for the following call:
gss_acquire_cred( ...
desired_name = (gss_name_t)0,
desired_mechs = GSS_C_NO_OID_SET,
cred_usage = GSS_C_BOTH,
... )
when there is a credential cache with fresh credentials for
the principal named foo at YOUR.REALM and the keytab for a server
with your userid that contains an entry for the principal
with the name bar/somehost.f.q.d.n at YOUR.REALM.
Does your gssapi mechanism support this at all?
If it generates an error message, which one?
If it doesn't generate an error message, what kind of credential
do you end up with (i.e. what principal for the initiating
credential and what principal for the accepting credential)?
If there is no error returned, can inquire_cred*() and
init/accept_sec_context() cope with this credential?
If you specify GSS_C_BOTH to gss_acquire_cred(), the current MIT
Kerberos implementation will attempt to obtain acquiring credentials for
host/<hostname>@LOCAL.REALM. It will also attempt to obtain initiating
credentials for the same principal. It must be able to obtain both
acquiring or initiating credentials, or it will return an error.
I'm just curious, because it isn't obvious to me from the spec
what is supposed to happen. I think the general rule of asking
for the "default" instead of passing along a user input is
not generally the most portable solution.
You're right; the specification isn't clear what happens in this case.
- Ted
Received: from cnri by ietf.org id aa17519; 15 Jan 97 3:01 EST
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa04104;
15 Jan 97 3:01 EST
Received: by pad-thai.cam.ov.com (8.8.4/)
id <EAA09529 at pad-thai.cam.ov.com>; Wed, 15 Jan 1997 04:19:31 GMT
Date: Tue, 14 Jan 1997 23:19:26 -0500
Message-Id: <9701150419.AA01383 at dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso at mit.edu>
To: Martin.Rex at sap-ag.de
Cc: cat-ietf at mit.edu, Martin.Rex at sap-ag.de
In-Reply-To: Martin Rex's message of Thu, 12 Dec 1996 11:45:35 -0800,
<32B060DF.11C2 at sap-ag.de>
Subject: Re: inquire_cred with GSS_C_NO_CREDENTIAL
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Precedence: bulk
Martin,
Just after the IETF you raised a number of interesting questions
about the handling of default credentials. My apologies for not getting
back to you sooner, but I've been rather busy with getting the 1.0
Kerberos release out.
Date: Thu, 12 Dec 1996 11:45:35 -0800
From: Martin Rex <Martin.Rex at sap-ag.de>
There seems to be a slight inconsistency in the description of the
use of GSS_C_NO_CREDENTIAL between high level spec and C-Bindings.
As gss_inquire_cred is already in V1, we cannot change the
behaviour, but should consistently document it. The C-Bindings
state that the "default INITIATING" credentials are being queried.
High level doesn't say whether the default initiating or the
default accepting credentials are being queried.
For V1 backward compatibility, the word "INITIATING" should be
used in the high level spec as well -- if this is the current
implementation practice!
This is the current MIT Kerberbos implementation practice, anyway. I
think you're right, and that at our next opportunity, I agree that we
should clarify the high-level specification to state that it is only the
default initiating credentials which are being quired.
Btw. gss_inquire_cred doesn't mention, which mechanisms default
initiating credentials will be queried for a multimechanism
implementation. (The different compounds of the multimechanism
credential might have different characteristics, e.g. different
lifetimes).
This is a good point, and since we haven't specified an authentication
target (as we would in init_sec_context), it really isn't clear what
gss_inquire_cred will do. Its behavior is presumably "unspecified", and
dependent on the implementation; it was for this reason that we
implemented gss_inquire_cred_by_mech().
A related issue: there new call in V2: gss_inquire_cred_by_mech().
This one may acutally return different values for acceptor and
initiator credentials lifetime, so it would in theory be possible to
query both, the default initiating credentials and the default
accepting credentials when GSS_C_NO_CREDENTIAL is passed in.
BUT, these two credentials may identify different users, so it's
probably not a good idea, and the query with GSS_C_NO_CREDENTIAL
should probably remain restricted to the default initiating
credentials just as the C-Bindings currently specify (but missing
in the high level spec).
I agree with you as well that the high-level specification should
restrict gss_inquire_cred_by_mech() to only query the initiating
credentials.
- Ted
Received: from ietf.org by ietf.org id aa20135; 15 Jan 97 6:40 EST
Received: from public1.guangzhou.gd.cn by ietf.org id aa19639;
15 Jan 97 6:24 EST
Received: from PC ([202.96.128.41]) by public1.guangzhou.gd.cn (8.7.5/8.7.3) with ESMTP id TAA27944 for <ietf at ietf.org>; Wed, 15 Jan 1997 19:22:16 +0800 (CST)
Message-ID: <32DDACF2.2968 at public1.guangzhou.gd.cn>
Date: Wed, 15 Jan 1997 19:22:10 -0900
Sender:ietf-request at ietf.org
From: Li Shengtao <gzstlee at public1.guangzhou.gd.cn>
X-Sender: Li Shengtao <gzstlee at public1.guangzhou.gd.cn>
X-Mailer: Mozilla 4.0b1 (Win95; I)
MIME-Version: 1.0
To: ietf at ietf.org
X-Priority: Normal
Content-Type: multipart/alternative; boundary="----------46994F357FBC0"
Source-Info: From (or Sender) name not authenticated.
------------46994F357FBC0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
subscribe
------------46994F357FBC0
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
<HTML><BODY>
<DT>subscribe </DT>
</BODY>
</HTML>
------------46994F357FBC0--
Received: from ietf.org by ietf.org id aa22206; 15 Jan 97 8:49 EST
Received: from ester.dsv.su.se by ietf.org id aa21967; 15 Jan 97 8:43 EST
X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/;
Relayed; 15 Jan 97 14:32:49+0100
Date: 15 Jan 97 14:32:49+0100
Sender:ietf-request at ietf.org
From: Lars Enderin DSV <Lars.Enderin at su-kom.dsv.su.se>
Message-ID: <1467643*Lars.Enderin at su-kom.dsv.su.se>
In-Reply-To: <32DDACF2.2968 at public1.guangzhou.gd.cn>
To: IETF-list <ietf-list at su-kom.dsv.su.se>,
Li Shengtao <gzstlee at public1.guangzhou.gd.cn>,
"'ietf at ietf.org'" <ietf at ietf.org>
Subject: Multipart/alternative a'la Netscape 4.0
Source-Info: From (or Sender) name not authenticated.
Det kommenterade inl{gget {r ett exempel p} hur Netscape 4.0b1
fungerar just nu. Detta ser man med profil rfc:
RFC-822-Headers:
X-Sender: Li Shengtao <gzstlee at public1.guangzhou.gd.cn>
X-Mailer: Mozilla 4.0b1 (Win95; I)
MIME-Version: 1.0
X-Priority: Normal
Content-Type: multipart/alternative; boundary="----------46994F357FBC0"
Source-Info: From (or Sender) name not authenticated.
Det verkar on|digt med HTML f|r en enda rad!
Received: from ietf.org by ietf.org id aa24693; 15 Jan 97 10:02 EST
Received: from ietf.ietf.org by ietf.org id aa23704; 15 Jan 97 9:41 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-palme-int-print-01.txt
Date: Wed, 15 Jan 1997 09:41:50 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701150941.aa23704 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Making Postscript and Acrobat Files International
Author(s) : J. Palme
Filename : draft-palme-int-print-01.txt
Pages : 3
Date : 01/14/1997
Certain text formats, for example Postscript (extension .ps) and Adobe
Acrobat (extension .pdf) specify exactly the page layout of the printed
document. The commonly used paper format is different in America and the
rest of the world. America uses the "Letter" format, while the rest of the
world uses the "A4" format This means that documents formatted on one
continent may not be easily printable on another continent. This memo gives
advice on how to produce documents which are equally well printable with
the Letter and the A4 formats. By using the advice in this document, you
can put up a document on the Internet, which recipients can print without
problem both in and outside America.
A very short summary of the advice in this document: If you are using
U.S. Letter paper format, ensure that both the left and right margins
are at least 21 mm (0.82 inches). If you are using A4 paper format,
ensure that both the top and bottom margins are at least
35 mm (1.38 inches).
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-palme-int-print-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-palme-int-print-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-palme-int-print-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: <19970114154752.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-palme-int-print-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-palme-int-print-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970114154752.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa25003; 15 Jan 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa23688; 15 Jan 97 9:41 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at list.cren.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-mailext-mail-attributes-07.txt
Date: Wed, 15 Jan 1997 09:41:46 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701150941.aa23688 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 Extensions Working
Group of the IETF.
Title : Common Internet Message Headers
Author(s) : J. Palme
Filename : draft-ietf-mailext-mail-attributes-07.txt
Pages : 19
Date : 01/14/1997
This memo contains a table of commonly occurring headers in headings of
e-mail messages. The document compiles information from other RFCs such as
RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766,
RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which
are not defined in RFCs are also included. For each header, the memo
gives a short description and a reference to the RFC in
which the header is defined.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mailext-mail-attributes-07.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-mail-attributes-07.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mailext-mail-attributes-07.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970114154255.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-mail-attributes-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-mail-attributes-07.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970114154255.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24994; 15 Jan 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa23715; 15 Jan 97 9:41 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mailext at list.cren.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-mailext-new-fields-06.txt
Date: Wed, 15 Jan 1997 09:41:52 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701150941.aa23715 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 Extensions Working
Group of the IETF.
Title : The Supersedes and Expires e-mail headers
Author(s) : J. Palme
Filename : draft-ietf-mailext-new-fields-06.txt
Pages : 4
Date : 01/14/1997
This memo introduces two new e-mail (RFC 822) headers, Supersedes, and
Expires. The postscript version of this IETF draft shows the differences
from its previous version.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-mailext-new-fields-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-new-fields-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mailext-new-fields-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970114155022.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mailext-new-fields-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mailext-new-fields-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970114155022.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa24991; 15 Jan 97 10:05 EST
Received: from ietf.ietf.org by ietf.org id aa23671; 15 Jan 97 9:41 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-06.txt
Date: Wed, 15 Jan 1997 09:41:42 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9701150941.aa23671 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-06.txt
Pages : 10
Date : 01/14/1997
The memo "MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)"
(draft-ietf-mhtml-spec-04.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-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-info-06.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: ftp.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.au
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mhtml-info-06.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19970114153739.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-mhtml-info-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mhtml-info-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19970114153739.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05355; 15 Jan 97 14:25 EST
Received: from cnri by ietf.org id aa05041; 15 Jan 97 14:16 EST
Received: from access.netaxs.com by CNRI.Reston.VA.US id aa19225;
15 Jan 97 14:16 EST
Received: from unix1.netaxs.com (mail at unix1.netaxs.com [207.8.186.3])
by access.netaxs.com (8.8.4/8.8.4) with ESMTP
id OAA08269 for <ietf at cnri.reston.va.us>; Wed, 15 Jan 1997 14:13:57 -0500 (EST)
Received: (from cook at localhost)
by unix1.netaxs.com (8.8.4/8.8.4)
id OAA06989; Wed, 15 Jan 1997 14:13:56 -0500 (EST)
Date: Wed, 15 Jan 1997 14:13:55 -0500 (EST)
Sender:ietf-request at ietf.org
From: Gordon Cook <cook at netaxs.com>
To: ietf at CNRI.Reston.VA.US
Subject: The State of Internet Infrastructure: Reflections from the San Jose IETF
Message-ID: <Pine.SUN.3.95.970115135935.5199B-100000 at unix1.netaxs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Source-Info: From (or Sender) name not authenticated.
Last month I attended my first IETF meeting in San Jose. I viewed it as
quite a valuable opportunity to increase my understanding of quality of
service and business model issues affecting the further growth of the
internet. Indeed, intelligence gathered in sessions, conversations and
interviews at this meeting serves as the contextual framework to the just
published anthology of complete articles from the COOK Report from May 96
through Feb. 97. Some members of the community have found this to be a
very useful overview of the issues facing the Internet in 1997 and have
suggested that I share it more widely. Therefore here it is.
Reflections from the San Jose IETF Meeting:
(Introduction to the 1997 annual Internet infrastructure report, "Evolving
Internet Infrastructure," Ewing, NJ, The COOK Report on Internet, 222
pages, referenced at http://pobox.com/cook/evolving.html)
With considerable awe, we watched in early December nearly two thousand
people come together for five days at the San Jose, California IETF. This
meeting, which takes place three times a year, serves as a kind of
"super-brain" for the network. What happens there is not only the design
of new protocols but a cross fertilization of ideas among people and
companies involved in all aspects of the Internet.
Despite some earlier predictions of doom and recent reports that a major
cable operator like TCI is pulling back from the network, the Internet is
coping amazingly well with its continued growth. In talking with a couple
of dozen key figures, we can confirm that, among those running the
network, there is a general awareness of how the pieces of the Internet
"engine rooms" have developed and how they have assisted in the continued
inter-operability and expansion of other aspects of the network. And
although the pieces of the Internet may appear to an outsider at first
glance to be unrelated, they definitely fit together as distinct parts of
an unwritten master plan.
While the stratification of the network continues, there are encouraging
signs that technology is being developed that will give the Internet a
viable business model through differentiated levels of service.
Furthermore there are signs that these levels of service do not
necessarily mean that the low end of the market will be priced out of
reach of the millions who currently enjoy access to it. Currently, the big
issues are: (1) a potential shortage of fiber; (2) efforts to build
backbones and become tier one providers; (3) attempts through Quality of
Service to offer a more lucrative business model than the current one of
best effort service; (4) creation of both the tools to assess ISP service
and organizations to facilitate ISP coordination.
Coming: a Fiber Crunch Fueled by Bandwidth
Demand?
The most troublesome sign on the horizon is a potential bandwidth crunch.
Given an estimated 500% percent increase in bandwidth consumption in 1996,
we may need to seriously re-examine an Internet business model that
implies the existence of inexhaustible bandwidth and a reality where
bandwidth sufficient to fill demand can be squeezed from deployed fiber
only with the greatest difficulty. We have had a generally held view that
the bandwidth obtainable from the current supply of fiber is
inexhaustible. Signs are emerging that this may not be the case.
We offer four examples. First, in communications with some of the
companies building national backbones, we have found them talking about
large gaps in SONET coverage where the available capacity is either non
existent (Southwest) or already committed that is to say: not actually in
use but committed to someone else in the North East.
They say that no suppliers exist that can provide OC3 and OC12
consistently throughout the US. As a result, often times the only way to
get to OC-3 is to go to multiple vendors and end up taking temporary DS3
circuits. They then find that they must tie up the DS3 circuits to get
equivalent bandwidth to OC3c fiber. The cost of adding new fiber to the
current supply will be phenomenal. Trenching 96 strand single-mode fiber
bundles currently costs between $125 and $350 a foot in metropolitan
areas. It is much less in open areas, provided you have right-of-way.
Second, in November, we were approached by a major consulting company with
questions about Internet bandwidth availability and acquisition. It turned
out that they are under contract to produce a feasibility study for an
entity that is thinking very seriously about installing new fiber from
coast to coast. The consulting firm was employed to find out whether a
market for new fiber existed. It was beginning to seem likely that the
market was indeed there.
Then, in his December 2, 1996 Network World (p. 34) column Scott Bradner
wrote: speaking of the problems facing those trying to build Internet
backbones or increase the robustness of existing ones, "many . . . are
quite worried about where the bandwidth will come from in the next few
years. The existing fiber plant is becoming exhausted, and new fiber
builds take planning, time and money.
On top of that there may be a problem in getting the fiber itself. The
New York Times reported on November 4 that the worldwide demand for fiber
used in telecommunications will reach 16.25 million miles of fiber this
year, a market worth about $6 billion. But production has been running
behind demand and the shortfall could be more than 1.25 million miles this
year. The demand has been fueled by the global telecommunications
deregulation movement. In addition, the advent of competition from direct
broadcast satellites is forcing US cable TV companies to undertake large
scale infrastructure upgrades."
Finally, in the December 24 issue of the Wall Street Journal Jarred
Sandberg wrote about a new company called Qwest. "Only a few years ago,
many industry watchers believed there was more than enough network
capacity to handle the nation's telephone calls. "Well, that's all changed
with the Internet," said Mr. Grubman [a telecom analyst at Salomon
Brothers Inc.]. A year ago, he noted, telecommunications' capacity
requirements were doubling every 12 months; today they are doubling every
4 months.
Qwest intends to become a "carrier's carrier," leasing its network to
other telecommunications companies. Its new fiber optic artery will be
13,000 miles long, reaching 100 cities nationwide when completed in 1998.
It also will be about 16 times faster than today's most common high-speed
networks."
Other industry sources believe that only the larger scope networks will
see the fiber-bandwidth crunch directly. For example, they say that those
who buy cell-relay services at 10Mbps will not see the same crunch as
those who buy raw SONET. The cell relay networks will simply have their
new 10Mbps PVCs added into an existing service cloud. Since they are
sharing bandwidth on an existing cloud, they will just experience a
greater traffic aggregation level. (However, if they have no service
guarantees in their contracts, they could be in for some unpleasant
surprises since their bandwidth can't be manufactured from nothing.)
Those large networks building with raw SONET require that idle fiber
strands first be located (and in some cases actually re-terminated for
higher speed) and then attached to new SONET drop and insert interface
cards. The actual shortage right now is not so much in fiber strands but
manufacturing backlog on the interface cards and availability of spare
slots in the shelves of existing SONET multiplexer chassis.
Some see the likely short term crunch periods as a result of failure to
anticipate leased line growth. The common practice of avoiding shelf
inventory excesses by IXC carriers and manufacturers also contributes to
the shortage. With 60 day ordering cycles, one can expect any specific
regional crunch to resolve itself within 60 to 90 days.
These crunches are expected to occur in different places and with
different providers randomly over the next year. Therefore, expect to see
more 90 and 120 day lead times as are now being experienced in San
Francisco and in New York. Some claim that these temporary crunches are a
bit artificial because the transmission industry and the manufacturers
could easily stock sufficient chassis and interface cards to meet the well
established upward trend in demand.
When we showed the preceding paragraphs on the additional details of the
problems of fiber infrastructure to Scott Bradner, he had the following
comment: "It is not just planning failure. I think that the shortage will
be felt down the stack in the form of higher costs."
The problem is exacerbated by the fact that no one really knows the amount
of available fiber. The FCC does publish in July, for the year ending the
preceding December, annual fiber deployment reports at
http://www.fcc.gov/Bureaus/Common_Carrier/Reports/FCC
State_Link/infra.html.
The reports cover the telephone industry (IXCs, LECs, and CAPs) but fail
to include utilities and the CATV industry. Furthermore, many local
governments are not 100% sure what fiber has been laid in their
communities and where.
The Backbone Building Rush
Even though it is not at all clear how peering and interconnect
arrangements with the majors will work out, 1996 has been a year of
backbone building for new companies who want to join the majors at the top
of the Internet hierarchy. In the Silicon Valley area CRL and Geonet have
gone T-3 from coast to coast. In Arizona Goodnet and Genuity have done
the same. Genuity is interesting because it has Bechtel, the multi
billion dollar construction firm, behind it and John Postel (the IANA) on
its Board. @Home has completed its backbone. On the East Coast ICONet,
has started from the New York City suburbs and built to the Pacific.
DIGEX, on the strength of an IPO, has done the same from Washington, DC
while from the same area, a Virginia suburban company named Netrail and
backed by a wealthy Atlanta investor is also completing a buildout.
Worldnet Access, in alliance with Brooks Fiber, is yet one more effort -
one which combines a new backbone with a chain of acquired ISPs.
When plans for most of these backbones were initiated at the beginning of
1996, it made sense to build them because the rules were that a new player
could expect to go to three of the five major public exchange at 45
megabits or above and obtain peering with the majors there. In other
words, it seemed that a start-up could, for the expenditure of a few
million dollars, become a Tier One provider with peering partners and no
one who would be both upstream of it and in a position to raise the prices
of its network connections and thus the cost of doing business.
So it was thought. But while these build-outs were taking place,
conditions changed again and the top five providers (MCI, Sprint, BBN,
UUNET, and ANS) began to execute private exchanges and to say that they
would re-evaluate their existing peering agreements. The effort to avoid
being a customer of one of these five and hence subject to price increases
was becoming very expensive and perhaps even impossible to accomplish. As
a result, some may begin to wonder about the comparative economic security
of connecting to one of the newer backbones as opposed to those of the top
five. Why? Because the second tier national providers are at the mercy of
any price increases that might be imposed by the big five. This is a
subject that we shall watch closely in 1997.
Routing, Switching and Quality of Service
In 1997 we will see new router announcements from Cisco. Engineers there,
and in other companies, are working hard to find ways to combine the
benefits of routing and switching since the ISP's dream is to have a box
that can do both. Tag switching, use of precedence bits in the headers of
IP packets, and RSVP are some of the numerous efforts designed to produce
something that the industry is beginning to call Quality of Service (QoS)
for customers who demand real time, or close to real time, performance for
business applications that are strategically important.
Scott Bradner touched on QoS development in a significant way when he
wrote in his December 2, 1996 Network World column: "Undifferentiated
products of this type [best effort delivery] leave little room for ISPs to
compete other than in price. If (or better, when) the network
infrastructure can support multiple levels of quality of service, the ISPs
can start to compete on a basis of quality of data delivery not just cost
or how fast they answer the phone. It also may provide a way for the ISPs
to moderate the growth in their bandwidth requirements enough so that the
production of fiber and the installation of new facilities has a chance to
catch up." (In both this report and our February 1997 newsletter we
explore the quality of service issue in new interviews with Scott Bradner,
Fred Baker, Noel Chiappa and Bob Moskowitz.)
Certainly, technologies for implementing Quality of Service [QoS]
differentials are at the top of many agendas. Some seem to think this may
well provide the Internet with its long sought business model -- one of
being able to sell differentiated levels of service quality. But others
disagree -- saying that such a view can trap the holder into an
unwarranted reliance solely on technology. In their opinion, the
prerequisites of the sound business model are excellent technical
performance, the ability to serve defined markets better than competitors
and distribution channels that would allow penetration into those markets.
For example, in a large corporation, the principal buyer of integrated
Internet services (such as security, network outsourcing, and advanced web
hosting) is not the telecom manager, but the general manager. This is a
very different sale. Companies want integrated results, not one stop
shopping for voice, long distance and Internet. Integrated results mean
providing high-speed access, integration, complex operation, application
development, and transaction services.
End User Quality
Monitoring
Efforts are underway to provide performance monitoring tools to Internet
customers. In 1997 the Automotive Network eXchange will work through its
"overseer" to certify National Service Providers that meet acceptable
level of quality and performance. Merit's Routing Arbiter has survived
its transition. In addition to route servers it has developed an network
outage monitoring system that over 30 large ISPs have agreed to use. At
the San Diego Supercomputer Center a group called NLANR is working on the
development of performance measurement tools. Kim Claffy is working on
forming a another group called CAIDA that will consolidate these tools for
use by end users.
According to http://www.nlanr.net/COLL/caidance.html, RCAIDA (Cooperative
Association for Internet Data Analysis) is a proposed effort to promote
greater industry cooperation in architecting and managing the Internet. It
seeks to address global engineering concerns that are highly dependent on
cross-ISP coordination. This includes efforts to: (1) identify, develop
and deploy measurement tools across the Internet; (2) work with commercial
providers to provide them with a neutral, confidential vehicle for data
sharing and analysis; (3) provide networking researchers and the general
Internet community with current data on Internet traffic flow patterns;
(4) assist in the introduction / deployment of emerging internet
technologies such as multicast, IP v.6, web caching, bandwidth reservation
protocols, etc.; and (5) enhance communications among commercial Internet
service providers and the broader Internet communities.S
Intel, meanwhile has developed a software test suite that it can use to
measure how well a potential ISP can retrieve material from a few thousand
web sites that its employees use. It is possible that this test suite
might be used by other companies as a means of comparing service provider
performance in advance of contract signing. By this time next year we
shall probably see one or more systems for rating ISP performance.
Beginning with our March 1997 issue, we shall cover these end user
oriented evaluative tools very carefully. We shall also follow efforts,
such as CAIDA, that are designed to provide mechanisms for inter provider
cooperation. We shall track the fiber shortage issue closely. Government
may become an additional issue. Currently the FCC looks ISP-friendly.
What may happen with Reid Hunt's departure is another matter. Bruce
Lehman is making much mischief at the Patent Office with his efforts that
seem designed to let content providers rule Cyberspace. These efforts
were also the focus of material recently delivered to a contentious
December 1996 meeting of the World Intellectual Property Organization. In
the meantime it is becoming clear that an Internet with differing service
quality levels does not have to be a broken Internet. Non broken in the
sense that customers paying for different levels of QoS should still be
able to communicate in a seamless fashion.
Conclusion
The Internet seems poised for continued major growth in 1997. The biggest
imponderable that we see is both the question of access to SONET bandwidth
at affordable prices and the ability to obtain interconnects with the top
five on a basis that continues to be economically viable for those without
their size and marketing muscle. On January 6, 1977 an announcement from
MCI that it was beginning to deploy 40 gigabit per second technology on
its network two years ahead of schedule further complicated the current
situation. MCIUs use of Hitachi and Pirelli technology will likely buy
some time in dealing with the bandwidth crunch. But with capacity demand
doubling every four months avoiding problems entirely seems unlikely.
Unfortunately, there are too many indications that prices will be
increasing to permit us to have unrestrained optimism in evaluating the
next stage of the Internet's growth.
January 7, 1997
For the complete contents and other information about the anthology please
see
http://pobox.com/cook/evolving.html
************************************************************************
The COOK Report on Internet For subsc. pricing & more than
431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material
(609) 882-2572 (phone & fax) visit http://pobox.com/cook/
Internet: cook at cookreport.com For NEW study: EVOLVING INTER-
NET ARCHITECTURE, a 222 page Handbook http://pobox.com/cook/evolving.html
************************************************************************
Received: from ietf.org by ietf.org id aa14254; 15 Jan 97 21:09 EST
Received: from cnri by ietf.org id aa13860; 15 Jan 97 20:56 EST
Received: from apnic-ttc.apnic.net by CNRI.Reston.VA.US id aa28382;
15 Jan 97 20:54 EST
Received: by apnic-ttc.apnic.net; id KAA12549; Thu, 16 Jan 1997 10:17:41 +0900
Message-Id: <199701160117.KAA12549 at apnic-ttc.apnic.net>
Received: from unknown(10.0.10.10) by apnic-ttc.apnic.net via smap (g3.0.3)
id xma012547; Thu, 16 Jan 97 10:17:16 +0900
To: Valdis.Kletnieks at vt.edu
cc: naipr at internic.net, IETF <ietf at CNRI.Reston.VA.US>
Subject: Re: Just wondering about the silence
In-reply-to: Your message of "Sun, 12 Jan 1997 01:54:02 EST."
<199701120654.BAA20120 at black-ice.cc.vt.edu>
Date: Wed, 15 Jan 1997 17:28:19 +0000
Sender:ietf-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Source-Info: From (or Sender) name not authenticated.
Valdis,
>Ahh.. Now I start seeing why the rates are so high. You want
>to spend time looking over the network plan and see if they are
>being "optimal" or not.
Want to? Not particularly (at least for me personally). Required to? Yes.
Registries are required to attempt to insure address space is used
efficiently.
>Is a /24 a waste if they're using one SLIP connetion, since it
>"could" fit into a /30?
If the requestor can only document 2 host addresses after 2 years in a /24,
yes.
>Umm.. why do the registries *care*?
Because the registries are supposed to manage the remaining IPv4 address
space until alternative solutions are available. Since most ISPs I have
spoken to aren't particularly excited about IPv6 (since it doesn't solve any
hard problems), the registries are required to attempt to increase overall
utilization and promote efficient usage.
>The owner paid for a /24, give them a /24.
As has been explained in many lists, the registries do NOT sell address
space. The "owner" (who isn't) has paid for allocation/registration
services, not for address space. Yes, I would tend to agree that using
simple economics could have useful implications with respect to conservation,
however there are significant issues that need to be addressed before
charging for address space can be implemented.
>I can accept that in the Pacific Rim, and in Africa, and in parts of
>Europe, the general clue level regarding networking is low enough
>that hand-holding is needed.
Actually, I suspect the clue level of ISPs starting up in all regions
is approximately the same.
>the *registry's* business is to *register*.
While I might agree (and in fact have argued this in the past), I would
simply point out that the organizations which are called regional registries
perform:
- allocation services including
* education both in terms of registry procedures and requirements
as well as more general education in the current state of the
art necessary to follow the registry procedures and meet the
requirements (note: we are *NOT* providing general consulting
services -- we only provide the information necessary to request
resources)
* verification (as much as possible) of claims made on requests
to attempt to insure address space is used efficiently.
- registration services including
* maintenance of database equipment/software
* updating and distributing databases
You may argue that some or all of these functions are inappropriate or
should be performed by another organization if they should be performed at
all (and I might agree), however the state of the system TODAY is as
outlined above. If you feel that system should change, I would encourage
you to propose alternative approaches to pagan at apnic.net (majordomo list:
send a body of subscribe to pagan-request at apnic.net). Until the time a
rough consensus can be reached on what registries are supposed to do and how
it should be done, we're stuck with the current system and that system must
be funded somehow.
Regards,
-drc
Received: from ietf.org by ietf.org id aa15843; 15 Jan 97 22:07 EST
Received: from cnri by ietf.org id aa15628; 15 Jan 97 22:02 EST
Received: from apnic-ttc.apnic.net by CNRI.Reston.VA.US id aa29481;
15 Jan 97 22:02 EST
Received: by apnic-ttc.apnic.net; id LAA12741; Thu, 16 Jan 1997 11:24:11 +0900
Received: from unknown(10.0.10.10) by apnic-ttc.apnic.net via smap (g3.0.3)
id xma012733; Thu, 16 Jan 97 11:23:57 +0900
Received: from ronin.apnic.net (davidc at localhost [127.0.0.1]) by nostromo.jp.apnic.net (8.7.3/8.7.3) with ESMTP id OAA00870; Wed, 15 Jan 1997 14:32:58 GMT
Message-Id: <199701151432.OAA00870 at nostromo.jp.apnic.net>
To: Ron Fitzherbert <ron at penguin.net>
cc: Valdis.Kletnieks at vt.edu, naipr at internic.net,
IETF <ietf at CNRI.Reston.VA.US>
Subject: Re: Just wondering about the silence
In-reply-to: Your message of "Sun, 12 Jan 1997 02:40:17 EST."
<Pine.LNX.3.95.970112023405.9253B-100000 at flying.penguin.net>
Date: Wed, 15 Jan 1997 14:32:57 +0000
Sender:ietf-request at ietf.org
From: "David R. Conrad" <davidc at apnic.net>
Source-Info: From (or Sender) name not authenticated.
Ron,
>"Charging" for address space is just plain SILLY.
Tell that to people who have been happy to fork over US $32,000++ for class
Bs (highest I heard was US $100,000, but of course this is unverifiable).
>Charging for providing
>a service (such as in-addr/whois) could be argued as reasonable -- but
>when we're talking about IP's we're talking about a very small "cost".
Are we? I would recommend you see Geoff Huston's presentation on the price
of address space which he gave at the PIARA BOF in Montreal. Executive
summary: address space is/will be a market in which the seller and the
buyer come to a mutually agreeable price for the resource. That price may
be high or low depending on the relative valuation by both parties -- there
is no absolute cost.
>The only "fair" way (IMHO) to charge for IPs would be if it were on an
>individual IP basis (and let's see how quickly we melt-down if we start
>host-routing all of the IP space!).
Routability would likely be a component of the price. Individual /32s would
presumably have very little value to the buyer since it is unlikely the host
addresses be globally routable, thus the amount offered would probably not be
enough to entice the seller to sell (note: exceptions apply).
In any event, we probably don't want to rehash the PIARA discussions on IETF.
The PIARA list has gone silent of late, but is still honoring subscriptions
(majordomo list, send a body of "subscribe" to piara-request at apnic.net). Also,
please see the PIARA archives at ftp://ftp.apnic.net/mailing-lists/piara/*
Regards,
-drc
P.S. PIARA = Pricing of Internet Addresses and Routing Announcements.
Received: from ietf.org by ietf.org id aa26463; 16 Jan 97 2:39 EST
Received: from cnri by ietf.org id aa26363; 16 Jan 97 2:33 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03580;
16 Jan 97 2:33 EST
Received: from money.autosex.com (autosex.com) by venera.isi.edu (5.65c/5.61+local-26)
id <AA27824>; Wed, 15 Jan 1997 23:31:37 -0800
Received: (from root at localhost) by money.autosex.com (8.6.12/8.6.12) id JAA13384; Mon, 13 Jan 1997 09:34:00 -0600
Date: Mon, 13 Jan 1997 09:34:00 -0600
Message-Id: <199701131534.JAA13384 at money.autosex.com>
Sender:ietf-request at ietf.org
From: Tom Bridges <bridges at autosex.com>
To: ietf at isi.edu
Subject: Earn money from your web site with no work
Source-Info: From (or Sender) name not authenticated.
You've probably seen a lot of form e-mails before. You may want to
read on...this one is a little different.
If you're like me, then you probably have a lot of traffic coming to
your web site every day and you may even be making money with it.
If you'd like to make more money, then you can by setting up a program
with us. We're talking about a profit-sharing plan that works with a
minimum amount of effort from you.
It works like this: you simply copy and paste some HTML code into
your page which provides a working interface between your site and our
site, AutoSex.Com. This code will include a unique identifier which will
allow us to track the number of buyers who come from your site to ours.
Now for the good part- the money. I'm sure you've heard about the
people who will pay you one or two cents per click-through. Wow!
What a payout. Again, our system is a little different...and a little
more lucrative! For each buyer who comes to our site from yours via
the interface on your site, we will pay you $3.00! Think about it.
You would have no bandwidth responsibility and no customers to deal
with. That would all be handled by us. We can afford to do this because
we are quickly becoming one of the largest adult companies on the Internet.
Sound too good to be true? Give us a call at 1-217-356-1349. Ask for me,
Tom. I'll be glad to answer any questions you might have regarding this
exciting new opportunity from DNT Enterprises, Inc.
Tom Bridges
President
DNT Enterprises, Inc.
P.S. We apologize if this letter has inconvenienced you in any way.
Received: from ietf.org by ietf.org id aa02642; 16 Jan 97 9:28 EST
Received: from cnri by ietf.org id aa02247; 16 Jan 97 9:18 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10404;
16 Jan 97 9:17 EST
Received: from orion.lrg.ufsc.br by venera.isi.edu (5.65c/5.61+local-26)
id <AA08097>; Thu, 16 Jan 1997 06:15:48 -0800
Received: (from westphal at localhost) by orion.lrg.ufsc.br (8.6.8.1/8.6.6) id LAA23550; Thu, 16 Jan 1997 11:53:03 -0200
Date: Thu, 16 Jan 1997 11:53:03 -0200
Sender:ietf-request at ietf.org
From: Carlos Becker Westphall <westphal at orion.lrg.ufsc.br>
Message-Id: <199701161353.LAA23550 at orion.lrg.ufsc.br>
To: sarikaya at u-aizu.ac.jp, cellular at dfv.rwth-aachen.de, perform at tay1.dec.com,
tccc at cs.umass.edu, ghafoor at ecn.purdue.edu
Subject: Please distribute widely
Cc: announcements.chi at xerox.com, arl at arl.wustl.edu, atm at bbn.com,
ccrc at dworkin.wustl.edu, cip at bbn.com, cnom at maestro.bellcore.com,
end2end-interest at isi.edu, enternet-ec at bbn.com, enternet at bbn.com,
f-troup at aurora.cis.upenn.edu, ietf at isi.edu, rem-conf at es.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Md5: Vy9AUIPdCSU3/rJ8KFg1JQ==
Source-Info: From (or Sender) name not authenticated.
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.
