Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: Masataka Ohta <[email-masked]>
Date: Mon, 10 Jul 2000 10:06:29 +0859 ()

Dear all;

Based on the previous discussion,

Jon> In message <[email-masked]>, Masataka Ohta ty
Jon> ped:
Jon>  
Jon>  >>	Is it fair if providers using iMODE or WAP are advertised
Jon>  >>	to be ISPs?
Jon>  >>
Jon>  >>	Is it fair if providers using NAT are advertised to be ISPs?
Jon>  >>
Jon>  >>My answer to both questions is
Jon>  >>
Jon>  >>	No, while they may be Internet Service Access Providers and
Jon>  >>	NAT users may be IP Service Providers, they don't provide
Jon>  >>	Internet service and are no ISPs.
Jon> 
Jon> i agree:
Jon> in the UK, i would say that someone claiming internet access via WAP
Jon> would be in breach of the trades description act.
Jon> 
Jon>  >>Any oppositions?
Jon>  
Jon> not from here (for wap - i dont know enough about iMODE to comment)

and lack of oppsitions in the thread, I have drafted an attached ID.

However, IESG is blocking the publication of the ID (it is just an
Internet Draft, NOT an Informational RFC)!

IESG says they have not even saw the content, which means a lot of
time will be wasted further.

So, I post the draft to the Mailing List.

Any comments on the content of the draft? Comments for the blockage,
if any, should be given with a separate subject?

I hope IESG has not taken the obvious next step of the moderation
of the Mailing List.

							Masataka Ohta
---

INTERNET DRAFT                                                   M. Ohta
draft-ohta-isps-00.txt                     Tokyo Institute of Technology
                                                               July 2000

                         The Internet and ISPs

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (May/1/2000).  All Rights
   Reserved.

Abstract

   This memo gives definitions on the Internet and ISPs (Internet
   Service Providers).

1. The Internet

   The Internet is a public IP [1, 2] network globally connected end to
   end [3] at the Internetworking layer.

2. ISPs

   A network provider is an ISP, if and only if its network, including
   access parts of the network to its subscribers, is a part of the
   Internet.

   As such, ISPs must preserve the end to end and globally connected
   principles of the Internet at the Internetworking layer.

M. Ohta                Expires on January 1, 2001               [Page 1]

INTERNET DRAFT                    ISPs                         July 2000

   A network provider of a private IP or non-IP network, which is
   connected to the Internet through an application and/or transport
   gateway is not an ISP.

   Dispit the requirement of "global connectivity", a network provider
   may use transparent firewalls to the Internet with no translation to
   filter out a limited number of problematic well known ports of TCP
   and/or UDP and can still be an ISP.  However, if filtering out is a
   default and only a limited number of protocols are allowed to pass
   the firewalls (which means snooping of transport/application layer
   protocols), it can not be regarded as full connectivity to the
   Internet and the provider is not an ISP.

3. Security Considerations

   While some people may think that filtering by application/transport
   gateways offer some sort of security, they should recognize that
   macro virus in e-mails can pass and are passing through all such
   gateways.

4. References

   [1] J. Postel, "Internet Protocol", RFC791, September 1981.

   [2] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
   Specification", RFC2460, December 1998.

   [3] B. Carpenter, "Architectural Principles of the Internet",
   RFC1958, June 1996.

5. Author's Address

   Masataka Ohta
   Computer Center, Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3415
   EMail: [email-masked]

M. Ohta                Expires on January 1, 2001               [Page 2]

INTERNET DRAFT                    ISPs                         July 2000

6. Full Copyright Statement

   "Copyright (C) The Internet Society (July/1/2000).  All Rights
   Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

M. Ohta                Expires on January 1, 2001               [Page 3]

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Jul 2000 08:27:37 +0100

>>Any comments on the content of the draft? 

I would go further - first to define by exclusion, secondly to define
a new class of providers (according tro common uisage) so that
discussion can proceed 

