Subject: Re: prohibiting RFC publication

From: Vernon Schryver <[email-masked]>
Date: Sun, 9 Apr 2000 14:06:22 -0600 (MDT)

> From: Pete Resnick <[email-masked]>

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

---

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

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

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

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

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

>ideas (e.g. Microsoft's PPP wreckage) if they're popular.

Absolutely. Exactly my point.

>dominant slice of the industry or that they're trying to push a brand

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 saying that the names caused me to believe that deployment was 
likely and therefore that the document was of interest and hence 
worthy of publication.

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

Agreed.

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