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

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Fri, 07 Apr 2000 23:41:30 -0400

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-masked]
Technical Leader
Content Services Business Unit       private:
[email-masked]
Cisco Systems                           or  :  [email-masked]

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Apr 2000 15:28:12 -0400

Peter,

I think that by now I've made my points and defended them adequately and 
that there is little more to be acheived by continuing a public,
and largely personal, point-by-point argument.  If you want to continue 
this in private mail I'll consider it.

The simple fact is that I believe that the idea of interception proxies 
does not have sufficient technical merit to be published by IETF, and 
that IETF's publication of a document that tends to promote the use 
of such devices would actually be harmful to Internet operation and 
its ability to support applications.  Reasonable people can disagree
about the utility of an idea and I certainly don't expect that my 
notion of the utility of interception proxies will be accepted by everyone.
(especially not folks who are making money by selling these things...)
But I thought it was valuable to try to raise awareness about the issue.

Keith

p.s. I think the term you're looking for is "nihil obstat".

---

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Sat, 08 Apr 2000 01:00:29 -0400

g'day,

> this in private mail I'll consider it.

Okay, but I'd like to make clear that I don't regard this as a "largely
personal...argument". On the contrary, I've drunk beer with you, I like you as
a person and would be happy to drink beer with you again. I am engaging here
*only* because I think the principles I'm defending are so important. It really
is nothing personal.

> its ability to support applications.

Fair enough, but my primary goal was not to justify this particular technique,
but to address the issue of whether we should be preventing the publication of
particular techniques, and under what ground rules. The industry and their
customers have already decided against you on this one. I'm wondering about the
future of an IETF that consistently takes itself out of play in this way. I'm
sure there are other techniques on their way that are going to allow us to find
out...

> p.s. I think the term you're looking for is "nihil obstat".

Yup, that's it. Thanks...

                                                                          -
peterd

---

From: [email-masked]
Date: Sat, 08 Apr 2000 15:59:57 -0400

> its ability to support applications.  Reasonable people can disagree

Keith:  I think that there's been sufficient commentary here that
interception proxies *do* have a place, both at the "server" end (for
load-balancing server, etc), and at the "client" end.  However, I am
fully in agreement that interception proxies imposed anyplace other
than either endpoint of the connection is a Bad Idea, because a third
party can't be sure of the connection.  I'm willing to do something at
my end, because I know that I wanted to connect to foobar.sprocket.com,
and what semantics that involves.  foobar.sprocket.com can make
decisions, based on its knowledge that any packet on port 7952 is
either for their monkey-widget server, or invalid.  But my transit
providers don't have any basis for making such decisions.

I'd have to vote against progressing it without language making this
distinction as clear as possible.

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Doug Royer <[email-masked]>
Date: Sat, 08 Apr 2000 12:10:53 -0700

Peter Deutsch in Mountain View wrote:
[in part you said]

> "Danger, Will Robinson! Danger!"

The above information is nonsense.

You seem to be objecting to Keith's right to object to the draft
as it is written. So using your logic (As I understand what you
are saying above) - you are also guilty of censorship by not
wanting Keith to object.

I understand you frustration as many of us in the IETF have
been frustrated from time to time. If you want to convince
me and others then please ignore anything you feel is a non-technical
issue. And address the technical issues.

Many in the IETF *are* swayed by technical content.

I am undecided on this issue and I am personally glad to see this
debate. I do find it an important discussion when it remains
technical. 

Questions I have:

Does this solve a problem that is not already solved by another method?
Not that it has to be unique as you point out above, but if you could
compare it against other known solutions (if any) then perhaps its
advantages (that I have not seen yet) could help you cause?

If this were not done - what could you not do?
I have worked for large corporations and I have worked on large to huge
scaleability problems. Why do I want this?

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Sat, 08 Apr 2000 13:45:02 -0700

>that IETF's publication of a document that tends to promote the use

Publication under Informational and Experimental has typically been open to 
all wishing it.  It is deemed an essential public service to afford that 
publication channel to anyone feeling that the Internet Community needs 
access to an archival copy of an Internet-related document, proprietary or 
otherwise.

The "IETF" imprimatur applies only to Proposed, Draft, Standard and BCP 
RFCs.  At most, the IETF has typically seen fit only to attach its own 
disclaimer text to other drafts about which it has concerns.

Concern for public misunderstanding of "RFC" vs. "IETF standard" is very 
long-standing and unresolved.  To date, this concern has not been used as a 
reason for entirely refusing publication.  (Making sure that there is no 
misleading text in the document and that the document has an appropriate 
title are different matters.)

Now, if the authors of the draft in question are seeking standardization, 
then the matter of acceptable technical merit is appropriate.  However I 
don't recall seeing a Last Call from the IESG.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Apr 2000 17:00:17 -0400

> particular techniques, and under what ground rules

As I see it, the issue is only one of where to have the debate - at
the RFC publication level or on IETF mailing lists.  

> The industry and their customers have already decided against you on 
> this one. 

Industry people love to make such claims.  They're just marketing BS.  
The Internet isn't in final form yet and I don't expect it to stabilize 
for at least another decade.  There's still lots of time for people to 
correct brain damage.

> I'm wondering about the future of an IETF that consistently takes itself 
> out of play in this way. 

IETF's job is to promote technical sanity, not to support unsound vendor 
practices.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Apr 2000 17:06:54 -0400

> Publication under Informational and Experimental has typically been 
> open to all wishing it.  

uh, no.   this is a common myth, but it's not true, and hasn't been
true for many years.

I hope (and believe) that the *potential* for publication is open 
to all, and that the process isn't biased according to who is asking,
but my understanding is that a great many drafts which are submitted 
for publication are rejected.  Like any other publication series
which has value as a compilation, the RFC series requires editorial 
oversight and filtering.  

For those that want an unfiltered publication series, there's always the web.
Or Usenet.

Keith

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 8 Apr 2000 22:09:52 +0100 (BST)

On Fri, 7 Apr 2000, Peter Deutsch in Mountain View wrote:
[much ad hominem snipped]
> always go elsewhere. Where does this lead?

This leads to peer review and advancing the state of the art by
criticism, feedback and selection.

> Well, look at the list of signatories to the Draft in question.

technical merits, please.

> 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

whose technical content I recall as being a few lines of incorrect
EBNF notation that didn't parse. But hey, they were generating a _lot_
of signatories with their write-in campaign.

> concept of the IETF 

I'd like a reference for the original concept of the IETF, please; I
worry about history being rewritten. What was the original concept of
'RFC Editor', exactly?

> is another document, making your case.

...which is why Keith began this thread in the first place. Or don't
mailing list posts count as documents?

> 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.

Peer review slows things down. This is unavoidable in exposing the
work to a larger audience, but has long-term societal benefits
unfortunately not quantifiable on a balance sheet.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Dave Crocker <[email-masked]>
Date: Sat, 08 Apr 2000 14:29:04 -0700

>uh, no.   this is a common myth, but it's not true, and hasn't been

First, let's be clear that your statement includes a contradiction:  If 
something "hasn't been true for many years" then it is not a myth but, 
rather, a poorly-known change in policy.

That's not nit-picking, it is intended to emphasize that the policy WAS in 
force.

RFC 223, "Instructions to RFC Authors" is a bit vague on this, though it 
does contain an essential statement, in Section 2, along with various other 
qualifiers:

>In some cases it may be determined that the submitted document is not
>    appropriate material to be published as an RFC.

So this does make clear that publication is not an absolute guarantee.

The guiding policy "for may years" has been relevance/interest for the 
Internet community.

One would be hard-pressed to inspect the author-list of 
draft-cerpa-necp-02.txt, the work of the associated companies, and the 
clear need for optimizations of application performance, and then deem this 
document not relevant.

That moves us back to 'technical adequacy'.  Again, that distinguishes 
between "interest value" and "IETF standardization", rather than "publish" 
vs. "do not publish".

d/

ps.  I'm done.  There are more important aspects to the debate about this 
draft.

=-=-=-=-=

---

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Sat, 08 Apr 2000 02:30:25 -0400

> for at least another decade.  There's still lots of time for people to

Well, I don't share the view of a monotonic march towards the "correct" Internet.
Just as the first single celled giving off massive amounts of waste oxygen created
an environment which led eventually to the furry mammals, the Internet responds and
evolves from instantiation to instantiation. I hear talk about products which people
expect to only have a lifetime of a few years, or even a period of months, until
evolution moves us all on. Some of the things that you find so offensive may not
even be relevant in a couple of years.

But (you knew they'd be a but, didn't you?) there is a substantial market for
products based upon interception or redirection technologies today. I don't offer
this as a technical argument for their adoption. I was merely pointing out that the
market has voted on this technique and judged it useful despite what the IETF might
or might not decree. Short of punishing those poor misguided users, I don't know
what else you can accomplish on this one...

> IETF's job is to promote technical sanity, not to support unsound vendor

Well there you go. You think the IETF's Seal of Approval and promotion of technical
sanity can prevent our unsound vendor practices  from perpetrating Marketing BS on
poor users. You're right - the positions are fairly clear at this point. I'll try to
quieten down now...

                                                                  - peterd

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Apr 2000 17:40:34 -0400

> clear need for optimizations of application performance, and then deem this 

I'm not hard-pressed to do this at all.  In fact I find it quite easy,
because I don't care who the authors work for.  

IMHO, we should base not publication decisions on the authors' employers.
We should base them on technical merit.

The trade press is quite good at fawning over vendors' products;
I don't think IETF needs to take on that role.

Keith

---

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Sat, 08 Apr 2000 03:31:26 -0400

g'day,

> technical merits, please.

I was not arguing for the merits of the technology in question based upon who
signed it. In fact, I haven't tried to address the technical merits of the
specific document at all. I was addressing the issue that Keith was declaring
a technique (IP address interception) as out of scope for the IETF and was,
in doing so, cutting the IETF off from an area of work that finds widespread
application on the net. This seemed inappropriate considering the claims for
the organization in such places as:

                   <http://www.ietf.org/tao.html#What_Is_IETF>

Note in particular the claims " It is the principal body engaged in the
development of new Internet standard specifications" and "Its mission
includes: ... Providing a forum for the exchange of information within the
Internet community between  vendors, users, researchers, agency contractors
and network managers."

IP address interception is a widely used technique that would not be
developed or documented through the IETF if Keith had his way. Since it is a
widely used technique for vendors and network managers, we'd have to ask Gary
Malkin to revise his document if we agree to Keith's request.

To be explicit, this is a metadiscussion about the IETF. I specifically
disclaim any interest or standing in a debate about NECP itself.

> of signatories with their write-in campaign.

Again, I did not engage in a debate about the technical merits of their
claims, I was (and am) pointing out that the IETF claims to be a gathering
place to educate and exchange ideas and is not as good at that as it used to
be (IMHO).

> worry about history being rewritten. What was the original concept of

I'm away from my archives, and my history only goes back about 10 years, so
I'll leave that for others who were there, but I refer you again to the Tao
of the IETF.

> mailing list posts count as documents?

Well, that's not the way I read his initial messages. He basically said "I
tried to stop them at the drafting stage, but couldn't so I ask that we not
let this go out the door with our name on it".

Originally the response to an RFC you disagreed with was an RFC explaining
the problems you perceive. It is true that things have become more formal
over time, but nowhere is it carved in stone tablets that we can't identify
problems with current trends and make some adjustments to our processes.
That's not a call for less peer review. It's a call for less of a single
world view, and more tolerance for multiple world views. In effect, I'd also
rather we worry more about what technical people do with our documents and
less with what marketing people do with our documents.

> unfortunately not quantifiable on a balance sheet.

I guess I didn't explain that very well. The question was not whether the
work would be submited to peer review, but whether the IETF was an
appropriate forum for that peer review. The view I've heard expressed several
times has been that the IETF has ossified and would not be receptive to new
ideas so just slowed things down. The implication being that the IETF was no
longer relevant to the engineering process. You are not going to hear this
opinion expressed here from people who have already moved on, so I thought
I'd pass it on.

Note, I am *not* suggesting Cisco has abandoned the IETF. Heck, such a
decision would be so way out of my pay grade (and not the way I see this
company working  at all).  I'm just suggesting that at least some individuals
I know (and not just at Cisco) are starting to feel that the IETF is less
relevant to their needs than it used to be. Some people are going to say
"great, that'll cut down on the marketing BS".. I happen to say "Houston, we
have a problem here..."

                                                                            -
peterd

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 8 Apr 2000 15:51:15 -0700 (PDT)

I'd like note my agreement with to the comments made by Dave Crocker.

And I would like to suggest that there is perhaps yet another aspect of
this debate:

The IETF recently made a strong moral statement against CALEA.  That
statement carried weight; it was noticed; it had impact.

And that statement carried weight precisely because it was unique - it was
a statement of morality that carried weight because such statements are
reserved for the worst of the worst.

If the IETF engages in routine non-acceptance of "informational" documents
on the basis of non-technical concerns the IETF will, I believe, lose its
clear and loud voice when that voice is most needed to be heard.

		--karl--

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Apr 2000 19:14:11 -0400

Peter,

I don't think I would agree that NECP is out of scope for IETF.
I think it's pefectly valid for IETF to say things like "NECP
is intended to support interception proxies.  Such proxies 
violate the IP architecture in the following ways: ... and 
therefore cause the following problems... the only acceptable 
things for an interception proxy to do within the current 
architecture are those things which are already allowed by the
IP layer (route packets without change to their intended 
destination, delay packets, duplicate packets, or drop them)
and the use (if at all) of devices that do more than this should 
be limited to the following situations..."  But it's difficult to 
say things like this if you start with a document that assumes 
that interception proxies are fundamentally a good thing.  

IETF tries to make the Internet work well.  If you propose something
that fundamentally violates the design of the Internet Protocol,
and which harms the ability of Internet applications to work well,
is that really something that the IETF should take on?  Granted
that the Internet can and should evolve over time, but proposals that
fundamentally change the architecture need to be examined from a 
big-picture point of view and not in a piecemeal fashion.

> company working  at all).  I'm just suggesting that at least some 
> individuals I know (and not just at Cisco) are starting to feel that the 
> IETF is less relevant to their needs than it used to be. 

then perhaps they misunderstand the IETF.  IETF doesn't exist to
meet the needs of cisco or any other single group.  IETF exists 
to help the Internet work well for the benefit of all Internet users.  
When vendors produce products that harm the ability of the Internet
to work well, they're quite naturally putting themselves in conflict
with the IETF.  This shouldn't surprise anyone.

Keith

---

From: Peter Deutsch <[email-masked]>
Date: Sat, 08 Apr 2000 06:03:39 -0400

g'day,

Keith Moore wrote:

> We should base them on technical merit.

Okay, I did some digging. Here are a few relevant excerpts from RFC
2026:

...

   The RFC series of documents on networking began in 1969 as part of

   the original ARPA wide-area networking (ARPANET) project (see

   Appendix A for glossary of acronyms).  RFCs cover a wide range of

   topics in addition to Internet Standards, from early discussion of

   new research concepts to status memos about the Internet. 

...

   Not all specifications of protocols or services for the Internet

   should or will become Internet Standards or BCPs.  Such non-standards

   track specifications are not subject to the rules for Internet

   standardization.  Non-standards track specifications may be published

   directly as "Experimental" or "Informational" RFCs at the discretion

   of the RFC Editor in consultation with the IESG (see section 4.2).

