![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.erv.ericsson.se (Joakim Bergstrom) ****** ****** Unread Message Follows: ****** From: Doug.Royer at Software.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.org Sender: droyer at ietf.org Message-ID: <38EF843D.F1E4C791 at Software.com> X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) To: ietf at ietf.org CC: iesg at ietf.org, rfc-ed at rfc-editor.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.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.