Re: prohibiting RFC publication

[Keith Moore]

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

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

Re: prohibiting RFC publication

[Karl Auerbach]

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

Re: prohibiting RFC publication

[Peter Deutsch]

g'day,



Keith Moore wrote:

> 

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

> 

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



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.





> The trade press is quite good at fawning over vendors' products;

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

Re: prohibiting RFC publication

[Keith Moore]

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

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

Re: prohibiting RFC publication

[Martin J.G. Williams]

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

Keith Moore wrote:

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


begin:vcard 
n:Williams;Martin
tel;cell:+44 (0)7971 018413
tel;fax:+44 (0)7092 245455
tel;home:+44 (0)1672 514508
tel;work:+44 (0)7971 018413
x-mozilla-html:TRUE
adr:;;;Marlborough;;;United Kingdom
version:2.1
email;internet:[EMAIL PROTECTED]
title:UNIX Systems Consultant
fn:Martin Williams
end:vcard

Re: prohibiting RFC publication

[Pete Resnick]

On 4/8/00 at 5:40 PM -0400, Keith Moore wrote:

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

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.

>IMHO, we should base not publication decisions on the authors' employers.
>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.

>The trade press is quite good at fawning over vendors' products;
>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 
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Re: prohibiting RFC publication

[Vernon Schryver]

> From: Pete Resnick <[EMAIL PROTECTED]>

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


Do I understand correctly that you think that 
draft-terrell-ip-spec-ipv7-ipv8-addr-cls-02.txt
should have been published as an RFC?

Since technical merit is irrelevant, you must be in favor of
publishing draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-04.txt.
Do you prefer Informational or Experimental?


Vernon Schryver[EMAIL PROTECTED]

Re: prohibiting RFC publication

[Harald Tveit Alvestrand]

At 12:54 09.04.2000 -0500, Pete Resnick wrote:
>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.
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 PROTECTED]

Re: prohibiting RFC publication

[Pete Resnick]

On 4/9/00 at 12:24 PM -0600, Vernon Schryver wrote:

>>From: Pete Resnick <[EMAIL PROTECTED]>
>>
>>...He suggested that we allow them to document current practice.
>
>Do I understand correctly that you think that 
>draft-terrell-ip-spec-ipv7-ipv8-addr-cls-02.txt
>should have been published as an RFC?

Uh, no. I see no deployed support for this document and therefore see 
no relevance to the Internet community to have this document 
published. If noone on the Internet is doing it and I'm therefore not 
going to see these packets on the Internet, then it's not relevant to 
me as a member of the community, which is the only test for 
Informational or Experimental.

>Since technical merit is irrelevant, you must be in favor of 
>publishing draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-04.txt.

Did Eugene go and write some code I don't know about? Did you start 
routing this crap out on the net?

pr
-- 
Pete Resnick 
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Re: prohibiting RFC publication

[Pete Resnick]

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

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

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
-- 
Pete Resnick 
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Re: prohibiting RFC publication

[Harald Tveit Alvestrand]

At 13:51 09.04.2000 -0500, Pete Resnick wrote:
>On 4/9/00 at 8:21 PM +0200, Harald Tveit Alvestrand wrote:
>
>>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.
>
>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.

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

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[EMAIL PROTECTED]

Re: prohibiting RFC publication

[ned . freed]

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

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

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

Re: prohibiting RFC publication

[Vernon Schryver]

> From: Pete Resnick <[EMAIL PROTECTED]>

> >>...He suggested that we allow them to document current practice.


> >Do I understand correctly that you think that 
> >draft-terrell-ip-spec-ipv7-ipv8-addr-cls-02.txt
> >should have been published as an RFC?
>
> Uh, no. I see no deployed support for this document and therefore see 
> no relevance to the Internet community to have this document 
> published. If noone on the Internet is doing it and I'm therefore not 
> going to see these packets on the Internet, then it's not relevant to 
> me as a member of the community, which is the only test for 
> Informational or Experimental.

I guess your previous words were imprecise:

] Dave's message only said that technical merit has no bearing on 
] publication of Informational or Experimental RFCs.


> >Since technical merit is irrelevant, you must be in favor of 
> >publishing draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-04.txt.
>
> Did Eugene go and write some code I don't know about? Did you start 
> routing this crap out on the net?

Exactly how much currently deployed support is needed to make technical
merit irrelevant?  I don't understand any of the three series of documents
from E.Terrell well enough to say they don't concern currently deployed
protocols.  Do you?

Do you mean to require that every RFC describe a currently deployed
protocol?  That would imply that a lot of RFC's should not be and should
have been published.

Since draft-cerpa-necp-02.txt seems to be more a proposal to extend and
replace ICP than a description of current practice, and therefore you're
not likely to have seen relevant packets, have you also changed your mind
about whether draft-cerpa-necp-02.txt should be published as an RFC?