...

      ********************************************************

      *                                                      *

      *   It is important to remember that not all RFCs      *

      *   are standards track documents, and that not all    *

      *   standards track documents reach the level of       *

      *   Internet Standard. In the same way, not all RFCs   *

      *   which describe current practices have been given   *

      *   the review and approval to become BCPs. See        *

      *   RFC-1796 [6] for further information.              *

      *                                                      *

      ********************************************************

...

4.2.1  Experimental

   The "Experimental" designation typically denotes a specification that

   is part of some research or development effort.  Such a specification

   is published for the general information of the Internet technical

   community and as an archival record of the work, subject only to

   editorial considerations and to verification that there has been

   adequate coordination with the standards process (see below).  An

   Experimental specification may be the output of an organized Internet

   research effort (e.g., a Research Group of the IRTF), an IETF Working

   Group, or it may be an individual contribution.

...

4.2.2  Informational

   An "Informational" specification is published for the general

   information of the Internet community, and does not represent an

   Internet community consensus or recommendation.  The Informational

   designation is intended to provide for the timely publication of a

   very broad range of responsible informational documents from many

   sources, subject only to editorial considerations and to verification

   that there has been adequate coordination with the standards process

   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet

   community and are not incorporated into the Internet Standards

   Process by any of the provisions of section 10 may be published as

   Informational RFCs, with the permission of the owner and the

   concurrence of the RFC Editor.

...

   If (a) the IESG recommends that the document be brought within the

   IETF and progressed within the IETF context, but the author declines

   to do so, or (b) the IESG considers that the document proposes

   something that conflicts with, or is actually inimical to, an

   established IETF effort, the document may still be published as an

   Experimental or Informational RFC.  In these cases, however, the IESG

   may insert appropriate "disclaimer" text into the RFC either in or

   immediately following the "Status of this Memo" section in order to

   make the circumstances of its publication clear to readers.

Seems pretty clear to me. Given that one of the roles of the IETF is

"Providing a forum for the exchange of information within the Internet

community between vendors, users, researchers, agency contractors and

network managers" (ref: RFC 1718), it would seem appropriate to publish

material from vendors that is finding widespread use, even if it

violates some individuals' personal view of the how the Internet should

be built.

> I don't think IETF needs to take on that role.

You seem quite afraid of the IETF being hijacked by vendors' marketing
people, but I submit you are denying a documented role of the IETF to be
a clearing house for information in the process. If you want the
appropriate words of RFC 22026 and 1718 deleted that you take the
appropriate steps to initiate the change, but I suggest that meanwhile
you shouldn't be denying the documented evidence for such a role within
the IETF.

					- peterd

-- 

   A specification that has been superseded by a more recent

   specification or is for any other reason considered to be obsolete is

   assigned to the "Historic" level.  (Purists have suggested that the

   word should be "Historical"; however, at this point the use of

   "Historic" is historical.)
----------------------------------------------------------------------

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 8 Apr 2000 23:03:34 -0400

Date: Sat, 08 Apr 2000 02:30:25 -0400
   From: Peter Deutsch in Mountain View <[email-masked]>

   Well there you go. You think the IETF's Seal of Approval and
   promotion of technical sanity can prevent our unsound vendor
   practices from perpetrating Marketing BS on poor users. You're right
   - the positions are fairly clear at this point. I'll try to quieten
   down now...

Whether or not the withholding of IETF's Seal of Approval would
influence the vendors is a separable question from whether or not it
would be responsible for the IETF to give such a Seal of Approval for
something which is a bad idea from a technical point of view.

							- Ted

---

From: "Martin J.G. Williams" <[email-masked]>
Date: Sun, 09 Apr 2000 04:39:22 +0100

I've come into this discussion rather late, however there is at least one
salient point which I believe that
Keith Moore has argued rather well...

In my understanding the role of the IETF is to promote the logical growth
and evolution of the Internet Protocols.
Whilst 'vendors' have massive technical resources at their disposal, one
thing that they are not, is impartial...this
is what I have always believed that the IETF's role is!

There is no denying the benefits that companies like Cisco have brought to
the Internet, but their kotive is, quite simply,
profit based....no more, no less.

On another note - to the guy who said 'this is way out of my pay grade' - I
would have to say...since when did pay reflect IQ?
Knowledge and insight are a valuable and rare commodity anyway...if we
start discriminating an the basis of income then
all of these discussion will become irrelevent within ten years, if not
less! (i'm not gonna name any names here! :-)  )

Kind regards
Martin

---

From: Keith Moore <[email-masked]>
Date: Sun, 09 Apr 2000 00:34:38 -0400

> a clearing house for information in the process. 

I have no problem with IETF having that role, and I agree that it is useful.
My objection was not about IETF having this role, but about publication of 
this specific document, in its current form.

2026 never says that all industry contributions are automatically 
worthy of publciation.  Neither does it say that the purpose of
RFCs is to serve as a way for vendors to claim legitimacy for 
techincally dubious ideas - as happens all too often.

This one, I think, is not worthy.  Or at least, it's on the margin.

Keith

---

From: "Martin J.G. Williams" <[email-masked]>
Date: Sun, 09 Apr 2000 05:38:35 +0100

I couldn't agree more Keith,

As far as i'm concerned (IMHO) if the standards bodies were to be driven by the
vendors, then they would become no more
than sanitised purveyors of de facto standards, and je jure standards would be
relegated to being nothing more than "misty-eyed" memories.
(Apologies if my spelling isn't up to scratch, but it's late!)

Martin

---

From: Pete Resnick <[email-masked]>
Date: Sun, 9 Apr 2000 12:54:28 -0500

>because I don't care who the authors work for.

You should care. Who the authors work for may have no impact 
whatsoever on *technical merit* (I would claim it never does), but it 
very often does indicate something about *relevance to the Internet 
community*. If lots of people from companies that have impact on the 
working of the Internet are doing something on the Internet and want 
to publish the existence of that practice, it is bloody well 
*relevant*, regardless of its technical merit.

>We should base them on technical merit.

You need to go back and read the message to which you are responding 
again. Technical merit is specifically *not* a factor in deciding 
publication of an Experimental or Informational document.

>I don't think IETF needs to take on that role.

3 straw men in one message. Impressive.

Dave's message only said that technical merit has no bearing on 
publication of Informational or Experimental RFCs. He (nor anyone 
else in this thread as far as I can tell) mad no claim that we ought 
to determine technical merit on the basis of the vendors, nor that we 
base a decision for publication based solely on who those vendors 
are, nor that we fawn over vendors products. He suggested that we 
allow them to document current practice. Unless (cf. 2026) "the IESG 
considers that the document proposes something that conflicts with, 
or is actually inimical to, an established IETF effort" (which I have 
not heard out of the IESG yet), the RFC editor should (with the 
required changes of getting rid of "implied standardhood") publish 
the document.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 09 Apr 2000 20:21:40 +0200

>publication of an Experimental or Informational document.
For those who believe this, please check out the technical merit of
draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-05.txt, and ask yourselves
if this should be published as an RFC.

After that little exercise, you will appreciate that technical merit *is*
a factor in deciding publication of an Experimental or Informational document.
But - and this is important - THE DECISION IS MADE BY THE RFC EDITOR.
All we're doing here is creating advice.

                    Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Pete Resnick <[email-masked]>
Date: Sun, 9 Apr 2000 13:51:09 -0500

On 4/9/00 at 8:21 PM +0200, Harald Tveit Alvestrand wrote:

>draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-05.txt, and ask 
>yourselves if this should be published as an RFC.

It should not. See my message to Vernon. But it's not because it 
lacks technical merit that it shouldn't be published.

>After that little exercise, you will appreciate that technical merit 
>*is* a factor in deciding publication of an Experimental or 
>Informational document.

Not if RFC 2026 is respected. I see nothing in 2026 allowing for this 
possibility.

