On Sat, 19 Jun 2004 23:40:03 -0400
John C Klensin <john-ietf(_at_)jck(_dot_)com> wrote:
Ohta-san,
I do not expect that we will agree on this, and may need to
simply agree to disagree, but, having just reviewed the draft
you included in your slightly earlier not, let me try to explain
the other point of view, and why the I-D to which Vernon refers
is written the way it is and, in the process, I hope, respond to
some of Hadmut's concerns...
The IETF has absolutely not ability to insist that an provider
of IP services, or various good or bad or terrible
approximations to IP servers, do or not do anything.
I agree that the IETF doesn't have the right to tell private, commercial
organisations how to run their business, and what types of services they can
or can't offer customers.
However, I think the IETF are in the position to make statements to the effect
that if "Internet" services are being offered in a manner that doesn't follow
the operational design and architecture of the Internet Protocols, as
outlined in RFC1958, then the end users of those services only have available
to them a limited subset of the features, benefits and capabilities of the
Internet. We are discussing IETF designed and developed protocols, which I
think puts the IETF in a position to state how they _should_ be used.
It also appears that the IAB are willing to make statements discouraging
certain practices, such as port filtering. Such a statement is at the
following URL :
"IAB concerns against permanent deployment of edge-based filtering"
http://www.iab.org/documents/docs/2003-10-18-edge-filters.html
If we were
to establish a document that said, e.g., "you are not an ISP,
and must not call yourself an ISP, unless you conform to the
following rules", I would expect the low-service providers to
simply ignore us. That helps no one.
Instead, I think there are only two courses of action that have
a chance of making progress on this issue. And I think they are
complementary, rather than competing, actions.
First, Hadmut, and others with his concerns in other countries,
probably need to approach the local regulatory authorities who
are concerned about consumer fraud and say "the range of things
that people are selling under the name 'Internet service'
includes too broad a range. People are confused, and suppliers
are insisting that people make long-term commitments to
particular providers with any real idea what they are getting,
and that is poor public policy and you should do something about
it".
Second, the IETF should consider standardizing (or making a BCP
out of) some terminology similar to that in the I-D. The intent
of that document is to lay a foundation for encouraging service
providers to explain what they are offering in language that
people can understand and, if the local/national regulators
think it appropriate, telling service providers what they need
to disclose and in what terms.
Bare in mind that documenting something in an RFC, even if the majority of the
IETF disagree with it, is commonly interpreted as giving it a level of
legitimacy. I've found that a lot of networking people in the enterprise/ISP
world (a) don't read RFCs and (b) consider that something being listed as in
an RFC automatically implies the blessing of the IETF / IESG / IAB.
For example, the original NAT RFC (RFC1631) contains the following
statement :
--
4. Conclusions
NAT may be a good short term solution to the address depletion and
scaling problems. This is because it requires very few changes and
can be installed incrementally. NAT has several negative
characteristics that make it inappropriate as a long term solution,
and may make it inappropriate even as a short term solution. Only
implementation and experimentation will determine its
appropriateness.
--
How many people who bought "RFC 1631" compliant NAT boxes were aware that the
value of the solution documented in RFC1631 was considered questionable by
the authors of the RFC itself? I'd suspect very few. I know I though it was a
good idea for a while, until I got burned by it.
Whether we like it or not, there are users (of what those users
think of as "the Internet") who would be perfectly happy with a
web-only, all outbound protocols but HTTP and HTTPS blocked, all
inbound ports blocked except responses to the above, private
address space, and all connections dropped and a new address
assigned every half-hour "service"... as long as it is cheap
enough.
I think these innocent and naive users are really being done a disservice.
The Internet is and will be far more capable that just these services - the
current architecture ensures that. I think it is important that the more
knowledgable attempt to ensure that the innocent are not taken advantage of,
nor denied access to the full capabilities that the Internet achitecture
provides.
Regards,
Mark.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf