From: Pete Resnick <presnick(_at_)QUALCOMM(_dot_)COM>
...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 vjs(_at_)rhyolite(_dot_)com