The following message is being returned unread.
The message is addressed properly but the addressee
has not accessed their mailbox for at least 4 days
******
****** Message To: ervjb(_at_)im(_dot_)erv(_dot_)ericsson(_dot_)se (Joakim
Bergstrom)
******
****** Unread Message Follows:
******
From: Doug(_dot_)Royer(_at_)Software(_dot_)com
Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt
Date: Sat, 9 Apr 2000 12:10:53 -0700
Reply-To: ietf(_at_)ietf(_dot_)org
Sender: droyer(_at_)ietf(_dot_)org
Message-ID: <38EF843D(_dot_)F1E4C791(_at_)Software(_dot_)com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686)
To: ietf(_at_)ietf(_dot_)org
CC: iesg(_at_)ietf(_dot_)org, rfc-ed(_at_)rfc-editor(_dot_)org
Peter Deutsch in Mountain View wrote:
[in part you said]
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!"
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?
TRUNCATED BY ERV_IMS.