An ISP _hosts_ its own and customer's hosts.  Hosts follow the 
hosts requirements RFC, at least.

An ISP uses routers to interconnect its, its customers, and other to ISPs
networks, Routers follow the router requirements RFC, at least.

Service Organisations that don't allow a host or router that follows the above
definition to excercise capabilities defined are what we now know as
Content Service Providers, and must provide application level gateways, 
Application Service Providers, and offer portals or ALGs. In each case there
may be good performance or security reasons for this mode of service, but
there will usually be lack of flexibility or ease of introdution to new
services, content and applications in general. 

personal comment
Other classes of organisation may simply be providing a subset of
internet services - I don't see a market or technical case for these
and in fact would encourage regulatory bodies to see if these types of
organisations are trying to achieve lock out or are engaged in 
other types of monopolistic or anti-competitive behaviour. :-)

cheers
j.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 10 Jul 2000 17:36:05 +0859 ()

Jon;

> a new class of providers (according tro common uisage) so that

My intention is to provide a semi permanent definition as an Informational
RFC.

It is important to make the definition protected by bogus opinions
of various bodies including IETF.

> networks, Routers follow the router requirements RFC, at least.

They are requirements by IETF.

Worse, even in IETF, there is no Internet Standard of router requirements
yet and the newest revision to the Proposed Standard is BCP.

So, please don't attempt to rely on it.

> services, content and applications in general. 

I think my draft covers the case to make such network providers
not ISPs.

> other types of monopolistic or anti-competitive behaviour. :-)

I just want to make it illegal for these types of organisations call
their service "Internet" or "internet".

It's something like "Olympic".

							Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jul 2000 06:35:47 -0700

> of various bodies including IETF.

of course you will exuse the providers if we continue to be perverse and
find new business models.

randy

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Jul 2000 21:43:13 -0400

> find new business models.

not bloody likely.  some things are inexcusable.  munging data in
transit is one of them.  the fact that you may have a business
model that says you can make money doing something that is inexcusable
is not a justification for doing that thing.

I'm sick and tired of folks justifing all manner of brain damage
merely because they think they can make money at it.  you'd think
that they believe that the only purpose in life is to make money.

Keith

p.s. sorry to single you out, there are far worse culprits.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Jul 2000 20:13:19 -0700

>is not a justification for doing that thing.

I don't see any problems people making money on weird 
NAT-munging-weirdo-webonly-wap things which they sell to customers, 
BUT, it is NOT Internet access.

I would not buy it, because I want Internet access.

What I oppose strongly, is that people sell weird stuff and call it Internet.

   paf

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jul 2000 19:26:04 -0700

> p.s. sorry to single you out, there are far worse culprits.

have you tried valerian root tea?

---

From: "mark.paton" <[email-masked]>
Date: Tue, 11 Jul 2000 08:12:37 +0100

I thought the real purpose of life was too make
money!!

Joking aside, I agree with Keith Moore, some
things are totally unacceptable and this falls
into that category.  Data integrity should be of
the utmost importance in any network.  The
InterNet is no exception.

Regards

Mark Paton CEO/DIR. Internet Network Eng
Mercury Network Systems Limited
+44 585 649051
+44 1256 761925
http://www.mnsl.org

"Mercury Network Systems - The Unstoppable Force"

This e-mail is intended only for the addressee
named above. As this e-mail may contain
confidential or privileged information if you are
not, or suspect that you are not, the named
addressee or the person responsible for delivering
the message to the named addressee, please
telephone us immediately. Please note that we
cannot guarantee that this message or any
attachment is virus free or has not been
intercepted and amended.

The views of the author may not necessarily
reflect those of the Company.

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: 11 July 2000 03:26
To: Keith Moore
Cc: Masataka Ohta; Jon Crowcroft; [email-masked]
Subject: Re:
draft-ietf-nat-protocol-complications-02.txt

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jul 2000 03:17:47 -0400

