Re: recommendation against publication of draft-cerpa-necp-02.txt

[Peter Deutsch in Mountain View]

g'day,

Keith Moore wrote:
> .  .  . I did not call for a ban on publication of any document.  I
suggested
> that the RFC Editor consider not devoting its energies to publishing
> the document - and I only suggested this after I suggested several
> things that could be done to "fix" the document.  Clearly the document

> can be published by other means, nor would I try to prevent such
publication.


Okay, I'll be a little more pedantic - you called for a ban on
publishing this document within the IETF. If it makes you feel better,
load up my previous post in vi and:

     s/document/document within the IETF/

I still object to your notion that it's not censorship since people can
always go elsewhere. Where does this lead? I see the day when people
can't publish a new  directory service protocol because "The IETF has
endorsed LDAP for directory services", or would ban the publication of
an extension to DNS because "it must prevent the misuse of the protocol
in creating inappropriate services". One by one, you'd be chasing
innovation to other foums.

"Danger, Will Robinson! Danger!"


.  .  .
> (Such waste of resources is especially annoying when the motivation
for
> having the document published appears to be lend IETF's imprimatur
> to an approach by having it published as an RFC - and therefore,
> can be cited as if it were a standard - language in the RFC preamble2
> to the contrary notwithstanding.


Hmmm I've read through the Draft again and I can't see the paragraph
which says that the motivation for publishing it is to lend the IETF's
imprimatur to the approach; I must have missed it. Or perhaps you have
first-hand knowledge of the motivations of the authors that you'd care
to share with us?

In any event, without attempting to speak for the authors, most of whom
work for competitors and all of whom I assume are quite capable of
speaking for themselves, I would add that since joining Cisco I've
already heard several conversations of the form "well, the IETF  isn't
the place to take this kind of work anymore. We'll probably develop it
outside and then just work with the industry to standardize it, and look
at whether it's worth taking to the IETF later if the climate changes".

Note, nobody talks in terms of getting something "blessed by the IETF",
but in terms of how the IETF would slow the work down and get in the way
so shouldn't be a part of the process.

If you can't see the long term danger for the IETF in such an attitude
taking root, then you're missing the entire point of my argument. You
can block dissemination of ideas you disagree with and cast aspersions
upon the motivations of participants if you must, but I feel obligated
to point out that I for one think you have crossed a line here and are
harming the IETF. Remember, the net regards censorship as failure and
routes around it....


> > So write an RFC Draft and call it "IP Address Spoofing Considered
> > Harmful". Argue eloquently. Convince everyone and you will be famous

> > to generations of students to come as the person who saved us from
> > this pernicious practice, right up there with Djkstra and GOTOs.
> > Fight ideas with ideas. But banning mention of the technique because

> > it can be misused? Puuleeze.
>
> again, you're using "ban" incorrectly.

Again, I assumed it was obvious that I was speaking within the IETF
context. So please apply:

      s/technique/technique within the IETF/

.  .  .
> I do take a hostile attitude toward so-called innovations which impair

> the flexibility and reliability of the Internet and Internet
applications,
> and I make no apology for it.

When we started running Archie it quickly filled the pipe to our
university (50 percent of all traffic to Montreal at one point was going
to the Archie machine). By your argument we should have shut it down and
banned discussion about automated data gathering and distributed search
engines as clearly we were impairing the "flexibilty and reliability of
the Internet".

Instead, we were prompted to develop new techniques to make good the
problems that the innovation was causing. We worked with other sites to
set up mirror servers, we developed data flooding algorithms, etc. Today
such techniques are regarded as important parts of the infrastructure
and more importantly the innovation showed the way to whole new classes
of Internet use. I'm not trying to beat our drum here, but point out
that I heard many of your arguments back then from conservative
Computing Centre types who felt we were dangerous and yes, evil. Hearing
it all again now from a former IETF Area Director is pretty sad.

In the climate you seem to want to create, we probably would never have
gone to the IETF to meet collaborators or used it as an exchange point
for ideas. We used to say that the most important part of the meetings
were the corridor talks and beer BOFs but you'd ensure that, in
reviewing the drafts and RFCs before a meeting today, many Internet
innovators are not going to see anyone working on technologies relevant
to them. I wonder how many people say nowadays "oh, it's just not worth
while going this time..."?

.  .  .
> > We need to build publishing and distribution services that can scale

> > to millions, if not billions, of users, and we need them now.
> > Address interception is a perfectly legitimate technique in our
> > arsenal of ideas for this task, with some dangers.
>
> I will agree that legitimate uses of the technique exist, but given
> the widespred misuse of this technique (there seems to be a great
> deal more misuse than appropriate use) "perfectly legitimate"
> seems like an oversimplificatiaon.

I fail to see the delicate degrees of shading that you draw between
"legitimate" and "perfectly legitimate". Or do you merely want a chance
to accuse me of oversimplification?

Given how much **I* see of legitimate uses of the technique in
commercial settings, I'd suggest that you're horizons are pretty
limited. Maybe you need to get out a bit more. (note, I'm not talking
about the specific protocol in the Draft in question, but the general
technique of IP address interception - TWIAVBP)


> > > > Bottom line is, you seem pretty confused here.
> > >
> > > only if you think that discussing several related topics in a
single
> > > mail message is a sign of confusion.
> >
> > Sorry, you're not convincing me you understand my point. You
> > acknowledge that it's okay to intercept if CNN knows you're doing
> > it.
>
> not quite. I said "if it's okay with CNN".  Knowledge != explicit
consent.

<sigh>

Okay,
            s/knows/gives its explicit consent/


Is this what you did all day as an Area Director? No wonder you claim
you didn't have any time...


> > So why don't we document how to do that? Oh, you say - that's
> > because the idea can be misused. "Let these dangerous kooks publish
> > their innovations elsewhere, so we don't sully the IETF brand".
> > Fine, if we do that, I guarantee that new ideas will simply migrate
> > out of this forum. Be careful what you ask for, as you're liable to
> > get it...
>
> sometimes it's useful if new ideas migrate elsewhere. in certain
> circles this is known as the Golgafrinchian Ark B principle.

Well, look at the list of signatories to the Draft in question. I see
people working for a major research university, and a roster of
significant players in the content services networking industry. Throw
in my own employer (because although as far as I know we don't use the
technology in question, we do use the technique of address interception
in such technologies as WCCP) and you've got an entire industry you'd
like to rule "out of scope" for the IETF. Yeeesh. Wouldn't it be easier
if you just write an RFC letting us all know what is actually considered
suitable family entertainment for this organization? Then the rest of us
could stop wasting your valuable time with undesireable experimentation
and possibly fruitless innovation.


> > Publishing of a technical document is not promoting "illegal or
> > clearly immoral behaviour", any more than publishing instructions on

> > driving a car is promoting carjacking.
>
> I would argue that publication of this document, regardless of the
> *intent* in doing so, is likely to have the *effect* of promoting
> illegal and/or immoral behavior.  If the decision is made to publish
> the document in some form, the question becomes one of how to minimize

> this negative effect.

Other than responding with a Draft of your own, what would you propose?
A letter-writing campaign to Congress? A Department of Commerce ban on
IP address interception, a la the crypto ban? I'm fascinated to see what
you'll come up with next...

.  .  .
> > Frankly *I'm* morally offended at that
> > notion as I think it strikes at the very heart of the IETF and what
> > made it a successfully organization worthy of my support. If this
> > were to become the way this organization actually does work in the
> > future, I would predict its speedy demise as a useful place for the
> > free interchange of ideas.
>
> Get over it.  The RFC has been exercising editorial discretion - or if

> you prefer - rejecting ideas for RFCs, for many years now.

Yes, and those of us who object to this degradation of the original
concept of the IETF probably have some obligation to engage and at least
point out their concern over this trend. So here I am, wasting my
Saturday when I should be doing other things trying to protect an
organization I admire from what I see as a very dangerous trend indeed.

I'd add that your obsessive concern over the purity of the "IETF brand"
actually contributes to the very phenomenon you're citing - by
preventing any but fully formed and suitably blessed publications, you
allow the Marketers to use the annoiting power of an RFC number, since
the IETF itself is guaranteeing the purity of its "product". You've also
increased your own workload to the point where you can use the lack of
time as a justification for chasing away ideas which are not fully
formed and judged to be safe enough to pursue a priori. I see an
interesting feedback loop forming here.

And the real killer is that you're more concerned about what Marketing
types will do with the document than what technologists will do with it.
Wow...

Frankly, I hope we are going to be able to arrest this dangerous trend.
So, I engaged last year when I saw the broadcast industry being run out
of town over the TV: URL draft, and I'm engaging now because I see the
content services networking industry being told they can't play in this
sand box with their dangerous notions of abstracting service requests
from transport.

To me the appropriate reponse when someone sees danger in a technology
is another document, making your case. After all, if the technique is so
dangerous, it's not enough to surpress it at the IETF. We need to hear
why it shouldn't be out there are all. Those of us in positions of
influence could then do something about it. Right now you've certainly
not convinced *me* there should be a ban on such work...

And if we fail to arrest this trend towards self-censorship, at least
we'll have addressed the workload issue for overworked Area Directors,
as all the major inovations and initiatives will have been driven to
outside consortia and the IETF will be able to point out that it had
nothing to do with bringing them to life or addressing their
short-comings. Sounds like a pretty bleak future to me, but as my
daughter would say, "hey, whatever..."


> > . . . I'm offended at
> > the notion that a former Area Director of the IETF would advocate
> > censoring what others can publish in the Internet's premier
> > technical exchange forum based not on the quality of the technical
> > information, but on how that information may be misused.
>
> as far as I can tell, you think that my having served on the IESG
> means that I have given up the right to speak out against dangerous
> and harmful practices and against poor uses of the IESG's and RFC
> Editor's energies.
>
> IMHO, that's not merely naive, that's delusional.

First you would ban technical information because it can be misued
(rather than documenting such misuse to help avoid it). Now you add
name-calling and intimidation to your arsenal. Way to go, Keith.

I think I might go to POISED and propose that we limit name-calling on
IETF lists to within the bounds of quoting appropriate snippets of Monty
Python. You'd be free to publish elsewhere, so it's not censorship, and
we'd be sure not to sully the IETF's reputation for quality of
discourse. At the same time, I'm going to propose that the RFC Editor be
told to insert at the front of each new RFC the words "nil obstatum" (or
whatever the Latin term is), to make clear the role the IETF sees itself
playing here. That should ensure the health and relevance of this
organization for years to come...

(and would a classicist in the crowd who recognizes this rather obscure
reference please give me the actual words, since I expect a flood of
flames and corrections to my egregous misuse of the Latin?
AD-thanks-VANCE...)


                                                                  -
peterd

----------------------------------------------------------------------
Peter Deutsch                     work email:  [EMAIL PROTECTED]
Technical Leader
Content Services Business Unit       private:
[EMAIL PROTECTED]
Cisco Systems                           or  :  [EMAIL PROTECTED]

         Alcohol and calculus don't mix. Never drink and derive.
----------------------------------------------------------------------