If whether something is or is likely to be deployed is the primary
criterion for whether an I-D should be advanced, then techical merit is
relevant, provided you agree that technical merit can still affects
deployment.  Furthermore, non-technical questions such as the wisdom of
sanctioning wiretapping can affect deployment, and so by your criterion
and contrary to your summary of Dave's (Crocker?), must affect publication.

...

It is at best naive to say that the employeers of authors of I-D's are
irrelevant or that big companies don't cause documents to be proposed
regardless of technical merit.  It is silly to claim that an I-D that
comes from big companies is necessarily worthy of publication, or that
big companies don't hire more than their share of induhviduals.  Which
companies are pushing something is primary in trade rag editorial policies
(as it should be), but not (yet?) the IETF's.
It would be silly to say it is not good to document the worst big company
ideas (e.g. Microsoft's PPP wreckage) if they're popular.
It would be at best ignorant of history to claim publication by a
consortium is sufficient to cause a protocol to be deployed or even
implemented.

Are USC, Radware, Network Appliance, Akamai, Foundry Networks, Inktomi,
Alteon, and Novell such a consortium?  I'm mystified by the dueling
implications that this group represents a commercially or intellectually
dominant slice of the industry or that they're trying to push a brand
new idea on the net.

The affliations listed for authors of any I-D only weakly disclose their
professional afflications.  Many people, particularly those who've been
around a while, write from other than their current employeer's or
clients's domains.  Anyone who wants to make employers relevant needs to
get the rules changed to require explicit disclosure, and to realize
that many of us would oppose such a rule.

None of that is to say that the IETF can no long have have an editorial
policy with some human wisdom.


Vernon Schryver[EMAIL PROTECTED]

Re: prohibiting RFC publication

[Pete Resnick]

On 4/9/00 at 12:39 PM -0800, [EMAIL PROTECTED] 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
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.

>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
-- 
Pete Resnick 
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Re: prohibiting RFC publication

[Dave Crocker]

At 12:54 PM 4/9/00 -0500, Pete Resnick wrote:
>Dave's message only said that technical merit has no bearing on 
>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/

=-=-=-=-=
Dave Crocker  <[EMAIL PROTECTED]>
Brandenburg Consulting  
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Re: prohibiting RFC publication

[Pete Resnick]

On 4/9/00 at 2:06 PM -0600, Vernon Schryver wrote:

>  > From: Pete Resnick <[EMAIL PROTECTED]>
>
>  > Uh, no. I see no deployed support for this document and therefore see
>  > no relevance to the Internet community to have this document
>  > published. If noone on the Internet is doing it and I'm therefore not
>  > going to see these packets on the Internet, then it's not relevant to
>  > me as a member of the community, which is the only test for
>  > Informational or Experimental.
>
>I guess your previous words were imprecise:
>
>] Dave's message only said that technical merit has no bearing on
>] publication of Informational or Experimental RFCs.

Perhaps they were. My only intention was to say that Dave claimed 
only "relevance/interest for the Internet community" and not 
"technical merit" as the criterion for publication has Informational 
or Experimental. Total lack of deployment (or in this case of 
draft-terrell-, any indication that there even will be deployment) 
makes it irrelevant/uninteresting and therefore unsuitable for 
publication. (This leaves aside the issue of editorial reasons for 
not publishing, which apply to draft-cerpa-, and probably apply to 
draft-terrell- as well.)

>  > >Since technical merit is irrelevant, you must be in favor of
>  > >publishing draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-04.txt.
>  >
>  > Did Eugene go and write some code I don't know about? Did you start
>  > routing this crap out on the net?
>
>Exactly how much currently deployed support is needed to make technical
>merit irrelevant?

Anywhere from zero to infinity. My argument is that technical merit 
is *always* irrelevant to suitability for publication as 
Informational or Experimental. The only criterion in the case of the 
Terrell documents is relevance/interest to the Internet community. 
None has (in those documents) been demonstrated.

>I don't understand any of the three series of documents from 
>E.Terrell well enough to say they don't concern currently deployed 
>protocols.  Do you?

