On 4/9/00 at 2:06 PM -0600, Vernon Schryver wrote:
> From: Pete Resnick <presnick(_at_)QUALCOMM(_dot_)COM>
> 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 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:presnick(_at_)qualcomm(_dot_)com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102