> What I oppose strongly, is that people sell weird stuff and call it Internet.

I've never seen a marketing person that wouldn't lie and do exactly that.
If folks want to buy wierd stuff, and they know it's wierd stuff and
are aware of its limitations, I don't have much problem with that.
But I've yet to see a NAT product that was advertised honestly.

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Jul 2000 07:27:40 -0700

> Joking aside, I agree with Keith Moore, some things are totally
> unacceptable and this falls into that category.

so we try to stay somewhere within the solar system, let's review what
"this" is.  it was a discussion with masataka and jon about defining classes
of providers.

    From: Randy Bush <[email-masked]>
    To: Masataka Ohta <[email-masked]>
    Cc: Jon Crowcroft <[email-masked]>, [email-masked]
    Subject: Re: draft-ietf-nat-protocol-complications-02.txt
    Date: Mon, 10 Jul 2000 06:35:47 -0700

    > My intention is to provide a semi permanent definition as an
    > Informational RFC.
    >

masataka was saying that he could classify providers given a rather fixed
model.  i was saying that the world changes and that providers will find
new business models and bend masataka's rigid classification.

and then keith came out of left field without bothering to actually read
the thread and went off on his usual jihad against whatever perfidy drives
him to wild accusations and libel this week, usually nats, proxies, and
whatever.  booooring.

but yes, likely some things in this world are not acceptable to some
segment of the population.  so don't accept them.  but life goes on and
things change.

randy

---

From: [email-masked]
Date: Tue, 11 Jul 2000 04:21:38 -0700

>I don't see any problems people making money 
>on weird NAT-munging-weirdo-webonly-wap things 
>which they sell to customers

"Making money" implies that for every seller
there is a willing buyer. For NAT to have
progressed from a twinkle-in-the-eye to the
near ubiquity that it will have in a few
years, there need to be a *lot* of willing
buyers. The marketplace rewards those who
satisfy a perceived need. 

If we would prefer that those customers
choose another solution (IPv6), then we
will need to make it every bit as easy 
to install and use as the alternative. 

However, even that may not be enough --
because history tells us that displacing
a deeply entrenched competitor (IPv4 + NAT) 
can generally only be accomplished by 
exploiting points of inflection. Perhaps 
Wireless and Infiniband will provide 
the required inflection points; we will see.

>BUT, it is NOT Internet access.

I'm not sure that in practice this is a
distinction that will ever be universally
understood in the marketplace. AOL isn't
Internet access either, but it serves
more than 25 million users. As with
NAT, AOL thrives because it fills a
perceived need better than the alternative.

>I would not buy it, because I want Internet access.

Perhaps it is more instructive to turn the tables
and complete the sentence:

"I would prefer {insert abomination here} to Internet
Access because {insert reason for preferring 
abomination}"

Then, try to complete an alternative sentence:

"I would prefer IPv6 to {insert abomination here} because
in addition to providing {insert reason for preferring
abomination} it can also enable my business to grow
faster in ways that IPv4 and {insert abomination here} 
cannot provide: {insert tangible business benefits of 
IPv6 here}"

The goal is to repeat the exercise until the above 
sentence convinces large numbers of customers 
(who may not know what Internet Access is) to part
with their money.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Jul 2000 15:14:34 -0400

> new business models and bend masataka's rigid classification.

yes, but the desire to have classification of providers is significantly 
motiviated by providers that keep coming up with "business models" that 
involve deliberately corrupting the data that they carry.

of course such providers would rather act as if they weren't doing anything
harmful...  which only further illustrates the need to have such 
classifications.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 12 Jul 2000 08:12:20 +0859 ()

Randy;

> find new business models.

Exuse? If you mean execution or decapitalization, yes, I will.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 13 Jul 2000 07:33:16 +0859 ()

Aboba;

> to install and use as the alternative. 

See draft-ohta-address-allocation-00.txt on how to commercially motivate
ISPs (and private IP network providers with NAT, too) deploy IPv6 service.

It also makes NAT unnecessary.

> perceived need better than the alternative.

If IETF makes it clear that AOL is not an ISP, it will commercially
motivate AOL to be an ISP.

						Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jul 2000 22:39:01 -0400

> motivate AOL to be an ISP.

probably not.  folks who subscribe to AOL aren't likely to be 
reading IETF documents.

face it, it's not the superior quality of AOL's service that keeps 
AOLers from moving - it's their susceptibility to marketing BS and
their addiction to chat rooms.  it's hard to help those people.

Keith

---

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 13 Jul 2000 10:30:55 -0400

> From: Masataka Ohta [mailto:[email-masked]]
> 
> 

Oh really - it is that simple! 
Guess who is better known in masses - IETF or AOL :-).

Cheers,

--brijesh
Ennovate Networks Inc.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Jul 2000 08:54:54 +0859 ()

Keith;

> probably not.  folks who subscribe to AOL aren't likely to be 

AOL will be motivated but, considering other factors, may not
change the current practice.

That's fine.

> their addiction to chat rooms.  it's hard to help those people.

I'm no user of AOL that I don't have to face it.

It is arrogance of you if you think you must help AOL users.

Just make the IETF definition of "ISP" clear and let ISP competitors
of AOL give reasons to say "AOL is not ISP".

							Masataka Ohta

---

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Wed, 19 Jul 2000 22:58:55 -0400

g'day,

Masataka Ohta wrote:
.  .  .
> motivate AOL to be an ISP.

Not to be unkind, since the IETF has done some good work, but the above
statement is incorrect. If you'd written "If AOL perceives that the
market would punish them if the IETF makes it clear that AOL is not an
ISP, it will commercially motivate AOL to be an ISP" you might be closer
to the mark. 

The bottom line is, the world isn't waiting for us to tell them the
right way to do what they want and the clever solutions we came up with
as solutions to the networking problems of 1970, or 1980, or 1990 don't
demand that they adopt our proposals for solving their problems of 2000.
We're in serious danger of surrendering to the same elitist posturing
for which we used to vilify the mainframe community. Pity, but we'll
have only ourselves to blame if and when the users pass us by...

				- peterd (feeling testy this evening)

-- 
--------------------------------------------------------------------------------
Peter Deutsch                               work email: 
[email-masked]
Engineerng Manager
Caching & Content Routing
Content Services Business Unit                 private:
[email-masked]
Cisco Systems

  "I want to die quietly and peacefully in my sleep like my granfather,
             not screaming in terror like his passengers..."

                                             - Emo Phillips
--------------------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Jul 2000 08:52:49 -0400

> have only ourselves to blame if and when the users pass us by...

not that I disagree with you, but this is a fairly content-free statement.
yes, we are seriously deluded if we think that the industry will do 
whatever we say just because we are IETF.  but a similar statement 
could be made of any organization that had been around awhile -
including, for instance, (but by no means specifically) your employer,
a few other large gorillas, telephants, other standards bodies, etc.  
in a free market, *anyone* is in danger of becoming irrelevant.

the reason I say that your statement is content-free is that it offers
no specific criticism of IETF that can be used in a constructive fashion.

I find that the work of IETF varies in quality - much of it is quite
good, some of it mediocre, a small fraction is highly dubious.
Most IETF WGs I've worked with do not operate with an attitude like
"people will have to do what we say", but rather "how do we solve
this problem".  Most of them seem to understand that they have not
only to solve the problem, but also to make the solution technically
sound, attractive to those who would use it, and easy to deploy.

So while I'm not familiar with every area of IETF, I don't see that
IETF as a whole is suffering from the problem you describe.  If
there are specific areas or groups you think are suffering from this
problem, you would do better to direct your criticism to those
areas or groups, to defend your argument with specific examples,
and to provide constructive suggestions for improvement.

Keith