I find our mutual lack of understanding (mine perhaps worse than 
your's), noone else's public claim of understanding, and the lack of 
documentation in these documents for where it is being used or what 
it effects a damn good indication of that lack of concern to 
currently deployed protocols.

>Do you mean to require that every RFC describe a currently deployed protocol?

No. Again, it's not deployment, but relevance/interest to the 
Internet community, that governs here. Sometimes that's squishy to 
get a hold of, I know, but I think we might both agree that Terrell 
doesn't have it.

>Since draft-cerpa-necp-02.txt seems to be more a proposal to extend and
>replace ICP than a description of current practice, and therefore you're
>not likely to have seen relevant packets, have you also changed your mind
>about whether draft-cerpa-necp-02.txt should be published as an RFC?

It depends. My understanding is that it is being deployed and has 
some high likelihood (given its proponents) of getting some wider 
spread use. If that understanding is incorrect and this protocol is 
heading for the dust bin, I would in fact change my mind about its 
suitability (on relevance grounds) for publication.

>If whether something is or is likely to be deployed is the primary
>criterion for whether an I-D should be advanced, then techical merit is
>relevant, provided you agree that technical merit can still affects
>deployment.

And here I was thinking that I was splitting hairs. Yes, technical 
merit may have impact on deployment, and therefore relevancy, and 
therefore worthiness of publication. But similarly I don't think that 
the earth's spinning is the cause of plant growth even though the 
earth's spinning does cause the sun to rise and the sun does cause 
plants to grow.

>It would be silly to say it is not good to document the worst big company
>ideas (e.g. Microsoft's PPP wreckage) if they're popular.

Absolutely. Exactly my point.

>It would be at best ignorant of history to claim publication by a
>consortium is sufficient to cause a protocol to be deployed or even
>implemented.
>
>Are USC, Radware, Network Appliance, Akamai, Foundry Networks, Inktomi,
>Alteon, and Novell such a consortium?  I'm mystified by the dueling
>implications that this group represents a commercially or intellectually
>dominant slice of the industry or that they're trying to push a brand
>new idea on the net.

Several members of that group do have an interesting dominance in an 
interesting slice of the industry which (given my minimal 
understanding of what the draft says) makes me believe that we are 
going to see these things widely enough deployed to be of interest, 
document or no document. Given that, the documentation seems like a 
good idea.

>Anyone who wants to make employers relevant...

Something of which I am not in favor. I was not saying that these 
folks employers are relevant to the publication decision; I was 
simply sa

Re: prohibiting RFC publication

[Pete Resnick]

[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

Re: prohibiting RFC publication

[Peter Deutsch in Mountain View]

g'day,

Dave Crocker wrote:
.  .  .

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

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

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

Re: prohibiting RFC publication

[Dave Crocker]

At 03:35 AM 4/9/00 -0400, Peter Deutsch in Mountain View wrote:
>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

we've done it more than once, before.


>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

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.


>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

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


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

"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/

=-=-=-=-=
Dave Crocker  <[EMAIL PROTECTED]>
Brandenburg Consulting  
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Re: prohibiting RFC publication

[ned . freed]

> On 4/9/00 at 12:39 PM -0800, [EMAIL PROTECTED] 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
> 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.

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

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.

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

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.

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

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

Re: prohibiting RFC publication

[Fred Baker]

At 03:51 PM 4/8/00 -0700, Karl Auerbach wrote:
>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.

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.

Re: prohibiting RFC publication

[Peter Deutsch in Mountain View]

g'day,

Fred Baker wrote:

> At 03:51 PM 4/8/00 -0700, Karl Auerbach wrote:
> >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.
>
> 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.

.  .  .

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

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

--


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

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

Re: prohibiting RFC publication

[Tripp Lilley]

On Sun, 9 Apr 2000, Peter Deutsch in Mountain View wrote:

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

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 PROTECTED]  *  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

Re: prohibiting RFC publication

[Valdis . Kletnieks]

On Sun, 09 Apr 2000 11:09:12 EDT, Peter Deutsch in Mountain View said:
> 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

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  for the
discussion why..."

What would it take to make it doable?

Valdis Kletnieks
Operating Systems Analyst
Virginia Tech

Re: prohibiting RFC publication

[Peter Deutsch in Mountain View]

g'day,

Tripp Lilley wrote:

> On Sun, 9 Apr 2000, Peter Deutsch in Mountain View wrote:
>
> > 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.
>
> 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...

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

--

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

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

Re: prohibiting RFC publication

[Dave Crocker]

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

=-=-=-=-=
Dave Crocker  <[EMAIL PROTECTED]>
Brandenburg Consulting  
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Re: prohibiting RFC publication

[Valdis . Kletnieks]

On Sun, 09 Apr 2000 23:01:38 PDT, Dave Crocker <[EMAIL PROTECTED]>  said:
> At 10:33 AM 4/9/00 -0400, Fred Baker wrote:
> >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.

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
Operating Systems Analyst
Virginia Tech

Re: prohibiting RFC publication

[RJ Atkinson]

At 16:09 09-04-00 , Peter Deutsch in Mountain View wrote:

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

 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 PROTECTED]

Re: prohibiting RFC publication

[John Stracke]

RJ Atkinson wrote:

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

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 PROTECTED]|  |
\===/

Re: prohibiting RFC publication

[Keith Moore]

> 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

Re: prohibiting RFC publication

[John Martin]

At 10:39 AM 10/04/00 -0400, Keith Moore wrote:
> > 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.

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

Re: prohibiting RFC publication

[Keith Moore]

> > > 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.
> 
> Let me jog your memory:

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

Re: prohibiting RFC publication

[John Martin]

At 02:21 PM 10/04/00 -0400, Keith Moore wrote:
> > > > 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.
> >
> > Let me jog your memory:
>
>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.

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

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

Re: prohibiting RFC publication

[Fred Baker]

At 02:38 AM 4/9/00 +0100, Martin J.G. Williams wrote:
>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.

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.