pr

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 09 Apr 2000 21:41:50 +0200

At 13:51 09.04.2000 -0500, Pete Resnick wrote:
>It should not. See my message to Vernon. But it's not because it lacks 
>technical merit that it shouldn't be published.
>

Section 4.2.3:

    The RFC Editor
    is expected to exercise his or her judgment concerning the editorial
    suitability of a document for publication with Experimental or
    Informational status, and may refuse to publish a document which, in
    the expert opinion of the RFC Editor, is unrelated to Internet
    activity or falls below the technical and/or editorial standard for
    RFCs.

                     Harald

---

From: [email-masked]
Date: Sun, 09 Apr 2000 12:39:11 -0800 (PST)

> Not if RFC 2026 is respected. I see nothing in 2026 allowing for this

You need to look harder. From RFC 2026:

  RFC publication is the direct responsibility of the
  RFC Editor, under the general direction of the IAB. 

And from RFC 1601bis:

   The RFC Editor executes editorial management and publication of the
   IETF "Request for Comment" (RFC) document series, which is the
   permanent document repository of the IETF. 

This makes it clear that the RFC Editor exercises editorial control over the
RFC series, but doesn't specify exactly what editorial control means. However,
the RFC Editor has interpreted its editorial responsibilities as involving
review with the distinct possibility of not publishing documents not believed
to be worth publishing for at least as long as I've been involved in the IETF.

I can recall discussions regarding the RFC Editor's refusal to publish
documents as early as 1992. And I suspect the lateness of this date is simply
due to my not having been involved in the IETF prior to 1989, faulty memory on
my part, or both.

Once again RFC 2026 doesn't specify the criteria the RFC Editor uses to decide
not to publish. But speaking as an observer of the process for over a decade,
the criteria I've seen the RFC Editor apply to potential RFCs over the years
has most definitely included an assessment of technical merit, among other
things.

Now, in recent years the RFC Editor, rather than simply accepting contributions
directly from authors and publishing them without community input, has chosen
to use the Internet Drafts mechanism as a means of getting community input on
whether or not a given document should be published. This is what is happening
here. 

I haven't always agreed with the RFC Editor's decision as to whether or not to
publish something (sometimes things have been published that I didn't think
were of sufficient quality, other times things have been rejected I didn't
think should have been), but I have never questioned the right of the RFC
Editor to refuse to publish something.

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Sun, 9 Apr 2000 15:45:31 -0500

On 4/9/00 at 12:39 PM -0800, [email-masked] wrote:

>[...]the RFC Editor exercises editorial control over the RFC series, 
>but doesn't specify exactly what editorial control means.

Actually, Harald's quote from 2026 does make it pretty clear:

Section 4.2.3:

    The RFC Editor

>However, the RFC Editor has interpreted its editorial 
>responsibilities as involving review with the distinct possibility 
>of not publishing documents not believed to be worth publishing for 
>at least as long as I've been involved in the IETF.

Absolutely. The question is on what basis that decision is made. 2026 
gives basically two criteria by which the RFC Editor may refuse 
publication:

1. It's unrelated to Internet activity. That's the one Dave and I 
(and others) have been pointing to. Clearly this draft is related to 
Internet activity; it's deployed technology, for better or for worse.

2. It falls below the technical and/or editorial standard for RFCs. 
Now, I think we all agree that the current document *does* fall below 
editorial standards insofar as it plays the "I am a standard" game in 
the text, making itself out to sound like a standard even though it's 
not. The document should be held up until that is fixed. But again, 
that's not Keith's main issue. He's complaining about "technical 
merit" (and sometimes legal or moral merit).

So, here I want to split a hair, but I think it's one worthy of 
splitting: RFC 2026 says "falls below the technical *standard* for 
RFCs". I don't believe what it's referring to here is whether the RFC 
Editor thinks that the document is describing a technically a bad 
idea, but rather whether the technical *quality* of the document 
(e.g., whether it is technically coherent, describes the protocol in 
appropriate detail, doesn't have the classic Gary Larson "...and then 
a miracle occurs..." clause in the middle of equation, etc.) is up to 
snuff. This seems like a good criterion to base publication on, 
whereas the other does not: It is always good to publish what I'm 
likely to have to deal with on the net, whether or not it's a good 
thing that it actually is going on.

It is of course a good thing not to standardize things that are 
technically bad ideas. But standardization is not at issue here. This 
is a question of how the RFC Editor should exercise its editorial 
judgement. 2026 lays out a reasonable guideline. I think Keith's 
request falls outside that (admittedly loose) bound.

pr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Apr 2000 13:52:31 -0700

At 12:54 PM 4/9/00 -0500, Pete Resnick wrote:
>publication of Informational or

This is a good example of the reason this apsect of debate is a major waste 
of time.

Although Pete is attempting to support my comments -- and I equally concur 
with his point of view -- in fact I did not say what he offers as the 
summary of my statement.  What I said was actually quite 
different.  However, further debating who said what is not where things 
should go.

In other words, folks, we all -- and Pete is better than average readers of 
this list, not worse -- tend to mis-read was is written and to argue 
polemically, rather than attentively and incrementally.

It is my understanding that the draft in question has been referred to a 
working group (wrec).  So, debate about that draft should move to that 
working group's list.

Except that...

That working group does not have this topic on it's charter and this seems 
an extraordinarily major and difficult topic, to leave as only an 
incidental goal of a working group.

It strikes me that it would be much, much more productive to fire up a 
working group focused on this topic, since we have known of the application 
level need for about 12 years, if not longer.

d/

=-=-=-=-=

---

From: [email-masked]
Date: Sun, 09 Apr 2000 13:39:24 -0800 (PST)

> load-balancing server, etc), and at the "client" end.

I certainly agree that interception proxies at the server end are very useful,
and also note that as they are necessarily under the same administrative
control as the servers themselves, the various issues regarding content
alteration do not arise. In addition, since all users are likely to be
subjected to the sae proxy experience, it doesn't cause unecessary user
surprise. Indeed, this sort of thing seems to be an essential ingredient in
building really large "virtual servers", and having specifications that
facilitate doing this correctly would be a very good thing.

I also agree that interception proxies at the client end have their place,
although in such a case I don't think NECP is going to be applicable.

>  However, I am

Exactly. And after having read this specification, I also think these issues
are glossed over.

> distinction as clear as possible.

Agreed. I think the right thing to do at this point is to revise the
specification. One possible approach, and the one I'd prefer, is to simply call
for NECP to only be used on the server side. Alternately, the distinction of
the location of the service could be made clearer and the perils of arbitrary
intermediate use spelled out.

I also see some technical issues in the protocol itself. For example, the
performance metric set seems inadequate, at least based on my past experience
with other load balancing systems. OTOH, the set is extensible, so this
could be corrected fairly easily.

I also don't see a way for servers to pass information about what security
options to use when a proxy routes a connection back to that server. This sort
of thing has proved to be quite useful in practice. Even worse, doing this
properly would require an encryption option; as far as I can see the present
protocol only allows for integrity checks. I'm also not entirely comfortable
with how integrity checking gets turned on to begin with -- it seems to me that
there are some loopholes that would allow unauthorized interceptions under
some allowed circumstances.

Finally, the mechansisms for controlling which connection get routed
where seem inadequate. In practice it is common to have a need for
proxies to do authentication and based on the authentication they do,
route the connection to a particular server. Some hooks for specifying
this sort of thing as the server comes online will be essential in many
applications.

However, I don't see any of these technical issues as impediments to
publication as informational or experimental.

				Ned

---

From: Pete Resnick <[email-masked]>
Date: Sun, 9 Apr 2000 16:29:35 -0500

[Removed IESG and RFC Editor from the recipients]

On 4/9/00 at 1:52 PM -0700, Dave Crocker wrote:

>Although Pete is attempting to support my comments -- and I equally 
>concur with his point of view -- in fact I did not say what he 
>offers as the summary of my statement.  What I said was actually 
>quite different.

I agree. I apologize for any mischaracterization, and I think my most 
recent response to Vernon explains my understanding of your position 
fairly. However:

>So, debate about that draft should move to that working group's list.

I will heed your advice and henceforth take any required discussion 
to private mail or to that list.

pr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Apr 2000 14:35:15 -0700

>for NECP to only be used on the server side. Alternately, the distinction of

Let's remember that a major goal of these facilities is to get a user to a 
server that is 'close' to the user.  Having interception done only at 
distant, localized server farm facilities will not achieve that goal.

Further, I'm unclear about the architectural difference between (and 
apologies if things don't quite line up):

client --> Internet -> ISP -> Intercept -> subnet1 -> Server1
                                         -> subnet2 -> Server2
                                         -> subnet3 -> Server3

versus

client --> Internet -> ISP -> Intercept -> Internet -> Server1
                                         -> Internet -> Server2
                                         -> Internet -> Server3

>intermediate use spelled out.

Perhaps the issue is not location, but coherent administration?

>could be corrected fairly easily.

This would seem to walk down the path of considering this spec as a BASIS 
for pursuing a standard?

(The usual caveats, proscriptions, etc. apply with respect to IETF change 
control.  What we see now is likely not what they will get later...)

>publication as informational or experimental.

ack.

d/

=-=-=-=-=

---

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Sun, 09 Apr 2000 03:35:22 -0400

g'day,

Dave Crocker wrote:
.  .  .

> level need for about 12 years, if not longer.

Which raises the interesting question as to what the participants would hope to
be the outcome of such a working group and whether we could possibly move
towards something ressembling a technical consensus, given the current polarity
of the debate. There are certainly more people than Keith who would brand the
relevant practices as evil and immoral. For sure you'd hear strong views
against endorsing transparent proxies, NATs and other things already touched
upon here over the past few months. I could mention a few more, at least as
controversial, which I'd see as coming into scope in the near future but
frankly I'm not personally willing to spend any energy trying to engage in any
form of consensus building on such things right now. The parties are simply too
far apart for me to expect there to be anything but grief at the other end.

I've seen us spend a lot of time engaging in working groups in which some
number of the participants has as their goal the invalidating of the underlying
concept or torpedoing the process itself. Having been there, done that and
collected the T-shirt a couple of times myself, I wouldn't go through that
again just because I have a soft spot, either for the IETF or in my head.

That isn't to say I disagree with you, Dave. There's definitely work to be done
here. It's just that this is one hairy tarball, and although there's going to
be lots done in this area over the next couple of years we've probably reached
a fork in the road where the IETF has to take stock of itself before it can
play a useful role. If it doesn't do that I predict that some of the major
architectural and implementation decisions in this particular subspace will be
taking place outside the IETF. And clearly, some would think that a good thing.

- peterd

--

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

---

From: [email-masked]
Date: Sun, 09 Apr 2000 15:42:41 -0800 (PST)

> distant, localized server farm facilities will not achieve that goal.

You are confusing topological locality with administrative locality. I was
talking about the latter, and so, I believe, was Valdis.

Indeed, the only reason I raised the security issues I did was to accomodate
the case where the proxies aren't topologically local to the servers. And
one of the things I see as missing from performance metric set is a means
of factoring in network QOS.

> Perhaps the issue is not location, but coherent administration?

In the case of proxies being "close" to the server, absolutely.

> This would seem to walk down the path of considering this spec as a BASIS

I would not have a problem with pursuing standards work on protocols for load
balancing within a single administrative area. (This is not to say that
defining a protocol that can span administrations would be useless. It would be
very useful indeed, but I see so many potential ratholes it isn't funny.)

I suspect a case could be made for working on client-administered proxies, but
it seems fairly clear to me that this isn't what the present protocol
is about.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Apr 2000 16:09:47 -0700

>towards something ressembling a technical consensus, given the current 

we've done it more than once, before.

>concept or torpedoing the process itself. Having been there, done that and

First, let me compliment you on getting the 'has' correct.  I'm envious, 
since it took some time to parse the sentence carefully and discover that, 
once again, Canadian education beats the tar out of average US education...

There are always some people who object to the details of any interesting 
work.  Hence the real question is a) whether there is a substantially 
larger, interested constituency interested in making progress, and b) 
whether that larger constituency has the benefit of a working group chair 
able to manage the process well enough to keep the disrupters under 
control.  The larger and more diverse IETF does make this management task 
more difficult, but it is not impossible.

>here. It's just that this is one hairy tarball, and although there's going to

Yes.  Lots of legitimate opportunity to get bogged down in the difficulty 
and complexity.  That also makes the task more interesting, doesn't it?

>taking place outside the IETF. And clearly, some would think that a good 

"some" always do.  however, while the IETF can not and should not try to do 
everything, this task seems entirely appropriate, since it requires a broad 
range of technical talents, across most of the stack, to get it right.

d/

=-=-=-=-=

---

From: [email-masked]
Date: Sun, 09 Apr 2000 15:55:15 -0800 (PST)

> merit" (and sometimes legal or moral merit).

Well, there's at least one more that's clearly called out in RFC 2026: If a
document is directly related to an area where there's ongoing IETF standards
activity it should not be published. (It isn't clear to me whether or not the
present document falls into this category.)

But regardless of the specifics in RFC 2026, my point is I've seen past cases
where the RFC Editor has refused publication where the apparent basis was none
of these things. And in particular, there have been cases where it was clearly
technical merit in Keith's sense of the term that was at issue. (I've also seen
cases where there were clear technical merit issues but publication happened
anyway.)

And nowhere does RFC 2026 say that the list of criteria for rejection it
provides is deemed to be exhaustive.

> thing that it actually is going on.

I'm sorry, but I think splitting this particular hair is a place we really
don't want to go. I'd much rather rely on the RFC Editor's judgement
as to whether or not to publish something than try to nail down an
exhaustive list of criteria for rejection (or acceptance).

And if you don't believe this is a really bad idea, I suggest that you read
"The Death of Common Sense". It argues this point rather forcefully IMO.

> request falls outside that (admittedly loose) bound.

I'm afraid I have to disagree. I think that Keith's assessment of technical
merit is a completely valid input to the decision process. The furthest I'd go
is to say it is by no means a decisive factor. However, in the case of the
present document I also think its more or less a moot point, as there are
plenty of other reasons why the document should not be published in its present
form, and once those are addressed the technical merit issue will have been
addressed as well, one way or the other.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Apr 2000 16:31:58 -0700

>talking about the latter, and so, I believe, was Valdis.

As my later comment meant to convey, I too was clear about the distinction, 
but yes I was definitely confused about the discussion underway.

>very useful indeed, but I see so many potential ratholes it isn't funny.)

Sounds like a conveniently healthy constraint, then.

d/

=-=-=-=-=

---

From: Fred Baker <[email-masked]>
Date: Sun, 09 Apr 2000 10:33:14 -0400

>clear and loud voice when that voice is most needed to be heard.

That's a valid concern. The trade-off of interest to me is the one between 
publishing standards and publishing other documents. If you look at other 
bodies, their standards are clearly identifies - they only publish 
standards. We also publish other things, but do so under a nomenclature 
that is readily wrestled to the appearance of support as standards. We're 
all aware of cases where something was poublished as informational, 
experimental, etc, and the next press release announced support of that 
"standard", and of cases where RFCs, like IP on Avian Carriers, started 
winding up on RFPs simply because it was an RFC, and therefore "must" be 
the standard. This is another case of meaning dilution that I worry about.

To my recollection, the IESG has recommended very rarely that the RFC 
Editor literally not publish a document. We have added wording changes in 
the title, added IESG notes that say in effect "the IESG thinks this is a 
profoundly bad idea", and so on. The cases of not publishing at all that 
come quickly to mind are limited to Bill Simpson's documents about which 
there was an appeal last year. We didn't publish them because they did not 
give us license to change the text, the text said "this is the one true way 
to do" certain things related to IPSEC, and the IPSEC Working Group had 
similar-but-not-the-same documents. We felt that publishing both was likely 
to give the impression that Bill's informational documents were updating 
and changing the documents that the working group produced, and introduce a 
high probability of non-interoperable implementation. We didn't publish 
because we were of the opinion that it was better for the community.

I believe that the RFC Editor's also decides to not publish quite apart 
from IESG input, and does so when documents that come their lack substance. 
But their ethic tends to be that the RFC Series is the community memory, so 
recording things that do have substance is good even if they are bad ideas, 
because it let's someone else learn from the experiment.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Apr 2000 07:26:17 +0930

At 14.35 -0700 2000-04-09, Dave Crocker wrote:
>Let's remember that a major goal of these facilities is to get a 
>user to a server that is 'close' to the user.  Having interception 
>done only at distant, localized server farm facilities will not 
>achieve that goal.
>

In the first case, which Peter Deutch brought up with the cisco local 
director, I understand your picture being that the entity which 
provides the service running on Server1, Server2 and Server3 do 
provide either a hostname and/or IP-address which goes to a virtual 
host which resides "inside" the box which is doing the intercept. 
That box rewrites the IP headers including destination address etc 
and ships the packet to one of Server1, Server2 or Server3.

I.e. the client ask to contact the virtual host, and the virtual host 
is contacted.

In the second case (which is what I am opposing) the server provider 
does not have anything to do with the interception. He runs only 
Server1, while Server2 and Server3 are caches which the ISP chooses 
to redirect the packages to which are addressed to Server1.

That is from my point of view a big difference.

In the first case, the packets sent from the client reaches the 
destination (i.e. the interceptor, which really is not an interceptor 
at all, but some kind of NAT box like the cisco Local Director) while 
in the second case packages addressed to Server1 might not reach 
Server1 but Server2 or Server3.

     paf

---

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Sun, 09 Apr 2000 11:09:12 -0400

g'day,

Fred Baker wrote:

> that is readily wrestled to the appearance of support as standards.

.  .  .

> because it let's someone else learn from the experiment.

Well put. As Dave has pointed out earlier this weekend, there is a burning need
for better, permanent access to the Drafts collection. If we had that, perhaps
much of this discussion might become moot, since some of the out-on-a-limb
stuff may be circulated in a less "official" form, but remain permanently and
readily accessible. I still see value in having documents come out as "Request
For Comments" in the traditional sense, but it certainly wouldn't  hurt to find
ways to better distinguish between the Standards track and other documents.

                                                    - peterd

--
--------------------------------------------------------------------------------

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

---

From: Tripp Lilley <[email-masked]>
Date: Mon, 10 Apr 2000 06:33:06 +0000 (/etc/localtime)

> ways to better distinguish between the Standards track and other documents.

Here's a novel idea: we could stop calling them all "RFCs". Call them by
the designators they get once they're blessed (ie: STD, INF, EXP, etc.),
and stop ourselves citing them as RFC [0-9]+.

Change begins at home, as they say...

-- 
   Tripp Lilley  *  [email-masked]  *  http://stargate.sg505.net/~tlilley/
------------------------------------------------------------------------------
  "I only counted on today's sunlight and snow,
   on the rain that dampened my face."

   - L.E. Modesitt, Jr., Adiamante

---

From: [email-masked]
Date: Mon, 10 Apr 2000 02:30:38 -0400

> stuff may be circulated in a less "official" form, but remain permanently and

What would be *really* helpful is if the various revisions of the
drafts and the working group e-mail archives were together, so that
I could answer questions with "That doesn't work, it was tried in
draft-ietf-foobar-07.txt, tossed in -08.txt, see <here> for the
discussion why..."

What would it take to make it doable?

				Valdis Kletnieks

---

From: Peter Deutsch in Mountain View <[email-masked]>
Date: Sun, 09 Apr 2000 11:31:41 -0400

g'day,

> Change begins at home, as they say...

Yeah, although I'd personally hum for keeping the RFC nomencalture for the Standard
and Experimental class RFCs, as the name is understand to encompass that anyways. The
rest we could lump under something like "OFI" (Offered For Information? The marketing
guys here agree that they wont write code if I don't name products... ;-) Anyways, we
need to draw a clearer line between the standards which have been wrought by the
IETF, and information which has been captured and tamed, so to speak...

                    - peterd

---

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Apr 2000 23:01:38 -0700

At 10:33 AM 4/9/00 -0400, Fred Baker wrote:
>wrestled to the appearance of support as standards. We're all aware of 
>cases where something was poublished as informational, experimental, etc, 
>and the next press release announced support of that "standard", and of 
>cases where RFCs, like IP on Avian Carriers, started winding up on RFPs 
>simply because it was an RFC, and therefore "must" be the standard. This 
>is another case of meaning dilution that I worry about.

In absolute terms, these misuses/abuses of RFC reference are quite 
bothersome.

However they have been a fact of life pretty much forever.  Absent evidence 
that they have become a more serious problem than usual, the noise-factor 
of the misuses does not seem to cause enough community damage to warrant 
changing existing practise.

(I didn't read your note, Fred, as promoting a change, but others have been 
in favor of it.)

=-=-=-=-=

---

From: [email-masked]
Date: Mon, 10 Apr 2000 03:31:54 -0400

> In absolute terms, these misuses/abuses of RFC reference are quite 

The important question is "Does RFC2549 support prove to be self-limiting
in the marketplace".

I'm afraid I know the answer, and don't like it... ;(

				Valdis Kletnieks

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Apr 2000 07:00:56 -0400

> distant, localized server farm facilities will not achieve that goal.

granted, but...

an interception proxy that gets the user to a server that is 'close'
to that user (in the sense of network proximity), but 'distant' from the  
content provider (in the sense that it has a significant chance of
misrepresenting or damaging the content) is of dubious value.

and a technology that only works correctly on the server end seems
like a matter for the server's network rather than the public 
Internet - and therefore not something which should be standardized by IETF.

I do think there is potential for standardizing content replication
and the location of nearby servers which act on behalf of the content 
provider (with their explicit authorization, change-control, etc).

But IP-layer interception has some fairly significant limitations
for this application.  For one thing, different kinds of content on
the same server often have different consistency requirements, 
which become significant when your replicas are topologically distant
from one another.  If you treat an entire server as having a single 
IP address you probably don't get the granularity you need to implement 
efficient replication - you may spend more effort keeping your replicas
consistent (and propagating the necessary state from one to another)
than you save by replicating the content in the first place.  Obviously 
you can use multiple IP addresses, assigning different addresses to 
different kinds of content, but this also has limitations.  You can also 
get into problems when the network routing changes during a session or 
when the client itself is mobile. 

Bottom line is that IP-layer interception - even when done "right" - 
has fairly limited applicability for location of nearby content.
Though the technique is so widely mis-applied that it might still be 
useful to define what "right" means.

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 10 Apr 2000 07:59:24 +0100

>ways to better distinguish between the Standards track and other documents.

         The notion of resurrecting the IEN series was mooted several years ago.  
However, the community as a whole did not support that notion with any significant
vigour.  So that hasn't happened.  My personal view is that there would be some
value to having the IENs alive and well, but there are issues with such an
idea.  Also, some items put out as I-Ds really well and truly ought not be in
any IETF-related archival documents.  While the folks in this discussion might
disagree on which drafts fall in that category, everyone believes that at least
some documents ought not be published in an IETF-related archival document series.

         That all noted, I think this conversation isn't really productive any longer
(if it ever was).  The I-D in question has been referred to an existing IETF
WG for review, which is a very normal kind of process that we're all familiar with.
I've never seen a draft document that failed to benefit from broad review, so I think
this has to be a good thing.

         All IMHO.

Ran
[email-masked]

---

From: [email-masked]
Date: Mon, 10 Apr 2000 09:42:21 -0400

> Internet - and therefore not something which should be standardized by IETF.

Much the same logic can be applied to NAT (the way it's usually implemented).

Both have issues, both have proponents, and both will be done even more brokenly
if there's no standard for them.

Personally, I'd rather have the IETF issue verbiage saying "Do it this way",
than have 50 million content providers all implement it in subtly different
and broken ways.

"You are trapped in a twisty little maze of proxies, all different..." ;)

---

From: John Stracke <[email-masked]>
Date: Mon, 10 Apr 2000 10:02:24 -0400

RJ Atkinson wrote:

> While the folks in this discussion might

Mmm...I think the patent thread pointed out that, if we archived all the I-Ds, it'd be a
good repository for patent examiners to search.  Since some people patent bad ideas,
archiving bad ideas would be useful there.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |All your problems can be solved by not caring!|
[email-masked]|                                              |
\===============================================================/

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Apr 2000 10:36:50 -0400

> Much the same logic can be applied to NAT (the way it's usually implemented).

true.
 
> Both have issues, both have proponents, and both will be done even more 
> brokenly if there's no standard for them.

yes, this is the dilemma.  IETF has a hard time saying "if you're going to 
do this bad thing, please do it in this way".  for example, it's unlikely
that the vendors of products which do the bad thing would consent to
such a statement.  and if you take out the language that says "this is bad"
then the vendors will cite the RFC as if it were a standard.

and given that NATs are already in blatent violation of the standards,
it's not clear why NAT vendors would adhere to standards for NATs.
nor is it clear how reasonable standards for NATs could say anything 
other than "modification of IP addresses violates the IP standard;
you therefore MUST NOT do this".

> than have 50 million content providers all implement it in subtly different

not sure what content providers have to do with this -
if content providers harm their own content, it's not clear why IETF 
should care - there are ample incentives for them to fix their own problems.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Apr 2000 10:39:06 -0400

> The I-D in question has been referred to an existing IETF WG for review,

that assertion was made, but not confirmed by the ADs.
is it really true?  it seems odd because it really isn't in scope for wrec.

Keith

---

From: "Derrell D. Piper" <[email-masked]>
Date: Mon, 10 Apr 2000 08:44:40 -0700

> useful to define what "right" means.

And there you have the argument for publishing this document.  I much prefer a
model where we allow for free exchange of ideas, even bad ones.  I tend to
believe that if someone took the time to write up a document that there's
probably some reason for it.  So let's call this an experimental RFC and get
on with life.  Isn't that what the experimental category denotes?

Derrell

---

From: "Dick St.Peters" <[email-masked]>
Date: Mon, 10 Apr 2000 11:50:05 -0400 (EDT)

...
> to redirect the packages to which are addressed to Server1.

That's an assumption that's not always valid.  There are cases in
existence now where a service provider *pays* the ISP to run a local
mirror, leading to

                                        ->  subnet  -> Server2

It would be entirely possible for the service provider, having paid
the ISP not to get traffic from the ISP's clients, to block that
traffic - or limit its bandwidth.

Consider the progession:

client --> Internet -> ISP -> Router -> 56k  -> Server1
                                     -> T3   -> Server1

client --> Internet -> ISP -> Intercept -> 56k  -> Server1
                                        -> T3   -> Server2

                                        ->  subnet  -> Server2

What is the fundamental difference between choosing the best path and
choosing the best source?  Arguments that the latter breaks the IP
model are simply arguments that the IP model is broken for today's
Internet and will be even more broken for tomorrow's.  The IETF can
fix the model ... or leave that to someone else.

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

---

From: John Martin <[email-masked]>
Date: Mon, 10 Apr 2000 17:57:09 +0200

>is it really true?  it seems odd because it really isn't in scope for wrec.

Let me jog your memory:

At 06:29 PM 30/12/99 +0100, Patrik Fältström wrote:
>A request has arrived to publish the named document as informational RFC. 
>The IESG wants all documents in this area to explicitely pass the WREC 
>working group, ...

I then sought clarification, re-sent the document to WREC (it had been sent 
before), to determine if there was a conflict - there wasn't. The authors 
re-submitted it.

John

---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Kruisweg 799                               Fax: +31 23 567 9699
NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Apr 2000 19:31:51 +0930

>fix the model ... or leave that to someone else.

The difference between what you describe and a random transparent 
proxy is that in your case it is the service provider which is 
building a service with whatever technology he chooses. It is not a 
random ISP in the middle which intercepts and changes IP-packages 
without neither of client nor service provider knowing anything about 
it. If the service provider knows about it, he can choose software 
(or whatever) which can stand the intercept.

Yes, it is the same technology which is used, but not in the same 
ways in both cases.

I.e. for me it is a question _who_ is managing the interception.

   paf

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Apr 2000 14:18:43 -0400

> And there you have the argument for publishing this document.  

no, this document doesn't try to do that - the protocol it proposes
is an attempt to work around one of the many problem associated
with interception proxies, but it's hardly a blueprint for how
to do them "right" (nor does it purport to be).

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Apr 2000 14:21:01 -0400

> >is it really true?  it seems odd because it really isn't in scope for wrec.

yes, I remember that wrec said there wasn't a conflict with its work.
that's not the same thing as wrec discussing whether the approach
is technically sound or whether the document is worthy of publication.

IMHO, that discussion doesn't belong in wrec.  but it's up to the ADs.

Keith

---

From: John Martin <[email-masked]>
Date: Mon, 10 Apr 2000 21:43:12 +0200

>is technically sound or whether the document is worthy of publication.

I appreciate that you cannot attend every working group meeting but the 
document, the approach and the implementation were discussed at all but one 
WREC face-to-face meeting and on the mailing list. We received comments and 
made changes as a result of discussions on WREC.

Note: many of those who are / were active within WREC were / are also 
active in discussing NECP.

John

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Apr 2000 16:12:27 -0400

> Arguments that the latter breaks the IP
> Internet and will be even more broken for tomorrow's.  

those two statements aren't equivalent.  the fact that people want 
to break the IP model may mean that it's easier (at least initially)
to deploy a broken solution than to deploy a technically sound one 
(just like it's easier to dump your toxic waste in the local stream
than it is to clean it up) 

but the fact that IP doesn't do everything that people want doesn't 
mean that the IP model is broken, any more than the stream is broken 
because it doesn't solve your waste disposal problem.  

some approaches to solving problems seem simple at first but 
really are a lot more complex than they look.

NATs seem like a simple solution to address exhaustion...until 
you figure in the additional complexity of application-level 
gateways inside the NAT, and of the additional code that ends
up in applications that try to work around the problems caused 
by NATs, and (in some cases) of the additional middleware that 
you need to deploy to solve those problems.  with enough work
you can get around most of the problems that NATs cause, but
it would have been a lot simpler, more efficient, more flexible,
and more reliable if you had just solved the address space
problem in a sane way.  (and regardless of what some folks think 
about IPv6, it's a LOT saner than NAT).  and in addition to the
complexity and increased operating costs and reduced reliability
etc. required by those workarounds, you also end up with an
increased effort requried to deploy new applications (e.g. IP
telephony).

interception proxies seem like a simple solution to automatic
location of services, until you figure in the additional complexity
(of things like NECP) required to make them work in something 
resembling the fashion that the applications expect, and the 
additional complexity of things (like IPsec) that applications and 
services need to do to defeat interception proxies that get in 
their way.  

similar arguments apply to content-modifying firewalls and 
probably apply to traffic shaping.

it's completely natural that people will try such approaches -
they are trying to address real problems and they want quick 
solutions to those problems.  but if the quick fix solutions  
get entrenched then they cause their own set of problems which
are worse then the original problems.  this is not progress.

IMHO we need to see these things for what they are:

- quick fixes with limited applicability and future
- indicators that there is an important problem that needs to be
  solved in a technically sound fashion

Keith

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 10 Apr 2000 20:11:58 -0700

>solutions to those problems.  

In particular, they will try such approaches if they are not
presented with better alternatives. 

>but if the quick fix solutions get entrenched then they cause 
>their own set of problems which are worse then the original 
>problems.  this is not progress.

Progress is created by the development of
solutions that do not cause their own set of problems. 
This does not happen merely by condemning other less
desirable solutions. It happens by presenting a better
alternative. 

>  solved in a technically sound fashion

If this mail thread is any indication, I'd say the indicator is 
shining brightly.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Apr 2000 03:23:08 -0400

> presented with better alternatives. 

there's something odd to my ear about people needing to 
*be presented* with better alternatives than doing harm to the architecture
as opposed to those people *developing* better alternatives.

I suspect there's something about the current economic climate that
favors development of quick fixes over development of sane ones.
but the apparent shortsightedness still bothers me.

Keith

---

From: Erik Fair <[email-masked]>
Date: Tue, 11 Apr 2000 01:39:32 -0700

It's much worse than that.

In the End to End model, far too many of our problems require 
changing all the end systems to solve. However, that's extremely 
difficult to do, particularly as there is little or no incentive (the 
DCA/DISA had guns, and control of the IMPs in 1982/1983 to force the 
NCP->TCP/IP conversion - there is no equivalent agency today).

Almost all of the pressure created by the growth of the Internet is 
on the network operators and their vendors (e.g. router vendors), 
rather than on the users and the end systems (and the end system 
vendors, e.g. PCs, Macs, Suns, etc).

It's also bad that there is little or no integration of intermediate 
system vendors with end system vendors (or vice versa), because that 
results in insufficient sharing of information between those two 
industry segments. The IETF should be facilitating information 
exchange, but it isn't working as well as it should (otherwise we 
wouldn't have these problems, right?).

So, with nearly all the pressure on the operators and the vendors 
that serve them, the "solutions" they come up with are necessarily 
pretty ugly hacks (e.g. NAT, TCP spoofing, Firewalls) because they 
have to deal with the reality that they can't change the end systems 
themselves, or require them to be changed.

This is a structural problem. Until the situation changes, we're 
going to keep on seeing ugly hacks that do violence to the Internet 
architectural model deployed, marketed, touted as "solutions."

	an author of RFC 1627,

	Erik <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Apr 2000 09:05:55 -0500

Bernard Aboba wrote:
...
> If this mail thread is any indication, I'd say the indicator is

There are many people wearing 3-month goggles who still just can't see it.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Apr 2000 10:59:50 -0400

> wouldn't have these problems, right?).

it's not clear that the problems are caused by lack of information
exchange, given time-to-market pressures that cause folks to ship 
product now and deny causing problems later.

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Apr 2000 06:59:12 -0700

>relegated to being nothing more than "misty-eyed" memories.

Are you saying that IETF specifications are de jure standards? If so, don't 
tell the State Department, they don't know that :^)

IETF Specifications are indeed de facto standards - they are standards in 
part because the community calls them such, but mostly because the 
community implements them and uses them.

I think what you meant to say is that they would be nothing more than 
purveyors of the proprietary protocols that vendors chose to make semi-public.

---

From: Scott Brim <[email-masked]>
Date: Wed, 12 Apr 2000 12:13:06 -0400

>   solved in a technically sound fashion

Agreed completely ... but this still doesn't lead to your 
conclusion.  Suppose we had suppressed every kludge that's come up since 
we started working on a new Internet design as a group?  Let me see, ROAD 
gave their report, where they recommended CLNP, in Santa Fe, right?  That 
was (let me look at the back of my shirt a second ...) in 1991.  OK, OK, 
I'm being a bit extreme but the point is that just because something is 
architecturally bad doesn't mean you shouldn't do it, since these days it 
takes us years to make any architectural enhancements.  Peter Deutsch is 
right: let the work go forward and *in addition* be sure you document 
very well what its limitations are.  Stick that documentation in the same 
RFCs whenever possible.

...Scott

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Apr 2000 13:27:06 -0400

> takes us years to make any architectural enhancements.

perhaps architectural impurity alone shouldn't keep you from doing 
something, but the fact that something violates fundamental design 
assumptions should cause you to do some analysis and hard thinking
about the likely consequences of using them.  and if you are in the
business of selling boxes that violate the design assumptions you 
shouldn't misrepresent these to your customers.

most of these hacks can be employed in ways that are mostly harmless,
but knowing when they are harmless and when they will cause harm
can be quite difficult.  NATs seemed mostly harmless when they were 
first deployed; now they're a huge problem.

Keith

---

From: Scott Brim <[email-masked]>
Date: Wed, 12 Apr 2000 23:02:17 -0400

At 01:27 PM 4/12/00 -0400, Keith Moore wrote:
>about the likely consequences of using them.

Yes.  So why don't we have a new design which decouples all the meanings 
for an IP "address"?

>and if you are in the

Sounds like we have some agreement on the list.

>can be quite difficult.

There is precedent for the IESG getting draft authors to include caveats 
and limitations.

>NATs seemed mostly harmless when they were

Just wait until mobile IP-based "phones" take off!

...Scott

---

From: Fred Baker <[email-masked]>
Date: Mon, 17 Apr 2000 19:55:54 +0900

At 12:44 AM 4/11/00 -0700, Derrell D. Piper wrote:
>model where we allow for free exchange of ideas, even bad ones.

hear! hear!

>  I tend to

Well, that's one way to interpret it. I think I'd prefer the words of RFC 
2026, which imply that it is simply an idea, something being experimented 
with, and that the document represents a snapshot of the work at a 
particular point in time. We let time and experience tell us whether it is 
a good idea or a bad one, and if you want to participate in the experiment, 
you had best contact the experimenter, as things may have progressed since 
the document was published.

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Apr 2000 11:20:38 -0400

I think various people have made a good case for eventually publishing 
this particular document, once appropriate revisions have been made.

I'm very supportive of the notion of free exchange of ideas, even
through the RFC mechanism - with the understanding that:

- IETF and the RFC Editor have limited resources and cannot publish 
  everything that comes their way
- it's inappropriate to use Experimental or Informational publications in 
  the RFC series to promote or claim legitimacy for ideas that are embroynic 
  or experimental in nature, especially when those ideas are violations of 
  Internet standards.  there should be a clear distinction between
  "this is somebody's idea for an experiment" and "this is the sense
  of the Internet technical community"
- some experiments are better carried out under controlled conditions.

Keith

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2000 10:26:03 -0700

> - some experiments are better carried out under controlled conditions.

I'm in favor of the free exchange of ideas, with the caveat that
breaking existing standards or proposed standards must be addressed
prior to publication.

It is common for the RFC Editor to require augmentation of a proposed
informational RFC prior to publication. E.g., when the Security Issues
section has not been sufficiently developed.

There may be utility in considering a uniform "Standards Issues"
section. Just as the Security Issues must be sufficiently addressed when
an RFC affects or compromises security, the Standards Issues would be
necessary when an RFC affects or compromises current (STANDARD) or
'proposed' (DRAFT STANDARD, PROPOSED STANDARD) Internet standards.

The Standards Issues section could be required even if the RFC is
informational or experimental, as in the case of Security Issues. In
fact, I would prefer if it were always required, as in Sec Iss, even if
stating "this system is conformant with and does not affect any Internet
STANDARD, DRAFT STANDARD, or PROPOSED STANDARD as of this writing."

(e.g., as an update to RFC 2223)

Joe