> > I am writing to request that the RFC Editor not publish
> > draft-cerpa-necp-02.txt as an RFC in its current form,
> > for the following reasons:
>
> > 2. A primary purpose of the NECP protocol appears to be to
> > facilitate the operation of so-called interception proxies. Such
> > proxies violate the Internet Protocol in several ways:
>
> > 3. Aside from the technical implications of intercepting traffic,
> > redirecting it to unintended destinations, or forging traffic from
> > someone else's IP address - there are also legal, social, moral and
> > commercial implications of doing so.
>
> You will need to be far more specific here. I see absolutely nothing that
> is not legal, is not social, or is not moral.
Okay, I'll offer a few specific examples, by no means the only ones:
1. an Internet service provider which deliberately intercepts traffic
(say, an IP packet) which was intended for one address or service,
and delivers it to another address or service (say that of an interception
proxy) may be misrepresenting the service it provides (it's not really
providing IP datagram delivery service because IP doesn't work this way).
2. an internet service provider which deliberately forges IP datagrams
using the source address of a content provider, to make it appear
that the traffic was originated by that content provider
(interception proxies do this), may be misrepresenting that content
provider by implicitly claiming that the service conveyed to the user
by the ISP is the one provided by the content provider.
3. an internet service provider which deliberately alters IP traffic
in transit, and deliberately makes it appear that the traffic was not
altered (by recomputing the checksum) may be misrepresenting the
service it provides (because IP doesn't work that way) and it may
also be violating the traffic orignator's right to make derivative
works of its copyrighted material. (in particular an interception
proxy that modified the content in transit - say to convert one
data format to another - might be held to violate that right because
content conversions almost always degrade the content and thereby
degrade the expression)
now whether any of these is actually illegal would be up to a court
to decide, and different courts in different jurisdictions might rule
differently (especially depending on the particulars of a test case)
but each of these is similar to behavior that in other communications
domains would be illegal. and regardless of whether the grounds is
technical, legal, or moral, none of these behaviors seems like
something that IETF should support.
> I do see commercial
> implications, but whether those are is "good" or "bad" is not a technical
> judgement.
I agree that we are safest when we can rely purely on technical arguments,
and I believe that all of the above practices are in general technically
unsound. Still, I don't think there is a definite boundary between
technical judgement and moral judgement. Technical judgements are
often based on moral sensibilities.
> > In my opinion IETF should not be lending support to such dubious
> > practices by publishing an RFC which implicitly endorses them, even
> > though the authors are employed by major research institutions and
> > hardware vendors.
>
> I take the contrary position. The IETF ought to be encouraging the
> documentation of *all* practices on the net. It is far better that they
> are documented where people can find useful information when they see this
> kind of packet activity rather than have them known only to a few
> cognescenti.
Actually I share the belief that it is a good thing to document any
widespread practice, or any idea which is believed to be useful.
However it's also clear that publication of all such pratices in RFCs
is beyond IETF's meager resources, and would dilute the value of
the RFC document collection. And the reality is that a protocol
documented in an RFC is often treated as if it were a standard, or
at least, as if the practice were endorsed by IETF. When a poor
protocol is apparently endorsed in this way it does harm to IETF's
reputation and to its work of promoting interoperability.
> May I suggest that one treat this in its classical sense - as a Request
> for Comments and that those who have technical objections or technical
> enhancements publish those comments in an additional document rather than
> try to suppress the original one.
RFCs have not been treated in this sense for many years. And while
such treatment may have made sense in the early days of the ARPAnet
with a community of a few hundred users, it does not make sense in
an Internet with tens of millions of users.
The reality is that today, many documents submitted for RFCs are rejected.
I'm simply arguing that this document should be added to that set.
or at least, that it needs substantial revision before it is found
acceptable.
> Having a document trail that shows what paths and ideas have been found
> wanting is nearly as important has having a trail that show what paths
> have been found useful.
agreed, but that doesn't mean that it's IETF's or the RFC Editor's job
to organize and maintain the definitive collection of such documents.
Keith
