Re: FSF campaign against TLS-authz

[Dean Anderson]

Mr. Chiappa is disingenuous in his letter below.  While cogent arguments
are indeed appropriate during the development of a document, such
arguments are irrelevant during the consensus-determination or "Last
Call" process, which only is concerned with the consensus on approving
or disapproving the document.  The IETF is not considering altering the
TLS-authz document at present and Mr. Chiappa knows this.

Rather, the TLS-AUTHZ document is undergoing the IETF "Last Call"  
process. This document is an "individual submission". The TLS Working
Group declined to consider the document in its work.  In the case of
Individual Submissions, a "Last Call" is carried out on the
IETF@IETF.ORG list.  The IETF makes decisions by "consensus", which is
indicated by the "Last Call" process.  The "Last Call" process is where
members indicate support or non-support for the document being 'called'.  
In the case of the TLS-authz document, the last call extends for 4
weeks, from January 14, 2009 until February 11, 2009. More information
can be found by reading RFC2026 and associated RFCs on the IETF process.

Beside the patent-encumbrance, the TLS-authz document was subject to a
number of corrupt practices during its development.  The principle
author of the TLS-Authz document is Russ Housley, who is also Chair of
the IESG, which decides to issue consensus calls. Housley was paid by
Co-author Mark Brown, Redphone to produce the document and to file all
appropriate IETF documents. There is no dispute about payment, but the
amount has not been disclosed. I assert this payment is evidence that
Housley was corruptly paid to use his position at the IESG. Although
Housley knew of the patent, and apparently worked from patent documents,
Housley filed seven (7!) documents with the IETF falsely stating that
there were no undisclosed patents.  About 6 months after the IESG
approved the document the first time, the Patent Office disclosed the
existance of the patent application, and Brown/Redphone disclosed the
patent to the IETF. IESG member Sam Hartman (MIT, Kerberos project)
revoked the approval because of the deception.

At about the same time as the first Housley document falsely claiming
that there were no patents, Housley and the IESG silenced myself (Dean
Anderson) for objecting to other patent non-disclosures. The IESG
asserted that RFC3979, updating the IETF process to require patent
disclosures, did not apply.  The IESG (including Housley) also at this
time falsely reported a consensus in the "PR Action" to silence me and
another long time IETF participant, JFC Morfin.  The email messages
indicating consensus in my case were 15 against "PR Action", 2 for.  
Housely's participated corruptly in the false IESG statement on the PR
Action to be false, and Housley also knew that his document required
disclosure according to RFC3979.  These facts show that Housley and
other IESG members acted corruptly on multiple occasions.

I believe that Mr. Chiappa is well acquainted with these facts, which
are authenticated according to the standards set forth in Lorraine v.  
Markel on authenticating email evidence and electronic records as
evidence.  I cannot explain why Mr. Chiappa would suggest that people
should offer technical opinions when the process is seeking a go/no-go
indication of consensus. Mr Chiappa is a long time participant in the
IETF, and is familiar with the IETF processes.  It seems to me more
likely than not that Mr. Chiappa intends to mislead you.


Dean Anderson
A long time IETF participant,
President of the League for Programming Freedom
CEO of AV8 Internet, Inc





On Tue, 10 Feb 2009, Noel Chiappa wrote:

> Dear Mr. Brown:
> 
> I am writing to you (and CC'ing the boards members of the FSF, less one whose
> emailbox I couldn't easily locate) in an attempt to explain to you (and
> convince you) that 'mass mailings' to the IETF mailing list (or any IETF
> list) of the sort the FSF has now attempted twice (once back in October,
> 2007; and again this week) don't work, and are in fact, if anything,
> _counter-productive_ to the FSF's own goals!
> 
> The IETF 'members' (since IETF membership is rather a loose concept) are not
> impressed with numbers, but rather with cogent and well-reasoned arguments -
> and an argument becomes neither more cogent, nor more well-reasoned, by
> virtue of being repeated 100 times.
> 
> The analogy is not perfect, but you need to approach the IETF more like a
> court: a judge - at least, a good one - is not supposed to be influenced by
> the number of protestors on the steps of their court; rather, they are
> supposed to be influenced by the cogency of the arguments laid before them.
> Refiling the exact same amicus brief 100 times (or slightly reworded) isn't
> going to 

RE: Removal of IETF patent disclosures?

[Dean Anderson]

Jim has a fine idea in principle, but in practice defensive patents are
necessary. Keep in mind that the patent system is changing to
first-to-file, from first-to-invent.  Prior art is still not patentable,
but the patent law still gives significant advantages to patent holders
over public domain technology users.  In a patent suit, by law the
patent is to be presumed valid by the court.  A patent could be filed on
a novel improvement to the public domain technology, or on an
unpublished but otherwise public domain technology that either all but
obsoletes the PD work, or makes it somehow unusable. Without a defensive
patent, it is impossible to obtain a cross license scenario that
essentially negates the offensive patent.  The current law strongly
promotes patenting and disadvantages not patenting, which is an
unfortunate fact that cannot be ignored. 

[The LPF and other organizations are working in various ways to change
the patent law. There is a case that is going to be before the US
Supreme Court which could invalidate software as a category, but we
can't presume that case will be resolved in our favor. Though I might
add that the general trend in patent law for over 400 years has been to
restrict and reduce patenting, with some notable exceptions]

Its also entirely possible that a novel patent may be so useful as to
leave no choice but agreement to terms.  Consider for example the fast
fourier transform versus the fourier transform. Both do the same job at
the end, but the FFT is so much faster that it makes real-time fourier
analysis possible where it wouldn't even be doable with the unmodified
fourier transform.  There would be no choice but to accept the license
terms on such a novel and incredibly useful invention.

So the problem can't be removed, entirely.

I think the basic procedure of RFC3979 is exactly right: Require
disclosure, consider non-patented alternatives, and make an informed
decision about the costs and benefits giving preference to unencumbered
solutions where possible.  The problems we have had with this procedure
is that authors haven't disclosed, that working group chairs have
suppressed the discussion of non-patented alternatives, or chairs have
entirely disregarded RFC3979 altogether asserting that non-technical
details are irrelevant or a 'rat-hole'.

I think we need to consider the ways that people have tried to
circumvent the procedures required by RFC3979, and to either close the
loopholes if any, or impose penalties on the failure to comply with
RFC3979.  Most troubling is that IETF managers aren't complying with
RFC3979 in WG discussions, and/or aren't requiring authors to comply
with RFC3979. Altering any part of RFC3979 or altering required patent,
copyright or trademark terms won't change non-compliance. So I think the
only alternative, for managers anyway, is some sort of penalty, and
perhaps better education about the policies of the IETF that WG chairs
have to enforce.  Compliance has to start with the WG chairs.


--Dean


On Fri, 15 Aug 2008, Bound, Jim wrote:

> Have read all this thus far and complex problem/discussion and good to
> have here.  I know this is heresy to many vendors but I believe the
> IETF should not permit at some date in the future any part of a
> specification to have any IPR from any vendor that is accountable to
> patents or royalties.  In simpler terms anything we develop in the
> IETF is public domain in the legal context, and we do not use any
> vendor patents for any of our work.  Just remove the problem entirely.
> As specs are implemented IPR added value can be done by vendors and
> inventors to improve and customize their product or invention to
> attain larger ROI in the market competitively, but the base core IETF
> specs are patent, royalty, and IPR free to all worldwide regardless of
> geography or governmental boundaries.
> 
> Disclaimer: This is my personal opinion and does not reflect the view
> of the company I work for at all.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Removal of IETF patent disclosures?

[Dean Anderson]

On Wed, 13 Aug 2008, Simon Josefsson wrote:

> Harald Alvestrand <[EMAIL PROTECTED]> writes:
> 
> > Simon Josefsson wrote:
> >> Harald Alvestrand <[EMAIL PROTECTED]> writes:
> >>   
> >>
> >> At least one of the removed patent licenses promises to make available
> >> patent licenses on fair, reasonable, reciprocal and non-discriminatory
> >> terms.  It seems unfortunate that IETF allows organizations to file such
> >> claims and permits them be removed later, presumably when the
> >> organization change their minds.
> > Agreed in principle.
> >
> > On the other hand (trying to play devil's advocate), if the promise
> > was made by someone in the organization that did not have authority to
> > commit the organization to that statement, I could see why the
> > responsible persons for that organization would want the original
> > statement made invisible, so as to not have to eternally go around and
> > explain the situation.

Removal by the IETF seems to be agreement to release the promisor from
the agreement.  The IETF shouldn't do this since the agreement was a
condition on which the WG made its decision. 

In the case that the organization doesn't have authority to make the
promise, it shouldn't make false promises and is responsible for
whatever consequences befall it as a result. These consequences are not
the concern of the IETF.  All the IETF should do is allow the company to
update the disclosures to state that it can't honor the commitment it
made previously. This is consistent with 'record is history' view.

> What if the request to remove the disclosure was filed by someone who
> isn't authorized to do it?

Good point.

> If the IETF removes patent disclosures, I believe the IETF will find
> itself in the position of evaluating the _correctness_ of patent related
> claims.  This seems like the wrong approach.
> 
> One way to mitigate your problem without getting into evaluating
> correctness or removing disclosures would be to collect all patent
> disclosures updates on the same page as the original patent disclosure,
> and sort the entries in reverse calendar order.  Then anyone can add
> note that a disclosure below was filed without authority.  That
> disclosure can be evaluated for correctness the same way that other
> disclosures can be evaluated.  Removing disclosures makes it impossible
> for IETF participants to evaluate the contents for themselves.

This is how I thought it worked now, perhaps with the exception of
sorting by date. I think they are sorted by number (or maybe this is
just the natural order), and higher numbers generally have later dates.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: several messages

[Dean Anderson]

> > How can a description of how to use a technology infringe on a patent?
>
> A standard isn't merely a description, as in a magazine article, but
> also represents an industry agreement on the definition of a product. A
> draft or WG could encourage persons to violate a patent, which is
> indirect infringement.  A draft or WG could define a product that is a
> contributory infringement on a patent.  The working group must take care
> not to do these things.

As I said before, I agree with Atty Rosen's position and I hope it will
prevail, I have run into lawyers who assert that source code
distribution does infringe a patent.

In the source code distribution examples that I know of, the
distributors were very clear about the existance of patents in certain
jurisdictions, and therefore seemed to have prudently (I would hope
sufficiently prudently)  avoided indirect infringement.  But it also
seems indisputable that there are indeed scenarios of imprudent actions
which could invoke indirect or contributory infringement.

There doesn't seem to be any basis for the assertion that it is entirely
impossible for the IETF to ever engage in indirect or contributory
infringement, no matter what actions it undertakes or how imprudent
those actions are.  So I think the IETF must define policies so to avoid
the scenarios of imprudent actions.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Failing of IPR Filing Page when makling updates in re LTANS and other filings.

[Dean Anderson]

On Tue, 12 Aug 2008, Scott Brim wrote:

> On 8/12/08 12:02 PM, TS Glassey allegedly wrote:
> > As to the IPR Page - it does not
> > allow for updates of already filed IPR Statement's to include new IETF
> > documents which violate the patent rights after the posting of the IPR
> > Notice.
> 
> How can a description of how to use a technology infringe on a patent?

A standard isn't merely a description, as in a magazine article, but
also represents an industry agreement on the definition of a product. A
draft or WG could encourage persons to violate a patent, which is
indirect infringement.  A draft or WG could define a product that is a
contributory infringement on a patent.  The working group must take care
not to do these things.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Failing of IPR Filing Page when makling updates in re LTANS andother filings.

[Dean Anderson]

On Tue, 12 Aug 2008, Lawrence Rosen wrote:

> Scott Brim asked:
> > How can a description of how to use a technology infringe on a patent?
> 
> It can't. :-)

This isn't an entirely accurate and I'm always worried about inaccurate
assertions from a lawyer. I think that one must be completely forthright
about the possibilities.  While I agree with Atty Rosen's position and I
hope it will prevail, I have run into lawyers who assert that source
code distribution does infringe a patent.  There is no case law that I
know of to back that up on patents and source code, but recent copyright
cases have taken a very broad view of what constitutes copyright
infringement, and this might signal a broader view on what constitutes
patent infringement.

The IETF must consider indirect infringement, where one merely
encourages others to infringe, and contributory infringement, where the
only use of a non-infringing device or method is to infringe a patent.  
I think the correct answer here is "An IETF could possibly infringe on a
patent".

> But neither does IETF have any responsibility to parse and evaluate any of
> the frivolous claims made in IPR disclosures. Responding to loose IPR claims
> in public here only gives them undeserved credence. People and companies
> will file what IPR disclosures they will; other people will evaluate their
> importance when it becomes important to do so.

I don't know what a "loose IPR claim" is.  However, it seems incumbent
on the WG chairs and the IESG to evaluate the IPR claims made IPR
disclosures to the same extent as anyone else. The WG Chairs and the
IESG have a duty of due diligence to ensure that IETF documents don't
indirectly infringe on patents nor engage in contributory infringement.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Blue Sheet Change Proposal

[Dean Anderson]

Sorry, missed this. Inline:

On Tue, 15 Apr 2008, TS Glassey wrote:

> Dean -
> - Original Message - 
> From: "Dean Anderson" <[EMAIL PROTECTED]>
> To: "Wes Beebee (wbeebee)" <[EMAIL PROTECTED]>
> Cc: "IETF Discussion" 
> Sent: Wednesday, April 09, 2008 10:28 PM
> Subject: RE: Blue Sheet Change Proposal
> 
> 
> > Speaking as president of the LPF; not a lawyer but a knowledgeable
> > layman.
> >
> > I think you are correct that the patent issue is a red herring.
> 
> No its not.
> 
> > The
> > patentee has the _right_ (not the obligation) to keep patent application
> > contents secret.
> 
> Sure but not when they submit that IP to others to get their 'contributed 
> work product' added into that IP.
> 
> So in response to your commentary, "No Dean they do not because that would 
> constitute an act of fraud by the party Submaringing the Patent in that they 
> are 'extorting through an apparent agreement as to joint ownership of the 
> IP' to that newly developed IP. But further since the patent filing itself 
> is now public there is no concern for public disclosure.

I'm not following you here.  I can see that someone could conduct the
fraud/extortion as you describe (indeed, someone already has), but I
don't follow why that has any bearing on whether they use blue sheets to
identify attendance at a meeting.  The blue sheet doesn't prove or
disprove a fraud/extortion charge.

> > Failure to keep the secret merely causes them to lose the _right_ to
> > trade secret status.
> 
> Yes but the public disclosure of an IP issue starts certain clocks
> running and this is a the real issue. What that means is that the IETF
> cannot process anything with Trade-Secret Status.

Err, what clocks do mean? Seriously, the only clock I can think of is
the patent clock, which starts on the filing date and has nothing to do
with when there was public disclosure, unless the public disclosure is
that someone _else_ previously invented and published the technology.  
The public disclosure that I (self just for example) invented a
technology I'm patenting has no bearing on any clock I can think of.
Though its probably not a good idea to do that before one gets to the
patent office, since under the new rules, someone else could beat you to
the patent office with your own invention. That's not a clock, but a
race to file.  But the second after the filing is made, one can disclose
as widely as the please.  Its only the patent office that will not make
any disclosures for 18 months; The patent office only keeps the secret
to protect the filer's right to a trade secret if the patent is quickly
rejected or withdrawn.

But I agree the IETF cannot process anything with trade secret status. I
just disagree this has anything to do with clocks. Trade secrets never
expire, by the way. The reason the IETF cannot process trade secrets is
that the secret must be disclosed in the draft, and then being
disclosed, it is no longer secret.  The IETF has no NDA and cannot
accept drafts under NDA. Everything submitted to the IETF is publicly
disclosed thereby ending the possibility of trade secret status, unless
perhaps it was improperly submitted to the IETF. (BTW, the possibility
of unauthorized disclosure is yet another reason for the IETF to get
written, signed transfers, as you advocated previously.)

> > They might want that status in the event the patent application is
> > rejected.
> 
> But that wouldnt have anything to do with the issue of whether the
> failure to disclose IP ownership defrauds the other participants in an
> IP effort of their rights to the derivative's and fruit of their own
> labor.

Agreed.  But one can't defraud via the IETF using a trade secret.  Such
misconduct is only possible with an undisclosed patent. My point is,
there is no justification in not disclosing the patent; since anything
proposed to the IETF cannot be a trade secret.

> > They lose the trade secret right if the patent is granted, when the
> > patent application is published 18 months after filing, or if they
> > disclose the information publicly, or if someone _independently_
> > rediscovers the secret. Obviously, if they are trying to standardize
> > the patent, they can't have trade-secret status anyway: the "secret"
> > is publicly disclosed in the draft text. So the issue of disclosure
> > is moot.
> >
> > I have no opinion on whether blue sheet changes are a good idea or a bad
> > idea for other reasons.  Generally, though, my experience and view is
> > that truth and disclosure is always a good thing for the public
> > interest.
> >
> > --Dean
> >
> > On Wed, 9 Apr 

RE: Blue Sheet Change Proposal

[Dean Anderson]

Speaking as president of the LPF; not a lawyer but a knowledgeable 
layman.

I think you are correct that the patent issue is a red herring. The
patentee has the _right_ (not the obligation) to keep patent application
contents secret. Failure to keep the secret merely causes them to lose
the _right_ to trade secret status.  They might want that status in the
event the patent application is rejected.  They lose the trade secret
right if the patent is granted, when the patent application is published
18 months after filing, or if they disclose the information publicly, or
if someone _independently_ rediscovers the secret. Obviously, if they
are trying to standardize the patent, they can't have trade-secret
status anyway: the "secret" is publicly disclosed in the draft text.  
So the issue of disclosure is moot.

I have no opinion on whether blue sheet changes are a good idea or a bad
idea for other reasons.  Generally, though, my experience and view is
that truth and disclosure is always a good thing for the public
interest.

--Dean

On Wed, 9 Apr 2008, Wes Beebee (wbeebee) wrote:

> Regarding the legal issues - if the sessions are broadcast over the
> Internet, and freely downloadable (w/o specifying or tracking who was
> downloading them), how can you be certain that someone was NOT aware
> of certain IPR?  Also, if someone was in the room, how can you be
> certain they WERE aware of certain IPR?  The only thing that the IETF
> can say is that every contribution to the IETF is considered to be
> publically disclosed, and this is indeed what the Note Well says.
> 
> It seems to me that the IPR concerns are a red herring.
> 
> - Wes
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Eric Burger
> Sent: Thursday, April 03, 2008 8:07 PM
> To: IETF Discussion
> Subject: Re: Blue Sheet Change Proposal 
> 
> Two purposes for Blue Sheets:
> 
> 1. Redundant data entry: Quite often, the name is illegible, while the
> e-mail is legible.  We don't care about the e-mail address, what we
> really care about is who was there.  IMHO, this is the important use for
> capturing the e-mail address.
> 
> 2. Legal issues: When the inevitable patent dispute happens, we WILL get
> served to report who was in the room when a particular subject was
> discussed.  Other standards bodies have had this problem, if we haven't
> had it, it means our time is near :-(
> 
> 
> On 4/3/08 4:22 PM, "Mark Andrews" <[EMAIL PROTECTED]> wrote:
> 
> > 
> > 
> >> All,
> >> 
> >> We are considering changing the meeting Blue Sheet by eliminating the
> 
> >> need to enter an email address to avoid spam concerns.
> >> 
> >> Is there any good reason to retain that info bit?
> >> 
> >> Ray
> >> ___
> >> IETF mailing list
> >> IETF@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ietf
> > 
> > It's is the only unique token on the blue sheets.  This
> > assumes no shared email accounts which is a pretty reasonable
> > assumption in this case.
> > 
> > Mark
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
> > ___
> > IETF mailing list
> > IETF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> > 
> 
> 
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> ___
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Possible RFC 3683 PR-action

[Dean Anderson]

As one of the 2 PR-action'ed persons, let me respond to these 
assertions.

I was subject of a PR-Action in fall of 2005 because I did three things:

1) I asked for honesty in the sources of claims in the controverial 
spamops document.  The discredited source was SORBS, which falsely 
claims address blocks used by Av8 Internet (130.105/16 and 198.3.136/21) 
are hijacked. They have done this since 2003, and know of the mistake. 
SORBS is connected to Paul Vixie and Dave Rand.

2) I asserted that RFC 3979 applied to DNS drafts, which had not made
the proper disclosures required under RFC3979. Steven Bellovin (then
chair of the IPR Working Group falsely stated that RFC3979 wasn't the
policy of the IETF. ISOC Atty Contreras later refuted Bellovin's false
claim. I was right. The drafts have not made the proper disclosures.  
This activity is similar to the deception by Russ Housley with the
TLS-AUTHZ document. (Housley also voted on my PR-Action)

3) I attempted to discuss problems with Stateful Anycast Stability on
DNSOP. Even though DNSOP was the proper forum for this discussion, I was
bluntly told to drop the subject by then Area Director David Kessens.  
Kessens was associated with Paul Vixie and ISC through several
connections. Vixie was advocating Anycast, and stood to lose money if
problems were revealed. Since then, experimental data confirms the 
problems with Stateful Anycast.


I've been vindicated on all three issues of the PR-Action. There was no 
misconduct on my part.


Since then, I have been banned from the GROW, IPR, and DNSEXT Working 
Groups:

-- I was banned from GROW for opposing draft-ietf-grow-anycast (Kessens)  
that implied that stateful anycast was stable, and stated that per
packet load balancing (PPLB) was pathological.  My opposition was steam
rolled. As Sam Hartman wrote in his evaluation record:

  I believe that the IESG did not follow a process consistent with how
  we handle other documents and that the divergences from our normal
  process created an unacceptably closed process.  As such, I am
  abstaining on this document as I cannot support its publication under
  the process that was used.

  The area director described the process used as "hard ball."  He said
  that because of the history of the document he was pushing back
  against changes both from the IESG and late last call comments more so
  than usual.  By history, I suspect that he meant both the fact that
  this document has already been subject to an appeal and the fact that
  the document has been under development for a long time.  I think that
  the area director chose to play hard enough ball that the process can
  no longer be considered open and that the IESG erred in supporting
  this process and approving the document.

-- I was banned from IPR Working group. I am president of the LPF, an
anti-patent organization founded by Richard Stallman. The LPF represents
the views of many GNU supporters and many famous people in computer
science.  I was banned for working to fix the problems that enabled Russ
Housley to deceive the IETF on IPR disclosure, yet receive no penalty.

-- I was banned from the DNSEXT Working Group (namedroppers) which I
have participated in since about 1990.  I was banned because I opposed
the author assigned to a revived axfr-clarify draft. This draft was
involved in a prior scam by Paul Vixie et al 'clarifying' the AXFR
protocol in 2002.  The draft proponents claimed the draft had no wire
protocol changes. However, it was discovered by Dr. Bernstein that the
draft did include protocol changes. It was also discovered that BIND had
already implemented changed protocol with detection for the old
protocol. This scam was discovered and originally opposed by Dr. Dan
Bernstein, the author of a major DNS server implementation. In 2002,
Bernstein's email was blocked, subjected to forged unsubscriptions, etc.  
The draft was dead until recently, when Vixie and affiliates revived the
document.  I objected to assigning the document to authors affiliated
with the previous abuse of Bernstein.


None of these represent any sort of obstruction to legitimate work.

Paul Vixie seems to be the center of the abuse against me, using his
resources at NANOG, ISOC, and ARIN, and SORBS to interfere with my
business and to promote his own economic interests. Others also have
economic motives to harm me (e.g. Housley to prevent his being held
accountable for patent disclosure violations.)

These efforts at improper and unjustifiable censorship are presently the
subject of legal contacts between my lawyer and their lawyers. These
efforts to censor persons for economic purposes contradict the bylaws
and charters of each of the organizations, and violate US laws.  It will
not stand. SORBS operator Matthew Sullivan has stated his intent to
cause AV8 Internet to spend money to sue people who would lose but have
no money to pay damages.

But I do agree that the efforts at censorship are indeed a waste of
time.  How

Re: Response to the Appeal by JFC Morfin dated 2006-02-17 - 2006-05-17.

[Dean Anderson]

On Wed, 12 Jul 2006, Joe Abley wrote:

>
> On 12-Jul-2006, at 15:45, Dean Anderson wrote:
>
> >> I make no claims that anycast is definitively safe for protocols and
> >> services which don't involve trivial, stateless transactions.
> >
> > Really?  That's a big change.
>
> Really? There has been text to that effect in the draft since -00.

Searching draft 4 just now, I can find no instances of the words "safe",
"trivial", or "stateless" in the draft.  So, I suppose, quite literally,
it is true that you didn't make such a claim in the __draft__.  But you
and your group did make these assurances elsewhere.  This is sort of
legalistically dishonest: Rather like an unscrupulous used car dealer
claiming he never promised the car would start in the sales contract,
even though he did say so on the lot.

I did notice a number of "bait and switch" between draft 02 and 03
(which I noted to you and the IESG).  In those cases, you quietly
weakened the statements made.  For example:

===
Date: Thu, 29 Jun 2006 13:50:42 -0400 (EDT)
From: Dean Anderson <[EMAIL PROTECTED]>
To: Joe Abley <[EMAIL PROTECTED]>
Cc: Sam Hartman <[EMAIL PROTECTED]>, iesg@ietf.org
Subject: Re: grow: draft-ietf-grow-anycast-pre04

[...]

On the issue of "minor changes":

This is a major change:

-   discrete locations.  The service provided by each node is consistent
-   regardless of the particular node chosen by the routing system to
-   handle a particular request.
+   discrete locations.  The service provided by each node is generally
+   consistent regardless of the particular node chosen by the routing
+   system to handle a particular request (although some services may
+   benefit from deliberate differences in the behaviours of individual
+   nodes, in order to facilitate locality-specific behaviour; see
+   Section 4.6).

The change from "is consistent" to "is generally consistent" is a
significant difference. To be a safe stateful operation, "is consistent"
is required behavior.  You assured people that it is safe, and then you
"bait and switched" the text to weaken the official statements in spite
of your stronger assurances. This is a nefarious change.

[...]
===



> >> For example, there are people using anycast to distribute services
> >> using very long-held sessions (e.g. internet radio, HTTP) with
> >> great success, and to ignore their experience and success would be
> >> idiotic and arbitrary.
> >
> > There are no such http services using stateful anycast (though this
> > is the first I've heard of internet radio being anycast---I'd have
> > to question what protocol he means. I think RTP streams may be
> > stateless, but I'm not certain).  The http protocol is definitely
> > stateful, however.
> 
> http://www.computerworld.co.nz/news.nsf/NL/54FCC3B9D0B8BB96CC25702F00740446

This link is a June 30, 2005 announcement from Radio New Zealand.  It
makes no mention of the protocol they plan to use. It does make mention
of anycast root DNS servers, as though that adds credibility to their
scheme. There is no data that this scheme is stateful nor, if it is
actually stateful, that it is safe.  Nor this announcement mean they are
having any success with this scheme over a period of time.  I don't know
if they are still using this scheme, nor if they even implemented the
intentions announced June 30, 2005.  This is a rather weak reference.

> http://www.nanog.org/mtg-0606/levine.html

First, check the date: June, 2006. Not very long time to check their
data, and __after__ you efforts began.  You've been promoting this
scheme since 2002, saying it was stable then, with years of commercial
use. 

Second, you seem to miss a lot: (page 5)
  "State is accomplished with custom hardware."

As much as they bluster about doing "TCP anycast", it is not actually
TCP Anycast.  They have some special hardware doing state behind the
scenes.  They don't give many details, though.  But that is different
from what we are discussing. You've proposed no custom hardware.  You
and they are essentially doing something that akin to confusing the
Mount Everest ride at Disneyland to climbing Mount Everest, because they
gave you a "I conquered Mount Everest" sticker.

Third, they are doing Porn video streaming, so customers probably don't
complain too much about frequent failures.

Fourth, it is my understanding that Real Media and MS Media player
streams are RTP, not TCP.  They are not real clear on those points. 

Fifth, their performance data indicated that over a long period of time,
they never had 100% availability. This is

Re: Response to the Appeal by JFC Morfin dated 2006-02-17 - 2006-05-17.

[Dean Anderson]

On Tue, 11 Jul 2006, Joe Abley wrote:

> 
> On 11-Jul-2006, at 05:32, Dean Anderson wrote:
> 
> > BTW, the IESG response implied that the allegations of scientific  
> > fraud
> > were (somehow) not substantiated.
> 
> I haven't seen these specific complaints voiced with this clarity  
> before (maybe I overlooked some mail). Perhaps this is a good  
> opportunity to dispense some additional perspective.

Abley's claims are again not true.  Abley's claim of not having seen the
"specific complaints with this clarity", is entirely false.  While the
information I just presented may be somewhat new to the main IETF list,
there was nothing new that hasn't been discussed on DNSOP and elsewhere,
with Mr. Abley, and the IESG. Abley and the IESG are well aware of the
precise details, in greater detail and clarity than the summary I just
presented. Abley is very well aware of these issues, in even greater
detail. 

Indeed, most of my recent message was copied from a message I sent to
DNSOP, which Abley certainly saw.

Abley has almost certainly also seen the DNSMON source code. But few
others have seen the DNSMON source code. (more below)

> > [...]
> >
> > What the full community may not know, [but ISC, RIPE, Joe Abley, David
> > Kessens, Brian Carpenter, and the IESG do know], is that the report
> > claiming that stateful anycast was stable was fabricated, and that no
> > stateful testing was performed by the DNSMON program.  Contrary to
> > assurances given by Karrenberg, there is no data which supports the
> > notion that stateful DNS Anycast is safe, nor any data that disputes
> > data and assertions that show DNS Anycast is unsafe.
> 
> I don't believe the fact that DNSMON sends all its probe queries  
> using UDP transport is news to anybody. It's certainly not a secret,  
> as you have aptly illustrated by looking at the source code, which is  
> freely available.

The code is copyrighted free, but is not freely available. RIPE does not
distribute the DNSMON code to the general public. The source code I
posted is not accessible by the general public.  When RIPE gave it to
me, they asked me not to redistribute it---but they indicated an
intention to give away the code, and my limited quote is fair use.

> It is possible to identify oscillations in node selection from
> individual probes without using TCP transport.

The oscillation issue is orthogonal and unrelated to the anycast issue.  
While both Verisign may have been originally looking to find oscillation
issues when the data was collected, the implications of the findings to
stateful anycast was an unexpected discovery. The implications of this
discovery were made clear by Verisign.

> However, from what I could tell from Daniel's presentation, the fact  
> that UDP transport was used by DNSMON was a simple result of the fact  
> that UDP measurement data is what was already stored, and hence that  
> was the data that was available for analysis.

This is false or complete nonsense. There is no prior data "already
stored".  The data was collected by DNSMON.  A tool like DNSMON could
collect stateful data. But DNSMON didn't do that.

Karrenberg didn't report that he only measured stateless UDP data.  
Karrenberg presented his results to refute specific claims of stateful
(TCP) problems raised by Anderson and Verisign.  If Karrenberg had
reported the truth at the time, no one would have treated his data as
having any relevance to stateful anycast.  

An honest person in Karrenberg's position would have reported that his 
data had no relevance to the TCP question. But Karrenberg didn't do what 
an honest researcher would have done. 

> I can find no example of Daniel (or anybody else) claiming that  
> DNSMON in general, or the data which formed the basis of Daniel's  
> NANOG presentation in particular, resulted from DNS queries made  
> using TCP transport. The only person suggesting otherwise is you.

This is also not true. While Karrenberg didn't explicitly say that he
made TCP queries (indeed Karrenberg didn't say anything at all about
this very important detail--this is a dishonest omission), Karrenberg
__did__ say was that his results refuted the "false rumor" that anycast
was somehow unsafe--this is a dishonest statement.  An honest statement
would have said that his data had no bearing on the question of whether
stateful anycast was safe.  

> Surely this whole issue is a red herring.

We have heard nothing but false assurances for several years.  "Surely"  
is definitely not "certainly".

> > Now put this in context along with repeated assertions from Joe Abley
> > and others associated with ISC and RIPE that stateful anycast is safe
> > and even non-controversial.  Mo

Re: Response to the Appeal by JFC Morfin dated 2006-02-17 - 2006-05-17.

[Dean Anderson]

BTW, the IESG response implied that the allegations of scientific fraud
were (somehow) not substantiated. Following is a summary of the
allegations, and after that is the DNSMON source code for sending
packets. The source code plainly constructs a UDP (and only UDP) packet.

---

What the full community may not know, [but ISC, RIPE, Joe Abley, David
Kessens, Brian Carpenter, and the IESG do know], is that the report
claiming that stateful anycast was stable was fabricated, and that no
stateful testing was performed by the DNSMON program.  Contrary to
assurances given by Karrenberg, there is no data which supports the
notion that stateful DNS Anycast is safe, nor any data that disputes
data and assertions that show DNS Anycast is unsafe.

The notion of a safe stateful anycast operation as asserted by Daniel
Karrenberg (http://www.nanog.org/mtg-0505/pdf/karrenberg.pdf) has now
been discredited. Karrenberg's document misled people to believe that
stateful anycast was safe, when in fact Karrenberg didn't perform any
stateful testing whatsoever.

The controversy began in 2002 with announcements by RIPE NCC and ISC 
(operators of K-root and F-root, respectively) to sell Anycast instances 
of K and F servers.  

In October, 2004, Mark Kosters reports on data gathered at J root:

http://www.nanog.org/mtg-0410/pdf/kosters.pdf

+ Expected to see a saw tooth distribution .
  instead have a noisy distribution in many cases
+ Does not affect UDP
+ DO NOT RUN Anycast with Stateful Transport

http://www.rssac.org/meetings/04-08/2004WashDC.html
  At the November 7th, 2004 RSSAC meeting, Kosters repeats warning on
stateful DNS Anycast, but is disputed by Karrenberg. In May 2005, after
one day after suppressing discussion on Nanog by Anderson, Karrenberg
unqualified assurance that Anycast is safe, and please "do not to spread
this false rumor" http://www.nanog.org/mtg-0505/pdf/karrenberg.pdf

It is later found (January, 2006)  [reported to IESG March, 2006] that
Karrenberg has done no stateful testing whatsoever, and that Karrenberg
did not reveal that his testing was only for stateless DNS, and
therefore had no relevance to the safety of stateful DNS Anycast.  [To
put this in context of current news, this is the difference between
creating a stem cell line, and creating a new stem cell line.  It was a
scientific fraud to describe the former as the latter. A one-word
difference]

This discovery was only made when Anderson examined the source code to
the DNSMON program written by Karrenberg to conduct this testing.

Now put this in context along with repeated assertions from Joe Abley
and others associated with ISC and RIPE that stateful anycast is safe
and even non-controversial.  More history is found at 
http://www.av8.net/IETF-watch/DNSRootAnycast/History.html


--  

copyright from main.c:

/* 
 * Copyright (c) 2003, 2004RIPE Network Coordination Center
 * Mark Santcroos <[EMAIL PROTECTED]>
 *
 * All Rights Reserved
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation for any purpose and without fee is hereby granted,
 * provided that the above copyright notice appear in all copies and that
 * both that copyright notice and this permission notice appear in
 * supporting documentation, and that the name of the author not be
 * used in advertising or publicity pertaining to distribution of the
 * software without specific, written prior permission.
 *
 * THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
 * ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS; IN NO EVENT SHALL
 * AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
 * DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
 * AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 *
 * $Id: main.c,v 1.12 2005/05/23 12:35:43 kevin Exp $
 *
 */


sendpacket function from sending_process.c:

/*
 *  Sendpacket
 *  takes a buffer and send it out to socket
 */
struct timeval
sendpacket(char *packet, struct server list[], int entry)
{
int ret;
int size;
struct ip *iphdr;
struct udphdr *udphdr;
char *sndbuf = (char *)malloc(512);
int udplen;
int iplen;
int datalen;
struct sockaddr_in saddr;
struct timeval send_time;

datalen = list[entry].size;

iplen = sizeof(struct ip);
udplen = sizeof(struct udphdr);

iphdr = (struct ip *) sndbuf;
udphdr = (struct udphdr *) (sndbuf + sizeof(struct ip));

/* copy to the actual send buffer */
memcpy(sndbuf+iplen+udplen, packet, datalen);

iphdr->ip_v = IPVERSION;
iphdr->ip_hl=sizeof(struct ip) >> 2;
iphdr->ip_id = 0;  /* 0 means kernel set appropriate value */
iphdr->ip_len = sizeof(struct ip) + sizeof(struct udphdr) + datalen;
iphdr->ip_tos = 0;
iphdr->ip_off = 0;
   

Re: Response to the Appeal by JFC Morfin dated 2006-02-17 - 2006-05-17.

[Dean Anderson]

On Tue, 11 Jul 2006, Jefsey Morfin wrote:

> Two appeals have been responded today. A first reading shows an
> impressive distance between the response and the matter of the appeal.

There were only two outstanding appeals, the other one being from me. I
can't see the response to JFC on the IESG site, but JFC has certainly
understated the response I did see. "Impressive distance", indeed.

While some parts of my June Appeal required some knowledge of DNS and
Anycast to understand, the impropriety of the IESG response can be
understood by just about anyone:  The third issue they addressed was the
failure of IESG members accused of wrongdoing to recuse themselves. The
IESG held they do not have to recuse themselves. But it is
well-established notion of professional ethics that one cannot sit in
judgement of one's own actions. That is a blatant conflict of interest.  
Just about anyone can understand that.

But apparently the IESG--as a whole--cannot understand this fundamental
principle of ethics that requires recusal for conflict of interest.  
Even though the IESG as a whole was reminded of this through repeated
requests for the officials (Kessens and Carpenter) to recuse themselves
and halt repeated instances of improper interference. This ethical
dysfunction discredits the IESG and its members as a competent body to
make fair and ethical judgements.  And this dysfunction discredits the
IESG and members as an activity of the ISOC subject to the ISOC bylaws
which require high standards of ethical behavior.  The ethics of recusal
are pretty straightforward in this instance.  The issues are now more
serious: Rather than merely two offending officials, there is now (at
least) a majority of the IESG involved.  This is now a very serious
breach of public integrity.

The other elements of the IESG decision are likewise not credible.  
This decision will also be appealed to the IAB.  Other organizations
will also have to be notified.  I anticipate that honest, ethical
members of the IESG will shortly resign or have already resigned to
protect their reputations. I will give a few days for these notices to
circulate.  The remaining members will be named as offending
participants in further complaints about this impropriety.

Dean Anderson
Av8 Internet, Inc



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Best practice for data encoding?

[Dean Anderson]

Some ASN.1 compilers have had some bugs, however, this does not to indicate that
ASN.1 is bug prone. Just the opposite: Once you have a secure compiler, you can
be assured that certain kinds of bugs don't exist.

Further, in the few cases of the bugs that were found, once the bug is fixed in
the ASN.1 compiler, the application just needs to be relinked (or given new
shared library) with the new generated runtime.  And any other application which
used a vulnerable runtime, but for which the vulnerability was unknown, is also
fixed.  So, users of compiled runtime benefit from usage experience by the
entire group.

Building tools that make trustable runtimes is a good approach to certain
classes of security problems. You can't get this by hand written protocol
encode/decode layers.

--Dean

On Mon, 5 Jun 2006, Iljitsch van Beijnum wrote:

> I was wondering:
> 
> What is considered best practice for encoding data in protocols  
> within the IETF's purview?
> 
> Traditionally, many protocols use text but obviously this doesn't  
> really work for protocols that carry a lot of data, because text  
> lacks structure so it's hard to parse. XML and the like are text- 
> based and structured, but take huge amounts of code and processing  
> time to parse (especially on embedded CPUs that lack the more  
> advanced branch prediction available in the fastest desktop and  
> server CPUs). Then there is the ASN.1 route, but as we can see with  
> SNMP, this also requires lots of code and is very (security) bug  
> prone. Many protocols use "hand crafted" binary formats, which has  
> the advantage that the format can be tailored to the application but  
> it requires custom code for every protocol and it's hard to get  
> right, especially the simplicity/extendability tradeoff.
> 
> The ideal way to encode data would be a standard that requires  
> relatively little code to implement, makes for small files/packets  
> that are fast to process but remains reasonably extensible.
> 
> So, any thoughts? Binary XML, maybe?
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Fwd: Can the USA welcome IETF (was: Last Call under RFC 3683 concerning Dean Anderson (reissued))

[Dean Anderson]

nclusive".

> All of us have the "right" to be here - Dean can still "lurk", if 
> the PR-Action goes against him.  We don't, however, have the "right" to 
> be disruptive.  

I haven't prevented any work from being done, by any group. Indeed missing from
the PR Action, in fact, is a prima facie case: RFC3683 speaks of a Denial of
Service:  that the IETF cannot get work done if the subject is allowed to post. 
 

There has been no denial of service.  The IETF has not been prevented from doing
anything whatsoever. 

But in fact, the IETF has responsibilities and obligations, which is why there
is a complaint process. A process to which Anderson has availed himself.

Your argument, and the PR Action, comes down to a retaliation for using the 
complaint process, and for discussing ON-Topic issues on a Working Group 
chartered to discuss the very subject.

> The IETF, on the other hand, like any organism, has the "right" to defend
> itself from attack.

Another false premise. First, the IETF hasn't been attacked. The employees of
the IETF are misusing their authority in the IETF to the conduct attacks against
someone who has registered legitimate and substantiated criticism against a root
server operator.

What Kessens has done is try to cover up this criticism. I am not the only
person to make this criticism, and all those making this criticism have been
viciously attacked.  And the theoretical and laboratory evidence happens to show
that Dean Anderson, Dr. Bernstein, and Iljitch Van Beijnum are right in this
criticism.

I have been attacked, and I have rightfully made complaints about these attacks.

You are trying to assert an argument that unless we (Anderson, etc) agree that
their criticism of ISC Anycast Extension is wrong, then somehow we are
asserting that "we are always right".  This is a fallacious argument.

> And, there is a PR-Action in progress because a particular volunteer's actions
> can reasonably be interpreted as an attack on the IETF.

Neither RFC3683, nor any RFC, allows for retaliation for criticism of the IETF.

All organizations are subject to criticism.

> We _volunteered_ to be here, and most of us either want to help, or selfishly
> use the IETF for our own education (personally, I'm in both groups).  And, if
> the group arrives at a consensus that any particular volunteer is more trouble
> than he's worth, then the IETF will decline to accept that volunteer's input
> in the future.  I think that offering to call in lawyers is just more
> demonstration that Dean will never be willing to let others work without
> interference.

I think you've missed the point of what "open, fair, and inclusive" means.

> IESG, please add the referenced "threat to call in lawyers" message 
> to the PR-action case against Dean Anderson.

I got the impression that you are student.  I'm wondering, have you taken an
ethics course yet?  Do you understand what it means to avail oneself of one's
rights?  Lawyers are sometimes necessary to do that.  That is why they call them
"rights"; because you have a "right" to them.

I'm also wondering if you've had to write research papers for any of your
classes. What happens to you if you fabricate citations or material in your
papers?  At most colleges and universities, this is considered academic
dishonesty, and grounds for expulsion. It is treated as a very serious offense.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Correcting errors about IETF [Re: Fwd: Can the USA welcome IETF]

[Dean Anderson]

On Tue, 18 Oct 2005, JFC (Jefsey) Morfin wrote:

> 1. ISOC says: "ISOC is the organizational home of the Internet 
> Engineering Task Force, the Internet Architecture Board, the Internet 
> Engineering Steering Group, and the Internet Research Task Force. 
> Specific activities include support for the RFC Editor Function of the IETF."
> 2. you say "IETF is not a subsidiary of ISOC and is not incorporated".

These actually can both be true.  A "subsidiary" is usually a corporation owned
by another corporation. The IETF is not a separate legal entity from the ISOC.

Though, just checking Black's Law Dictionary, "subsidiary" means:

  "Under another's control.  Usually short for "subsidiary corporation".



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Fwd: Can the USA welcome IETF

[Dean Anderson]

This doesn't come close to representing what has transpired.

Try this on for size, in the same childish genre as the other:

There are two clubs.  The first club is like a gang of kids.  Not very formal.
Just a group, really. Kind of a gang.  Not terribly educated, but tight. The
second club is more adult-like. Velvet smoking jackets: "How is Sir today?",
"How is Madam today?". "How does the gentleman vote on the issue of
draft-widget-factorizing?"

There are also two sets of rules. The grownup rules, and the club rules.
Actually, there are three sets because there are two clubs, but we can ignore
this.

At the first club, there were a bunch of bullies. The person didn't know right
away that they were bullies [well actually, he did know they were bullies from
many years before, but had forgotten that--not a grudgeholder himself]. The
bullies said they could do whatever they wanted and no rules applied to them.
This person merely told them at the that they were wrong: there were rules that
applied to them.  He quoted the rules.  The bullies said that they were bullies,
and that no one would go against them.  The bullies shake down the other kids
for their lunch money, by saying they sell vinegar.  They also put up signs
saying "no vinegar sales", while helping the real vinegar vendors hide from the
vinegar police. Of course, they don't help the vinegar vendors for free: They
charge for list-washing.  They go around boasting a lot about looking for
grownups, but when someone stands up to them, the first thing they say is that
if they go to the grownups, they'll be blocked forever.

Two of the members of the first club repeatedly abused the person, punching and
hitting. So the person invoked the grownup rules. So the grownups came, and
found the person following the rules, and that other the two members were
breaking the rules. One of the bad kids had to be sent home by his boss, because
even after he was told to stop, he continued in spite of what his employer said
to do. This made the bad kid really angry. Six years later, he's still mad. The
other bullies weren't happy either. You can't be a bully if you let someone get
away with going against a bully. So the first club said he couldn't be a member
anymore, out of spite. They don't like people who invoke the grownup rules or go
against the bullies. And about the one person who really pissed them off, they
he stole IP addresses. The IP address claim is not credible because the
companies to which the IP addresses belong to still exist and function. But the 
spite of bullies is not to be underestimated.

So later, at a posher, sort-of-grownup club, the same group of bullies is
looking for revenge on the person who got their two bully-friends into trouble
by having grownup rules enforced on them.  They engage in name-calling, personal
attacks, and generally school-yard behavior. This behavior is largely ignored by
the person, save to occasionally register a complaint with the club leaders
about the behavior.  But the club leaders don't dare go against the bullies.
Indeed, some of the bullies have become club leaders.  One of those bullies
changes his official club email address to say to any customers of the one
person, that his IP addresses are stolen.

Once again, the person has caught the bullies cheating, breaking the rules, and
doing all sorts of reprehensible things. Bullies will be bullies.  They try to
intimidate and threaten the person. They threaten anyone who speaks up for the
person.  So the bullies say "We can't stand this person anymore. We want him
out." One bully announces publicly that hs is searching for ways to get rid of
the person according to the club rules. One might guess that they demanded
removal and were turned down on account of the rules.  So the bullies have
fabricated charges against the person to have him removed from the sort-of-grown
up club.  Ironically, the bullies use complaints about the bullies, charging
those complaints are attacks on bullies.  Poor bullies.

But, unlike the first club, this second club has some grownup rules.  It seems
unlikely that the club can do this act, and still obey the grownup rules. There 
are consequences for violating the grownup rules. 

Once again, the bullies pretend that there are no rules to govern their
behavior. But if anything is ever true, this is: The grownups never side with
bullies.  This grownup club has a requirement to act in the interest of the 
public, and to be fair, open, and inclusive.  Fairness requires some sort of 
fair prosecution devoid of conflict of interest, and a fair opportunity of 
defense against the charges.  Moreover, all this has to be in the public 
interest, not in the interest of a group of bullies.


--Dean

On Mon, 17 Oct 2005 [EMAIL PROTECTED] wrote:

> Lets look at this as what it may appear to be.  No references to anyone
> living or deceased is intended in the following story.
> 
> Disclaimer - I have been personally named by Mr. An

Re: Fwd: Can the USA welcome IETF

[Dean Anderson]

Scott, your presumption of being above the law and able to act without any
regard or recognition of responsibility and obligation is exactly how
organizations get into legal trouble.

The IETF is an activity of the ISOC. The ISOC is incorporated in the US, has a
corporate charter, bylaws, and various duties imposed on it.  It is subject to
US law, and it seems, Massachussets state law.  We'll see.

Your frustration is familiar: I've seen it before as ignored legal realities are
imposed on those who presume they don't exist. The experiences of Chris Neill**
and Alif Terranson come to mind.  


Eduardo: Don't take these things personally. When faced with reprehensible
behavior: "speak to the jury".  And thanks for speaking up.

--Dean

[** BTW, Chris Neill just recently sent me a nasty gram, 6 years later. For
those of you who don't know the story (most of you who aren't Nanog members),
Neill was fired from Verio in 1999 after Nanog members encouraged him to abuse
our relays. This was at a time when Nanog members claimed that no laws applied
to the Internet. I was banned from Nanog for saying with substantiating
citations that this view is wrong.  I was vindicated by all accounts except
those of hard-core Nanog members like Dave Crocker. Neill's firing not entirely
Nanog's fault, but it partly is. Neill continued the abuse after being told to
quit by his management. Neill posted a diatribe on Spam-l after he was fired,
blaming me. This is just one of the reasons Nanog members make personal attacks
on me]


On Mon, 17 Oct 2005, Scott W Brim wrote:

> OK, this is getting silly.  Have you ever been to an IETF meeting?
> You should understand the IETF culture before presuming to advise
> governments.  The IETF is not a puppet of any government, and even if
> it were, that has nothing to do with RFC3683.
> 
> The Last Call was reissued precisely to support the rights of the
> "accused" (your word).  Because it was issued on the wrong list, some
> people might not have seen it.  It was given *more* exposure time, not
> less, in order to be *more* fair, not less.  Your implications that
> the "rulers" and their lackeys are gaming the system to take away
> rights is completely absurd.
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Fwd: Can the USA welcome IETF (was: Last Call under RFC 3683 concerning Dean Anderson (reissued))

[Dean Anderson]

This is not my response to the PR Action.

Mr. Mendez raises a valid point of jurisprudence regarding the fairness of this
PR-Action.  The point he raises is called "double jeopardy". The US recognizes
this principle in criminal court cases. This is not a criminal court case, but
it is similar in that rights of a defendant are in jeopardy.

The IETF, as part of the ISOC, has an explicitly stated fiduciary duty (a legal
obligation) to act in the interest of the public trust, (IE the public
interest), and to be "fair, open, and inclusive".  The ISOC (and thus the IETF) 
 
is incorporated in the US, and subject to US law.

Mr. Kessens is plainly conflicted, being a party to some of the issues which are
the subject of the PR-Action.  In other words, it is as though the prosecutor is
prosecuting an alleged crime against the prosecutor.  Suppose you trespass in
the prosecutor's yard. That prosecutor cannot file charges, it would be an
unethical abuse of office. But this is what Kessens did. And it is not the first
abuse of his office.

My research so far indicates that there are other unreported conflicts and
irregularities in the PR-Actions against Dean Anderson.

For the time being, I am withholding release of my response pending advice of my
attorney.

--Dean


On Mon, 17 Oct 2005, Eduardo Mendez wrote:

> I corrected error (underlined). Apologies.
> 
> -- Forwarded message --
> From: Eduardo Mendez <[EMAIL PROTECTED]>
> Date: 17-oct-2005 16:27
> Subject: Re: Can the USA welcome IETF (was: Last Call under RFC 3683
> concerning Dean Anderson (reissued))
> To: David Kessens <[EMAIL PROTECTED]>
> 
> 
> 2005/10/17, David Kessens <[EMAIL PROTECTED]>:
> > I don't appreciate your suggestion that there could be another motive
> > for reissuing the Last Call as the explanation in the note that
> > accompanied the reissued Last Call message was quite clear in it's
> > motivation.
> 
> Mr. David,
> I am sorry you do not appreciate.
> This is may be we do not share the same culture.
> Every culture is to be respected.
> 
> For your information. There are other countries when the procescutor
> makes such a mistake it kils the procescution. This protects the
> rights of the accused person.
> 
> What you did increases the rights of the accusator.
> You also are the victim, a law maker, a judge, and an appeal judge.
> There are countries where you must ask another AD to procescute.
> 
> There are countries where one is not allowed to say:
>  "Mr. X did wrong".
> One must say:
> "Mr. X seems to have done wrong".
> Or Mr. X can sue you and win.
> Everyone is innocent; except when the Judge said he is not.
> And there is no appeal.
> ---
> Sorry: I mean. "and you stay innoncent until the end of the appeal".
> 
> So, sorry if I hurt you.
> 
> Eduardo Mendez
> 
> > The Last Call was reissued since the first message was inadvertently
> > send to the the IETF announce list (where all other IETF Last Call
> > messages are send) instead of the IETF discussion list as specified by
> > RFC 3683. It seemed prudent to reset the Last Call timer to avoid any
> > conflicts on whether the Last Call would have been of sufficient
> > duration.
> 
> NB. You created a conflict on duration: it is too long.
> "Sufficient" is a word like if you had made your mind as a Juge.
> In true Justice lawyers would use it.
> Your rights can be defended only if you defend the rights of everyone?
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Anyone not in favor of a PR-Action against Jefsey Morfin

[Dean Anderson]

This is a discussion of administrative IETF business. Further, this is a serious
IETF matter. It properly belongs on the IETF main list.

You are free to create whatever personal lists you like, however, your list does
not represent IETF business, nor is it required to comply with any IETF standard
for participation.

--Dean

On Thu, 6 Oct 2005, Harald Tveit Alvestrand wrote:

> 
> 
> --On torsdag, oktober 06, 2005 02:59:49 -0400 John Leslie <[EMAIL PROTECTED]> 
> wrote:
> 
> >But, much though I'd be happy to live without Jefsey's posts, I
> > firmly believe that the PR-Action Harald proposes is a bad tactic,
> > and is poorly supported. I won't go into detail on this list. (It is
> > turning into a Denial-of-Service attack to _this_ list: perhaps
> > someone could divert the discussion elsewhere?)
> 
> your wish is my command :-)
> 
> The list "pr-action-talk" 
>  is awaiting 
> subscriptions!
> 
> Note: This is not in ANY way, shape or form an IETF list. I've created it, 
> I'm responsible for it, I'll shut it down if I feel like it.
> 
> But if Jefsey posts to it, I'm more likely to append his messages to the 
> FAQ file for the list than to ban them
> 
> (In my time as IETF chair, I was sometimes chastised for creating new 
> mailing lists at the drop of a hat, scattering official IETF business over 
> multiple lists that nobody ever could remember or find again. But now I'm 
> no longer IETF chair, so what I do with mailing lists is entirely my own 
> business. Official IETF business goes on IETF lists. This isn't one.)
> 
> (btw:
> number of postings with "PR-Action" in subject over the last 30 days: 41
> Number of postings with "UN plan" in subject: 57
> The UN has the power :-)
> 
> 
>Harald
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: IETF Last Call under RFC 3683 concerning Dean Anderson

[Dean Anderson]

I just checked the archives, and I see no original message on this topic.

Who initiated this Last Call?

The quoted message below from David Kessens does not seem to appear in the IETF
archive on October 7th.

I will create a webpage to respond to these false charges made against me under
http://www.av8.net/IETF-Watch/DavidKessens.html. This page should be available
by Monday, October 17th.  This response page is necessary and does not limit my
rights to purse the IETF and its officials in Court. Posting this page does not
imply any agreement, settlement, or choice of forum. I do not agree to any legal
settlement of any legal issue related to this matter, or related to the IETF, 
or 
related to officials of the IETF.

Dean Anderson
Av8 Internet, Inc


On Fri, 7 Oct 2005, Marshall Eubanks wrote:

> As much as I hate to, I have to support this based on the personal attacks
> I have read.
> 
> Regards
> Marshall Eubanks
> 
> On Fri, 07 Oct 2005 15:22:10 -0400
>  David Kessens <[EMAIL PROTECTED]> wrote:
> > The IESG received a request from Dave Crocker to take action under RFC
> > 3683 against Dean Anderson. Mr Crocker alleged disruption of the IETF
> > and DNSEXT lists and provided sample emails [4]. In addition, Dean
> > Anderson was recently warned by David Kessens [2], Operations &
> > Management Area Director, that a recent posting on the DNSOP working
> > group mail list was not acceptable after which he responded to the
> > DNSOP list by sending a brief message but with a similar accusation as
> > the one he was warned not to repeat.
> > 
> > While these messages alone might not suffice to justify action, Mr
> > Anderson has repeatedly posted, before and since, on these and other
> > IETF lists, messages that refer offensively to individuals or
> > organizations [1]. For a small sample of such messages, we refer to
> > the urls provided at the bottom of this Last Call message.
> > 
> > Many of them are off topic for the IETF, since the IETF can only
> > produce general technical recommendations for operators; it may not
> > criticise individual operators or tell them how to conduct their
> > business. We wish to make it clear that quarrels and disagreements
> > between software suppliers, operators and the like have no place in
> > the IETF and must be discussed and settled elsewhere.
> > 
> > Although sometimes Mr Anderson's messages address technical topics,
> > this is not enough to excuse the frequent offensiveness. He has been
> > warned to desist from offensive postings multiple times and has often
> > ignored such warnings [2,3].
> > 
> > The IESG therefore proposes to ban Dean Anderson from posting to the
> > main IETF list and to authorize all WG chairs to ban him from posting
> > to their working group lists. This message calls for comments on this
> > proposed action from the IETF, which should be sent to iesg@ietf.org
> > (or ietf@ietf.org) by 06 November 2005.
> > 
> > For the IESG,
> > 
> > David Kessens
> > Operations & Management Area Director
> > ---
> > 
> > Please see below for a sample of abusive behavior on maillists:
> > 
> > [1] Personal attack on Bill Strahm and alleges that Rob Austein
> > defames av8 Internet:
> > 
> > http://www1.ietf.org/mail-archive/web/ietf/current/msg37889.html
> > 
> > IETF management is accused of harassment and it is stated that
> > Stephen Sprunk is untrustworthy (end of message). In addition, the
> > message implies that David Kessens is the responsible Area
> > Director for dnsext, while this working group is part of the INT area:
> > 
> > http://www1.ietf.org/mail-archive/web/ietf/current/msg37931.html
> > 
> > Dean uses a very unpleasant tone to make it clear to David Kessens
> > that he doesn't agree with him and adds another attack by twisting
> > Steven Bellovin's own words and smearing Steven Bellovin's
> > reputation:
> > 
> > http://www1.ietf.org/mail-archive/web/ietf/current/msg37873.html
> > 
> > (Dean apperently referred to:
> > http://www1.ietf.org/mail-archive/web/ietf/current/msg37557.html)
> > 
> > 
> > Please see below for a sample of messages that ignore requests to Dean
> > Anderson to stop his disruptive behavior:
> > 
> > [2] Example of an attack on a well known organization on the dnsop list:
> > 
> > Dean Anderson attacks a well known root name server operator and
> > talks about uncontrolled corruption in the IETF:
> > 
> > http://darkwing.uoregon.edu/~llynch/dnsop/msg03551.html
> > 
> > Message by David Kessens to Dea

Re: Petition to the IESG for a PR-action against Jefsey Morfin posted

[Dean Anderson]

On Mon, 3 Oct 2005, Peter Constable wrote:

> > From: Dean Anderson <[EMAIL PROTECTED]>
> 
> > In the message Randy concludes that
> > 
> > "If anyone wishes to raise an issue, (s)he should do on on the working
> > group
> > mailing list by posting a message detailing the concern and, if
> > possible,
> > supplying proposed replacement text."
> > 
> > But it would seem that Morfin did just exactly that, with a lot of
> > supporting documentation.  It seems to me that Randy Presuhn just doesn't
> > want to address the concerns raised, nor does he want anyone _else_ to
> > address the concerns.
> 
> Not the case at all. Everyone else in the WG that was voicing pertinent
> concerns was doing so (i) in a reasonably clear manner that all could
> understand (ii) on the list and (iii) whenever appropriate supplying
> specific suggested revisions to the text. There were occasions on which
> Mr. Morfin made clear and pertinent comments on the list, and when he
> did they were welcomed. On some occasions, he suggested specific text,
> and when he did those suggestions were considered openly. On several
> occasions, however, he posted messages that tended toward being opaque
> or overly long or both, and far more often than not he didn't give
> concrete suggestions for specific textual changes. Within some of those
> often-lengthy posts he pointed to documents he had placed on other
> sites, and there were many things that led others in the WG to believe
> that the material on those other sites was supporting his entirely
> different agenda rather than the work of the WG. Perhaps some of that
> content was useful to the work of the WG, but by that point there was
> already a high level of frustration among many WG members, such that
> there really was an onus on him to demonstrate that it would be
> worthwhile to spend the time going off to review them. This he did not
> do.

In this case, I reviewed the documents supplied by Morfin, and did not find it
particularly onerous to do so.  

You seem to be criticizing him for making the effort to show that in fact his 
points were worthwile. A catch-22.

As for concrete suggestions, in one of the six messages I reviewed was a
suggestion to remove certain text from the draft.  This too, was criticized for
"failing to provide alternate text".  That is a frivolous criticism. 

> > In fact, Randy actually admits in the same message to having advised others
> > _not_ to review Morfin's objections.  That seems to be contrary to Last
> > Call.
> 
> I'm not aware of any occasion on which Randy advised members of the WG
> not to review Last Call comments that had be submitted in the expected
> manner on the WG or IETF lists.

You can look at the message I quoted. Particularly this passage by Randy:

 ...I posted a message to ietf at ietf.org suggesting that reviewers' time
 would be better spent on the working group documents that are under last
 call, rather than trying to make sense of the polemic on that website.


> > The sample, limited as it is, seems to confirm an unjustifiable personal
> > attack on Morfin based, it seems, on personal dislike and intolerance for
> > his English language skills
> 
> IMO your limited sample is not sufficient to support your point. 

Yes, it is only six messages. But significantly, in that six there is one
plainly inappropriate response from the WG Chair.  It seems that Morfin is being
mistreated.  I'd say that you now have an obligation to show that this
mistreatment is somehow justified, before I review dozens more messages by
Morfin.  It seems not to be justified.

> If it were representative, then one would expect that several others
> monitoring the WG discussions would be providing that confirmation. I have not
> seen any indication of that happening.

This is a false premise.  First, silence does not indicate agreement.  But even
if everyone on the WG did want him removed, their reasons must be due to actual
and unreasonable misbehavior that prevents the working group from functioning.  
Personal dislike, even if unanimous, is insufficient.  No serious engineering
can be done as a personal popularity contest.

--Dean

--
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Petition to the IESG for a PR-action against Jefsey Morfin posted

[Dean Anderson]

On Mon, 3 Oct 2005, Brian E Carpenter wrote:

> Dean Anderson wrote:
> 
> > ...  It may also be
> > time to make a formal complaint to the ISOC about the pattern of 
> > misbehavior by
> > the IETF leadership in several related areas including abuse of Dean 
> > Anderson,
> > Dan Bernstein, Nick Staff, Jefsey Morfin, and others.
> 
> I reckon it's because we so much dislike Nick Staff that the IESG
> appointed him as one of our external scribes. (The first set of
> scribe notes will be showing up sometime soon, btw.)

So what is the relevance of this to anything?  Indeed, I think Nick will be an
excellent scribe.  But appointing him scribe doesn't mean he hasn't been abused
as part of a pattern of abuse.  I didn't say you disliked Nick Staff. I said you
abused him. Sometimes these are different. When you offensively disrespect the
people you like, then you plainly have a problem with interpersonal
interactions.

Carpenter offers to (barely) chastise Alvestrand:
http://www1.ietf.org/mail-archive/web/ietf/current/msg35904.html

Nick Staff asks publicly to rule against Alvestrand: Calls Alvestrands attack 
"obnoxious, childish, and pubescent", notes double standard by Carpenter:
http://www1.ietf.org/mail-archive/web/ietf/current/msg35938.html

Nick Staff says TIME OUT: 
http://www1.ietf.org/mail-archive/web/ietf/current/msg35957.html

Brian Carpenter tells Nick to pound sand:
http://www1.ietf.org/mail-archive/web/ietf/current/msg35969.html

Nick tells Brian how he feels about that: (Nick is plainly offended)
http://www1.ietf.org/mail-archive/web/ietf/current/msg35993.html

Carpenter offered to barely discpline Alvestrand, and even though that offer was
accepted publicly by Nick, and offlist by Anderson, Carpenter backed out anyway,
and told Nick Staff (and Anderson) to pound sand, describing Nick's view as
"annoying and irrelevant".

Nick is just trying to make peace. He didn't deserve that.  What's more
sickening is that Carpenter still apparently doesn't think he did anything
offensive to Nick.

Carpenter also doesn't find it "annoying or irrelevant" to chastise others:
[e.g.  http://www1.ietf.org/mail-archive/web/ietf/current/msg35780.html] This is
part of a pattern of abuse and acceptance of abuse by Carpenter.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   







___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Petition to the IESG for a PR-action against Jefsey Morfin posted

[Dean Anderson]

I have to plead mostly ignorance of the technical details of LTRU issues.  
However, I just went to the LTRU archive and started with July 15th:
Specifically, I went to the archive page, and picked page 40:
http://www1.ietf.org/mail-archive/web/ltru/current/mail40.html. This link
rotates as new pages are added to the archive. At the moment I selected it, it
pointed to July 15th, 2005.

>From there, I reviewed 6 messages from Jefsey, and one message from Randy
Presuhn in response to Morfin. I also reviewed several messages from Doug
Ewell.

On this day, it would seem to be a debate about Last Call issues, requirements
and objections to a draft in Last Call, and a few other issues. It did not seem
very unusual traffic.  Morfin's messages are not rude or combative.  Morfin 
articulates his objections to a new draft.

Morfin created a webpage to explain his objections. His messages seem to be
respectful, rational, and well-documented.  The website he created was likewise
rational, respectful, and well-documented, and even easy to understand to
non-LTRU experts, such as myself.

Randy's message
[http://www1.ietf.org/mail-archive/web/ltru/current/msg02836.html] is rather
more disturbing. Randy (WG Chair) claims that Jefsey's wording is "deceptive"  
and his website is "misleadingly named", as if the _name_ of the website should
be relevant.  Randy is not specific as to what it is that is "deceptive".  This
is nothing more than an ad hominem attack. This seems to be offensively
inappropriate behavior by the WG chair.  


In the message Randy concludes that 

"If anyone wishes to raise an issue, (s)he should do on on the working group
mailing list by posting a message detailing the concern and, if possible,
supplying proposed replacement text."

But it would seem that Morfin did just exactly that, with a lot of supporting
documentation.  It seems to me that Randy Presuhn just doesn't want to address
the concerns raised, nor does he want anyone _else_ to address the concerns. In
fact, Randy actually admits in the same message to having advised others _not_
to review Morfin's objections.  That seems to be contrary to Last Call.

Doug Ewell's several messages on this day were mostly in support of Randy
Presuhn's views.

So, I find the LTRU WG chairs response much more disturbing than anything I
found in the small sample of Morfins messages.  Indeed, the RFC3066.org website
seems to be sensible and rfc3066.org/review.htm raises what seem to be very good
points. I would argue that the WG Chair's role is to facilitate discussion. If
there is a language barrier, the WG Chair should try to bridge that barrier.

While I found it at times difficult to follow Morfins writing because he is a
non-native English speaker, I found that his sentences were in fact sensible.  
Morfin compensates for his language issues by restating his points, which while,
wordy, helps with extracting the meaning. That it is hard to communicate due to
language problems is not reason for criticism. It seems to me from this sample
(and his web pages), that it is difficult to argue that Morfin isn't making a
positive, and rational contribution, and if he represents a minority view, his
views are still fairly well documented and not unreasonable.  I saw nothing in
this sample that would seem to support Doug Ewell's view below.

The sample, limited as it is, seems to confirm an unjustifiable personal attack
on Morfin based, it seems, on personal dislike and intolerance for his English
language skills

--Dean



On Sun, 2 Oct 2005, Doug Ewell wrote:

> I wish that everyone who trivializes Harald's proposal as a matter of
> "personal dislike" or "silencing anyone with a different opinion" could
> have experienced life in the LTRU Working Group for the past 6 months,
> where list members were constantly insulted for being Americans or for
> being employed by large companies, where "resolved" and out-of-scope
> issues were raised over and over again, and where list members became
> wary of posting anything at all, for fear their words would be twisted
> to mean something completely different.  It would not have been
> tolerated in any face-to-face working environment.
> 
> --
> Doug Ewell
> Fullerton, California
> http://users.adelphia.net/~dewell/
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Petition to the IESG for a PR-action against Jefsey Morfin posted

[Dean Anderson]

On Fri, 30 Sep 2005, Michael Froomkin - U.Miami School of Law wrote:

> 
> 
> No first amendment issues are implicated here.  The first amendment only 
> protects US persons (citizens & residents) against actions by the US 
> government.  Both sides of that equation are absent here.
> 
> This is private action against a private party.  It may implicate the 
> moral principles of freedom of expression but these are not ordinarily 
> actionable either in the US or elsewhere.  YMMV of course.

I think that the legal issues involve defamation and disparagement, and perhaps
others (e.g. corporate bylaw violations---otherwise known as "failure to follow
ones own written rules"), and other duties and obligations required of
corporations.  Last I checked, the IETF is an activity of the ISOC, which is
incorporated in the US.  The IETF has a nearly 2 million dollar budget, and its
bank account isn't in the name of an individual, it is in the name of a US
corporation.

But I think that Jefsey should formally counter-complain that the PR-action is a
personal attack based on personal dislike.  I think the next step is to appeal
the IESG action to the IAB, and if that fails, then to the ISOC.  It may also be
time to make a formal complaint to the ISOC about the pattern of misbehavior by
the IETF leadership in several related areas including abuse of Dean Anderson,
Dan Bernstein, Nick Staff, Jefsey Morfin, and others.

> Please note that this comment expresses no opinion on the merits of the ban.
> 
> 
> 
> On Fri, 30 Sep 2005 [EMAIL PROTECTED] wrote:
> 
> [much edited]
> 
> > Note that the whole issue of list ban is treading on first amendment 
> > grounds 
> > in a way that could end up in court.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: delegating (portions of) ietf list disciplinary process (fwd)

[Dean Anderson]

" and "one proven act" are more clearly in
> the "there exists" sense. 

If that were the case, then the disputed statement needs to have factual,
truthful support. If Ted wants to discuss the truth of the original draft
statement, he would need to find a source of fact that supports that statement. 
 
Instead, he is trying to argue that the people making the statement aren't
people who "lie repeatedly".  He does this by lying himself.

But the discussion between Anderson, Carpenter, Tso, and Martinez was not about
the truth of the original statement. The discussion was about whether the fact
that a _source_ of a statement is a 3-time court-proven liar is relevant to any
discussion.  It is relevant.  Tso never directly addresses this question, but 
tries to defend the liars, and to assert that their statements are merely 
coincidental.

Tso tries to dismiss this a being merely coincidental:

http://www.av8.net/IETF-watch/Tso-summary.html Tso writes:

"some people in the IETF that have made assertions that also happen to
align with statements made by various extreme elements of the
anti-SPAM crowd"

None of this is merely coincidental, as Tso tries to assert. These elements were
cited as the source for the draft statements.  The draft statements were false,
and the cited sources of the false facts are known to be repeat liars and/or
associates of repeat court-proven liars. That fact is plainly relevant to the
technical merits of the draft.

> (And if I were in Ted's shoes at that time, I probably would've ignored the
> implied suggestion that I go hunt through your web site or use Google to try
> to find the information I had asked you to provide on the other people your
> use of the plural implies.)

You can ignore it, but then you would still need to prove your assertion that
there is only one lawsuit and that he does not "habitually utter falsehoods" and
"[lie] repeatedly"  using some other source. Having no source at all is not
acceptable.

It might have been reasonable for Tso to say that my references weren't 
specific 
enough, but he didn't make that claim, and I added more specificity when he 
continued to assert 'only one case'.

> I haven't read up on enough of the context to form an opinion on the
> reputation versus statement accuracy issue in this instance.

> So, to summarize my look at a few of the messages: You both lose points for
> some of your statements or how you tried to make your arguments, and the
> accuracy of the summary page is questionable. None of it, so far, really
> suggests any sort of professional dishonesty on Ted's part to me. 

1) false claims of facts about whether someone was a 3-time court-proven liar.

2) Fabricating statements and attributing them Dean Anderson

> (If this were a research paper instead of an email message, I'd probably want
> him to be much more careful and even pedantic in his arguments, but that would
> be about the quality of the work, not honesty.)

If this were a paper submitted at a course at MIT, Tso would be considered for 
expulsion.

But you are minimizing the context of these messages. The IETF is an activity of
the ISOC, which is a professional membership organization. Tso was acting in his
official role as Sergeant at Arms. These are not random personal muttering on
some email list, but official IETF documents of the Sergeant at Arms.

> Bored now, and not interested in the case under discussion in that old 
> thread; 
> I'm going to stop digging




-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: delegating (portions of) ietf list disciplinary process (fwd)

[Dean Anderson]

On Thu, 29 Sep 2005, Harald Tveit Alvestrand wrote:

I didn't see this message from Ken Raeburn go to the IETF list. [I just found it
on the IETF archive site, I will respond in detail shortly.  Strangely, I should
have received 2 copies, one to [EMAIL PROTECTED] and one from the IETF list. I 
have
neither.  Must have a mail problem somewhere.]

> I think you illustrate quite well why I'm glad I don't have to talk to Dean
> Anderson any more.
> 
> Any conversation where I can't toss of a casual remark without getting 
> virtually crucified for it is a conversation not worth having.

Harald was never "crucified". His personal remarks were inappropriate, as are
the remarks above.  But he was not reprimanded in any way.  Harald's personal
opinion of anyone is completely irrelevant to any business before the IETF,
unless it is to show that _Harald_ has a conflict of interest. 

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: delegating (portions of) ietf list disciplinary process (fwd)

[Dean Anderson]

Let me ask you Ken: Are you participating in the IETF as part of your job?  Or
are you just here for personal kicks?

On Thu, 29 Sep 2005, Ken Raeburn wrote:

> Perhaps there is no legal standing for an expectation of privacy.   

It has nothing to do with legal standing. Its a question of etiquette.  Office
etiquette and backyard-fence etiquette are different.

> Still, it is generally considered discourteous among most serious email users,
> I think.  But we seem to have gone past the point where that matters to
> people.

This is only true with respect to PERSONAL communication. BUSINESS communication
is not personal communication.  

If my friends tell me something personal outside of business, I keep it private,
because its personal.  My friends don't write personal notes to the IETF Chair
complaining about me and my company. [certainly not feigning having no
position.] That would be business, and they probably wouldn't be my friends
anymore.

If you file a motion with the FCC or write a nasty gram to the IETF Chair, its a
business document. I have every right to publish it. Its not personal. 

And I do business favors, too, but I have no obligation to do so.

You don't understand the distinction between business and personal.

Actually, I'm now convinced that this is the whole problem with the abuse at the
IETF: An inability to distinguish between personal and organizational interests
and subject matter.

> So, if I wanted to make comments to you about IETF matters, people's personal
> conduct on mailing lists, etc, that I didn't want made public to fuel
> arguments I specifically don't want to add to, I should ask you to sign an NDA
> first?  Got it, I'll keep that in mind.

Those are business topics.  If you are concerned about "fueling" something, then
you should keep silent. Only a lack of fact adds "fuel", otherwise known as
hyperbole.  You should consider your business commications differently from your
personal communications.

> This has been vaguely entertaining for a while, at least until a friend of
> mine became one of the side targets.

Oh, I sympathize.  I thought it funny too, until I became a target of repeated
abuse, defamation, and disparagement for merely making true statements that
counterfeit anti-spammers didn't like.

The good thing is, lies wash off. But the truth sticks with you forever. Once
you are a Court-proven liar, associate with a court-proven liar, dishonest etc.,
that doesn't go away.  Alan Brown will be a 3-time court proven liar for the
rest of his life, unless he becomes a 4-time court proven liar.  Nothing he does
will ever remove that.  

Even a lesser miscreant, Chris Neill, fired for conducting open relay abuse he
was convinced was undetectable in 1999, just recently sent me a nasty gram.  6 
years later, and he hasn't forgotten. 

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: delegating (portions of) ietf list disciplinary process

[Dean Anderson]

On Thu, 29 Sep 2005, Nick Staff wrote:

> Of course it's a matter of opinion, so it's not like I'm trying to tell you
> I'm right and you're wrong, but think about every high court in the United
> states and many in Europe - none of them are 1 person but rather a group.
> There are reasons for this, most important of which is no one is right all
> the time - no one no matter how wisened sees every situation clearly from
> all angles - not to  mention most everyone has their hot issues and areas of
> predjudice or misunderstanding.  Having a group of seven or nine helps
> neutralize individual errors.  I'd feel much safer being judged by tcp than
> udp.

This is a good idea.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

On Thu, 29 Sep 2005, grenville armitage wrote:

> Since when have political conspiracy theories, 

Political conspiracy theory? The disparagement machine is working overtime.

> allusions to impending legal action

I made no allusions.  I demanded compliance with the law and performance of
fiduciary duty, and for the IETF to stop defamation. That isn't an allusion.

> and references to other people's dating lives 

I made no reference to anyone else's dating life.  However, memory serves that
we dated the same girl.  It is quite reasonable to question if the new partner
of a lost romance is a target for long term vengeful behavior and animosity.  
Some people hold these grudges their entire lives.

> been admirable examples of 'forceful, stubborn, or persistent' discourse?

These characteristics are all more admirable than "court proven liar",
"professionally dishonest", or "lack of personal integrity"


--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: delegating (portions of) ietf list disciplinary process (fwd)

[Dean Anderson]

On Wed, 28 Sep 2005, Dave Singer wrote:

> >This was offlist, but I think it is relevant, now to similar 
> >questions raised by
> >others.
> 
> Yes, emailed to you offlist.  Do you have NO idea of professional 
> courtesy?  You do not post personal emails by other people without 
> their permission.  You needed to ASK first whether I minded.

Your points were relevant, and they were sent to the IETF Chair. Thus, you don't
have any privacy interest in it.

There are no privacy interests in official business communication, unless you
have an NDA arranged in advance.

If you send a letter to the FCC about Verizon, Verizon is entitled to publish
that letter without your permission. 

It seems that you have no idea of the difference between personal communication
and professional business communication. But I've also just learned that the
distinction between personal and official actions is a problem at the IETF.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: delegating (portions of) ietf list disciplinary process (fwd)

[Dean Anderson]

This was offlist, but I think it is relevant, now to similar questions raised 
by 
others.

I will put the original messages at http://www.av8.net/IETF-watch/Tytso.html

I will try to have this done tonight.

Offlist, Ted has said he has no recollection of me. Indeed, I did not meet him.
I wasn't sure if he had some personal animosity at an ancient romance lost.  I
have sent him the name of the girl I think we may have both dated. If he denies
dating her, or denies having any animosity because of it, then I know of no
personal animous, so his inability to properly summarize my argument must be a
mistake on his part resulting from some reason other than personal animosity.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


-- Forwarded message --
Date: Wed, 28 Sep 2005 19:50:38 -0400 (EDT)
From: Dean Anderson <[EMAIL PROTECTED]>
To: Dave Singer <[EMAIL PROTECTED]>
Cc: Theodore Ts'o <[EMAIL PROTECTED]>, Nick Staff <[EMAIL PROTECTED]>,
 Brian E Carpenter <[EMAIL PROTECTED]>
Subject: Re: delegating (portions of) ietf list disciplinary process

On Wed, 28 Sep 2005, Dave Singer wrote:

> Good grief!  I am (mostly) a lurker on this list, and I know none of 
> the people involved in this subject so far, and have (to the best of 
> my knowledge) not shared a mailing list with them.
> 
> Here you bring in a matter that is unrelated to the dispute at hand, 
> in a way that makes direct, personal attacks on a specific 
> individual, without providing substantiation.

It is related to the subject matter of this thread. This thread is different 
from the DNSOP Mismanagement thread. Perhaps you are confused about that.

You seem to confuse "personal attack" with specific professional criticism.

If you mean that you cannot evaluate my accusation without the original
messages, that is an entirely fair request. I will make them available so that
they can be evaluated by others and so that my accusation can be fully verified.

> "professionally dishonest" is a grave accusation.  

Indeed it is. I don't make it lightly.  

The issue involved is not limited to just the specific criticism of Mr. Ts'o.  
The IETF Chair doesn't seem to consider professional honesty important in IETF
officers.  Bad leadership starts at the top, as does good leadership. The
failure to act on verifiable accusation of professional dishonesty is also
itself a criticism to which the IETF Chair can be held accountable.  The IETF
Chair has had both the original messages and the accusation for far longer than
you've known about it.

> I assume from reading the email that this is unrelated to the DNSOP subject
> under discussion.

The current thread subject "Re: delegating (portions of) ietf list disciplinary
process", did in fact arise out of discussion of the diciplinary questions
raised on DNSOP Mismanagement discussion.  But it is now a separate discussion
with its own subject description, and has its own issues that are related to
disciplinary process in general, not just the particular one under the DNSOP
Mismanagement subject.

The failure of the IETF Chair to discipline the Sergeant at Arms is an example
of a critical and high level failure of disciplinary process.

> I doubt that this new accusation needs to be discussed 
> on the IETF list along with the original subject, and so you have 
> left those accused in the unpalatable position of either letting the 
> accusation stand, or propagating a discussion that did not previously 
> and probably should not exist on the list. 

_I_ have left no one in an unpalatable position.  Mr Ts'o is responsible for his
own actions.  He has left himself in an unpalatable position. And Mr. Ts'o also
has a copy of the messages, if he chooses to dispute my accusation.  I have not
made vague charges that aren't specific enough to be disputed, if that's what
you mean.

This accusation can certainly be discussed under the current subject on 'ietf
list disciplinary process'.  I included enough to make specific my accusations;
My accusations are not vague. The IETF Chair has Ts'o's original messages, and
as well as my offlist complaint that they failed to act on.

And as I said above, if you mean that you cannot evaluate my accusation without
the original messages, that is an entirely fair request. I will make them
available so that they can be evaluated by others and so that my accusation can
be fully verified.

>  Can you think of a courteous way to resolve this for the community?

Yes, I can. The IETF (and ISOC) leadership can start holding IETF officers
accountable for professional honesty.  That is a critical first step to honest
and fair disciplinary processes.

Working down from the top officers, eventually everyone includin

Anycast DNS [some tech] was RE: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

On Tue, 27 Sep 2005, Hallam-Baker, Phillip wrote:

> 
> > From: Dean Anderson [mailto:[EMAIL PROTECTED] 
> 
> > It is not DNSSEC that is broken.
> 
> Anycast has been deployed for four years. 

I think it is three years. But it has been controversial from the start.

> Any change to the DNS infrastructure that is incompatible with use of anycast
> is not acceptable and will not be deployed.

I don't think you get to make that demand. Or rather, I don't think you get to
impose that demand.  But Root server operators have to comply with RFC2870.  
RFC2870 does get imposed.

> Anycast significantly improves the response time and the robustness of
> DNS operations and allows operations to be made more scalable and run
> more economically. 

This is not true, either.  But it is yet another Nanog legend. I've analyzed
this in detail previously.  But I'm not going to get into it in detail now.
Here's the short answer:

The following is predicated on BGP anycasting (without PPLB), in which a subset
of clients talk to only one anycast instance.  If you do Lan anycasting, the
analysis is similar, but not exactly the same.

Response time:

Response time is primarily dependent on network latency. This has nothing to do 
with choice of anycast or unicast.

Robustness, scalability:

If you have only 4 servers to configure, then 4 unique IP address better
distribute load than 4 anycast servers on the same IP. Given the same resources,
A DOS against a single IP is more effective than a DOS distributed against 4
IPs.  With unicast servers, all 4 servers have to go down before service is cut
to clients. Nor is anycast more robust for DOS: suppose the DOS is sufficient to
take down 2 servers of 4 anycast. All of clients of those 2 servers with be out
of service. This may not be half of the clients because load isn't evenly
distributed. It may be more than half, or less than half. So, more servers with
unique IP addresses is better.

Does it get better if you take your 4 servers and make 2 IPs with 2 Anycast
each?  No. Because a DOS only has to divide its resources in half, instead of by
fout.  Given our same premise, that they can take out 2 servers, they attack
each anycast server and take out one for each IP. This will affect something
like 25% of the clients with a total outage (but again, not exactly, because
load isn't distributed evenly.

The number of servers in this analysis can be 13, 26, 52, etc.  With fewer than 
13 servers, we can easily have 13 IP addresses. With more than 13 servers, 
people think they have no option but anycast. There are alternatives.

> Core DNS is subject to continuous DDoS attacks. Without anycast there is
> a possibility that at some point in the future it might not be possible
> to support the bandwidth needed to defeat these attacks.

We'll have to deal with that in the future.  

I think it would be better to find a way to allow more than 13 root servers.  
There are several ways to do that: allow an EDNSO or perhaps a truncated
response, or limit authoritive data from the root response. so one would have
more than 13 servers in the nameserver root hints but only 13 in the authoritive
response. As long as the responding server is in the authoritative list, the
resolver and cache should have no problems.  Those caches that overwrite the
in-memory hints with the authoritive response would then be limited to a subset
of only 13 servers. But this isn't a bad thing.  There are a number of things
that can be worked out to have allow more than 13 servers without breaking DNS.

But of course, its also possible to build bigger servers.

Anycast is not the only solution to DDOS attacks.

> The DNS has operated successfully without DNSSEC up to this point. The
> onus is always on those proposing a change to work within the deployed
> infrastructure.

Well, thats one view. There are other views about the operation of DNS up to
this point, with respect to Anycast Extension. Since the Anycast Extension isn't
approved, the onus seems to be on root server operators to use approved
practices.  The deployment of unworkable technology seems to go against the view
of "successfully operated".

> The DNSSEC spec makes several proposals that appear to address the
> packet fragmentation issue. If you think these are inadequate you should
> explain why.

I have explained. You just don't seem to understand.  DNSSEC can't address the
problem. Its at a layer below DNSSEC.  The problem has nothing to do
specifically with DNSSEC in any way that DNS could possibly change.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: delegating (portions of) ietf list disciplinary process

[Dean Anderson]

This isn't going to work, with ordinary members.

But Ts'o makes good points. You can't know easily who is trustworthy.  Though
you can know sometimes who is not trustworthy.

I've seen a number of people in the leadership act inappropriately. Offlist, Ted
Ts'o, in his official role as Sargeant at Arms, was recently professionally
dishonest by falsely attributing statements to me that I didn't make. Ts'o was
summarizing the arguments I raised. Since Ts'o went to MIT, and since (if I
recall correctly) we dated the same girl at different times, I'm not sure if I'm
more comfortable thinking this is personally motivated rather than some sort of
incompetence at the task of literature summary.  But fortunately, freshman must
now demonstrate skill at literature summary.

But Ts'o also asserted false facts[*] to the IETF Chair that are easily 
checked.  
He did this repeatedly, after being repeatedly informed that his fact claim was
false. The IETF Chair was informed, but took no action on these serious ethical
lapses.

One needs to hire lawyers to do this sort of thing.  Lawyers are trained to find
facts, and to approach arguments dispassionately. Further, failing an acceptable
resolution, such disputes may wind up in litigation, so finding a fair and
honest solution is definitely going to be worth it.

[* Ts'o asserted that Alan Brown lost only one court case. In fact, Brown lost
three: One case (Domainz) was defamatory statements on an email list. Two others
(Xtra and Actrix) involved false claims of ISPs having open relays.]

On Wed, 28 Sep 2005, Theodore Ts'o wrote:

> On Tue, Sep 27, 2005 at 06:47:36PM -0700, Nick Staff wrote:
> > > 2. An IETF "netiquette" committee, to offload list banning 
> > > procedures from the IESG.
> >
> > I'm a big fan of the netiquette committee.  I'd like to suggest that
> > volunteers be allowed to "throw their names into the hat" and that members
> > be selected blindly from that pool.  This would of course avoid any stacking
> > or favoritism, but we would need a "qualifier" that prevented interlopers
> > from submitting their name.  Though I hate to suggest it as it would exclude
> > me from selection, having attended an IETF meeting in the last x years could
> > possibly be a good filter.
> 
> Maybe.  I see two potential problems:
> 
> 1) Serving on this committee is going to be no fun at all.  Getting
> qualified people to sign up for what will only be seen as a sh*t job
> is going to be difficult.  And how do you exclude certain known
> (repeat) troublemakers from throwing their hat into the ring?  Or
> maybe you don't, but then if they get selected, they would then have
> the opportunity to practice their own unique form of DOS on the
> netiquette committee?
> 
> 2) Unless discussion of the decisions of the netiquette committee,
> during the committee is considering a request, and after the committee
> has rendered a decision, is ruled out of scope, it's not going to help
> the very long discussions such as this one which plague the IETF list.
> In the worst case, we can assume that the mailing list abuser will
> immediately appeal any decision of the netiquette committee, which
> means that after inventing this entire mechanism, it may not have any
> effect other than prolonging the agony.
> 
> Problem (2) could be solved by making the decisions of the netiquette
> committee not subject to appeal, but that causes its own problems and
> potential for abuse of the people who do end up on the committee.  But
> if you don't, then people who are intent on practicing their DOS
> attacks (or otherwise impose their view of their world on us) will
> simply use our procedures against us.
> 
> I suppose we could try to add some sanctions such as using a very
> large ban time (measured in multiple years), so the benefit of trying
> to get someone banned from the list is worth the cost, assuming we are
> willing to preserve through the entire tortious process of (a) a
> decision by the netiquette committe, (b) an appeal to the IESG, (c) an
> appeal to the IAB, and eventually (d) an appeal to the Internet
> Society --- or perhaps we could impose an automatic doubling of the
> sanctions if someone attempts an appeal, and double the eventual ban
> time at each level of appeal if the banning is eventually upheld.
> 
> But there isn't really a good solution to this problem, unfortunately.
> 
>   - Ted
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

cluding at
the IETF.  You can frequently identify them by their participation in Nanog and
anti-spam issues.

Just recently, people wanted the IETF to associate with counterfeit
anti-spammers who were also 3-time court-proven liars. This was really
remarkable, since many on the IETF are academic or research scientists.  
Associating with such dishonesty would discredit them in their professional
life. I've never seen people try so hard to associate with the dishonest, and
try so hard to suppress facts that are easilly checked, like that fact of being
a court-proven liar, twice lying on the subject of open relays, which was what
the IETF people wanted to associate and trust them on.  This provoked a very
strong response in personal harrassment.

But that was truly remarkable, so much so, I'll digree here for a moment. I've
worked in research environments (Charles Stark Draper Lab), and attended MIT,
I've had a little experience with this community.  My GF teaches at MIT. She's
had a couple students plagarize over the years.  This is a very serious academic
offense. It is grounds for expulsion. Years of work is lost. What good school
wants to admit a plagarist?  I know what "professional dishonesty" means to an
academic or researcher.

Academic and research professionals have great concern for things that go under
the heading of "professional dishonesty".  Professionals don't associate with
liars, particularly when those lies are established by a court, and on the same
topic. Honest people seek truth, not lies. No professinal wants to be associated
with dishonesty. Security clearances are denied for dishonesty. Professional
credibility, established over a lifetime, is lost.  And by "professional", I
don't mean "someone who does something for a living", as in "Professional
car-mechanic". I mean academic and research professionals, who have standards to
meet, and a career at risk.  

Back to controversies:  Just recently, the DNSEXT chairs also tried to violate
the patent policy of the IETF by suppressing discussion, and failing to obtain
disclosure statements.  This is another valid complaint, which is also under the
supervision of David Kessens. Plainly, the DNSEXT WG Chair doesn't really
appreciate my contribution to adhering to IETF policy.  Kessens' has so far
ignored the complaint, except to try to prevent me from posting, on a frivolous 
claim.

Another controversy: Certain IETF WG Chairs think they can do IETF work
according to their own terms, and according to their own policies.  Ususally
employees that refuse to adhere to company policies are shown the door. Usually,
the sooner this is done, the better.

These things make me unpopular with some people. These things don't justify the
harrassment that has been directed at me. The policies of the IETF are meant to
protect me from this harrassment.  The management of the IETF has the authority,
responsibility, and obligation to protect me from this harrassment, and from
defamation by IETF officials.  It is a scandal that the IETF management is
involved in conducting the abuse, and has failed to stop the abuse and the
defamation. 

> particularly as they form a long-term pattern of harassment of a particular
> company or persons.

I have not harrassed anyone.  I have been harrassed, as evidenced by the
numerous school-yard name-calling, defamation, disparagement, etc. I have not
engaged in this behavior. Mostly, this behavior is motivated for my positions on
the above (many not IETF relevant) issues. But the harrassment isn't limited to
harrassing Dean Anderson or Av8 Internet. There are a small number of abusers.
They abuse many people, and their abuse is unchecked by IETF management.

In the case of instant criticism of ISC, several people have raised the same
objections, and have been similarly attacked.  Attacks for genuine ISC criticism
are not limited to me personally.

But Non-IETF conflict should be kept out of IETF business. There are policies to
disclose conflicts of interest.  This does not mean that ISC should be immune
from criticism for improper root server operation on the DNSOP list. That topic
is specifically listed in the DNSOP charter. It does mean that ISC employees
should be prevented from using their official IETF position to defame Av8
Internet. It means that people should be prevented from disparaging Dean
Anderson and Av8 Internet, as well as a number of other people. 

> Note that I consider it irrelevant whether his position in this or any past
> instance turns out to be correct: it's the form, not the content, of his
> efforts that is the problem.

Note that Stephen Sprunk has disagreed vehemently with the above listed non-IETF
issues on Nanog.  There is plainly nothing wrong with the form of my messages.  
The attacks are personally motivated.

> [1] Many modern routers, particularly ones used in the Inter

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

I'm rather reticent to add real technical discussion to the issue of list 
mismangement. 

On Tue, 27 Sep 2005, Bill Sommerfeld wrote:

> On Tue, 2005-09-27 at 10:06, Robert Elz wrote:
> > Date:Mon, 26 Sep 2005 15:41:56 -0400 (EDT)
> >     From:    Dean Anderson <[EMAIL PROTECTED]>
> > Message-ID:  <[EMAIL PROTECTED]>
> > 
> >   | It is not DNSSEC that is broken.
> > 
> > I have not been following dnsop discussions, but from this summary, there
> > is nothing broken beyond your understanding of what is happening.
> 
> It's worse.  The reasoning is broken on other points, as well.
> 
> In these arguments, RFC 1812 has been cited repeatedly as a
> specification for load-splitting.  By my reading, 1812 is extremely
> vague about the topic, and does not require a specific spreading
> algorithm.  

Yes. It gives the implementor tremendous lattitude. But plainly, it is 
appropriate to do (as Cisco did), per packet load balancing, where successive 
packets can be expected to take different paths.

> Its strongest recommendation is that there be a way to turn
> it off if it doesn't work for you, which should by itself be a clue that
> load-spreading should be used with caution; it also cautions that that
> load-splitting was an area of active research at the time 1812 was
> published.

And now there are implementations and users that use it. 

But to make anycast work with TCP or large UDP and fragments, one needs to
guarantee that two successive packets (actually an entire session) uses exactly
the same path.  No load balancing (or very course grained load balancing) is
required.  The prescription given in RFC1546 needs to be changed:

RFC1546 page 5:
---
How UDP and TCP Use Anycasting

   It is important to remember that anycasting is a stateless service.
   An internetwork has no obligation to deliver two successive packets
   sent to the same anycast address to the same host.
---

RFC1546 also gives a prescription for alterations to TCP so that TCP can work
with Anycast and with the condition on successive packets above. So far as I
know, no one has implemenated this prescription in a TCP stack.

> Moreover, load-splitting which results in the sort of flow-shredding
> which would disrupt multi-packet anycast exchanges also causes
> significant difficulties for unicast.  To quote from rfc2991 section 2:

RFC2991 is a Informational, and is wrong in some of its assertions. This was
discussed on the GROW list.

>Variable Path MTU
>  Since each of the redundant paths may have a different MTU,
>  this means that the overall path MTU can change on a packet-
>  by-packet basis, negating the usefulness of path MTU discovery.

This is not a real problem. The MTU is reduced to the smallest MTU of any path. 
 
If PMTUD is turned off (an option rarely used) the DF bit is also turned off and
so packets will be fragmented.  While the smaller packet size might be
sub-optimal on the larger MTU paths, this is just a (tiny) performance
consideration.

It is not the case that the usefulness of path MTU is negated.

>Variable Latencies
>  Since each of the redundant paths may have a different latency
>  involved, having packets take separate paths can cause packets
>  to always arrive out of order, increasing delivery latency and
>  buffering requirements.
>
>  Packet reordering causes TCP to believe that loss has taken
>  place when packets with higher sequence numbers arrive before
>  an earlier one.  When three or more packets are received before
>  a "late" packet, TCP enters a mode called "fast-retransmit" [6]
>  which consumes extra bandwidth (which could potentially cause
>  more loss, decreasing throughput) as it attempts to
>  unnecessarily retransmit the delayed packet(s).  Hence,
>  reordering can be detrimental to network performance.

RFC2991 also mis-states the TCP issue. RFC2581 describes the Fast retransmit
behavior as follows:

   "The TCP sender SHOULD use the "fast retransmit" algorithm to detect
   and repair loss, based on incoming duplicate ACKs.  The fast
   retransmit algorithm uses the arrival of 3 duplicate ACKs (4
   identical ACKs without the arrival of any other intervening packets)
   as an indication that a segment has been lost.  After receiving 3
   duplicate ACKs, TCP performs a retransmission of what appears to be
   the missing segment, without waiting for the retransmission timer to
   expire.

RFC2991 mis-states this as follows:

 When three or more packets are received before
 a "late" packet, TCP enters a mode called 

RE: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

On Mon, 26 Sep 2005, Hallam-Baker, Phillip wrote:

> 
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Tim Bray
> 
> > On Sep 24, 2005, at 8:28 PM, Dean Anderson wrote:
> > 
> > > None of my emails have been abusive.
> > 
> > Speaking as a 99.% passive observer around here, I consider  
> > Dean Anderson's emails, in aggregate, abusive. They consume precious  
> > mental bandwidth, in many cases with no material technical content,  
> > and thus make it more difficult for me (and I assume many others) to  
> > follow the flow of IETF discussion.
> 
> I am completely unable to follow the line of argument.
>
> Dean appears to be claiming that DNSSEC is somehow incompatible with the
> widespread use of anycast. If for the sake of argument we accept this as
> true the only conclusion I could draw from such a situation is that
> DNSSEC would have to be sent back to be reworked again. If DNSSEC does
> not support existing use cases then it has to be fixed.

It is not DNSSEC that is broken.

> But I do not see how DNSSEC is incompatible with anycast. It is merely
> an assertion that is repeated without evidence. Anycast might possibly

There has been plenty of evidence on the DNSOP list and most recently on the 
GROW list.  Without getting into to much detail, Anycast doesn't work with TCP, 
but it also doesn't work with large UDP packets and fragments. DNSSEC requires 
large UDP packets and fragments. The details of why fine grained load balancing 
permitted by RFC1812 break the Anycast Extension are hinted at in RFC1546 and 
the footnotes to my instant criticism on DNSOP. I can send you a more detailed 
explanation if you like offlist.

Your assumption below is common: You assume that everyone does course grained
load balancing or no load balancing. Besides RFC1812 permitting fine grained
load-splitting in "theory", Cisco implements it.  There are active programs
underway such as BGP multipath, which also results in fine grained
load-splitting.  One cannot assume that two successive packets are delivered to 
the same path or that two successive packets will reach the same Anycast 
destination.  This is acceptable for small, stateless UDP packets. It is not 
acceptable TCP or large UDP packets and fragments.

> break TCP/IP fallback but it is unlikely that the anycast routes would
> change rapidly enough for that effect to be any more significant than
> existing TCP issues created by firewalls.
> 
> Cryptography is remarkably indifferent to transport, this is the biggest
> challenge in the DKIM spec. Depending on particular transport
> configurations has in the past turned out to be a mistake. The
> authentication of the end point IP addresses in IPSEC achieves no useful
> security purpose, it only causes the protocol to become more brittle in
> use.
> 
> If the issue is real then it should be raised in DNSEXT where the DNSSEC
> specs are being developed. It does not appear to be genuine to me.

Its not a problem with DNSSEC per se. It a problem with operation of Anycast 
Root Nameservers.  There should not be any Anycast root nameservers.

> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

On Sun, 25 Sep 2005, David Kessens wrote:

> I first sent a message on the dnsop mail list that most people would
> interpret as a clear warning to behave better or face the
> consequences. However, considering earlier misunderstandings, I sent
> him a private message to make sure he fully understood what I was
> telling him.
> 
> > Dean in turn informed the IESG of your warning because he felt it
> > was unwarranted and being used by you as a tool to silence someone
> > who had a differing technical opinion. 
> 
> He did two things: He sent another inflammatory message to the dnsop
> mail list in which he again attacked a well-known organization while
> he was just told to refrain from such attacks.

Entirely false.

I sent a note stating that:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03553.html

This is not an attack. It states that mis-operation of root DNS servers is a
valid topic for DNSOP, refuting your claim that my criticism was somehow 
inappropriate.

The charter for DNSOP states
http://www.ietf.org/html.charters/dnsop-charter.html

1. Define the processes by which Domain Name System (DNS) software
  may be efficiently and correctly administered, configured, and
 ^^^
  operated on Internet networks. This will include root zone
     ^^^
  name servers, gTLD name servers, name servers for other DNS
  
  zones, iterative DNS resolvers, and recursive DNS resolvers.
  As part of this effort, the group will produce documents
  explaining to the general Internet community what processes
  and mechanisms should be employed for the effective management
  and operation of DNS software. 

2. Publish documents concerning DNSSEC operational procedures. 


Plainly, correct operation of Root zone nameservers is a valid topic for DNSOP
as described above.  The subject of mis-operation of Root DNS servers is proper
topic.

Plainly, the Anycast Extension also affects DNSSEC operational procedures.

> In addition, he forwarded my private message to the IETF mail list.
> However, he not just forwarded my private messsage, he added simular
> accusations as the ones in his earlier messages to the dnsop mail
> list.

Another false characterization. The message is at
http://www1.ietf.org/mail-archive/web/ietf/current/msg37864.html

I added no additional accusations, but merely forwarded Kessens' threat.  This 
is an administrative complaint, and on-topic for the IETF list.


> > You then used his complaint to the IESG as an instance of another
> > abusive post and requested to have his privileges removed. Is that
> > basically correct? 
> 
> No, it was not his complaint as he did not sent a complaint. It was
> the fact that he used his messages to repeat the same accusations that
> he was warned not to repeat.

I didn't send a complaint?  Really? 

   "FYI: I am being threatened for posting operationally relevant criticism of 
mis-operation of the F DNS Root server on the DNSOP list."

Sounds like a complaint to me, which is how I meant it, and plainly, how 
everyone else took it.

> > If so are you telling me that I have to be afraid of ever voicing a
> > complaint or problem to the IESG because an AD can use that as a
> > reason for retribution? 
> 
> I did not send my request to the IESG just because he voiced his
> opinion or filed a complaint. I sent my request, because, among
> others, his comments were out of scope for the dnsop working group, he
> voiced his opinion in a totally unprofessional manner and repeated
> this behavior on two different mail lists right after he was warned.

Well, that "out-of-scope" question seems to be a dog that won't hunt.

And it is plain that you did send a complaint because of my complaint to IETF 
list. You mentioned that post in your complaint as a basis for your complaint:
And I note that your complaint was in fact a "reply-to" my complaint to the 
ietf 
list.

Kessens' wrote in his complaint:
  As you can see from my private mail that Dean forwarded to the IETF
  list, I have given him an official warning to refrain from sending any
  more abusive mails to IETF maillists. Despite this, he immediately
  followed up by sending more abusive mails to the dnsop and ietf
 
  mail lists.
  ^^^
http://www1.ietf.org/mail-archive/web/ietf/current/msg37865.html

Note both the "ietf mail lists", and the fact that his complaint was a reply-to 
my complaint to the ietf list.

Plainly, Kessens acted in retaliation.


> I hope this helps to clarify the events.

No, but we have records that establish withou doubt the events.

> David Kessens
> ---
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service

RE: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

First, remember that Bill Strahm is a working group chair who doesn't believe he
has to either 1) interact with IETF participants, or 2) not defame IETF
participants in his official duties. He thinks its perfectly OK for Rob Austein 
of ISC to use his IETF position to defame Av8 Internet:

On Fri, 18 Jun 2004, bill wrote:
> As a working group chair - I would refuse an e-mail account that I am
> not allowed to spam control on my own terms.
>
> Before long these published email addresses would become spam sponges -
> and completely worthless (or expensive timewise to correctly filter
>
> Bill

The IETF email lists and other accounts seem not to have this problem.

Bill Strahm should also be removed as a WG chair for refusing to perform his
duties as a WG Chair according to the IETF rules.

On Sun, 25 Sep 2005 [EMAIL PROTECTED] wrote:

> Nicholas Staff wrote:
> > If so are you telling me that I have to be afraid of ever voicing a
> > complaint or problem to the IESG because an AD can use that as a reason for
> > retribution?

> The way I see it - the answer is, under normal circumstances NO.  However,
> in the history of the IETF there have been several cases where people go
> out of their way to send unwarranted complaints to various ADs/IESG/IAB
> with unwarranted claims.
> 
> If you were to do this more than a few times...  Well, lets just say
> crying wolf once isn't a foul - but after a couple more times the town
> won't come out to see if there is a wolf in the pasture.

I haven't seen very many unwarranted claims, outside of Kessens instant claim,
of course.  There are few precedents for that kind of abuse.
  
However, the abuse documented by myself and others is pretty plainly abuse:
Schoolyard-level name-calling, publishing unsubscription addresses and such are
plainly abuse.  Professional dishonesty [that is to say, denying proper credit,
or crediting someone else improperly, or reporting falsely and disparagingly on
the contents of a document one hasn't read] is plainly abusive.  Defamation is
plainly abusive.

Unjustified threats to suppress valid technical criticism is a bit more
sophisticated.  I can't think of another case similar to that.  But of course,
we can figure out if my technical criticism is justified, and if it is, it
completely undermines the credibility of Kessens' complaint.  And in this case
the answer is easy to find. Simply answer these questions:

1.  Does Anycast Extension work with fine grained per packet load splitting as
described by RFC1812 and as implemented and documented for example in Cisco
PPLB on various Cisco routers?

If the answer to the above question is "No", then Dean Anderson, Dan Bernstein,
and Iljitsch van Beijnum are right, and ISC is wrong.  On two Working Groups, no
one has claimed that the answer is "Yes". The opposing arguments generally
either claim that PPLB is impossible (easily refuted), or that the Anycast
Extension works with course grained load balancing (which doesn't answer the
question and isn't "Yes").

2.  Has the IETF approved the Anycast Extension?

The answer is plainly "No". There is no RFC and no approval.  This is plainly
found in IETF records.

3.  Does ISC F Root operational deployment of the Anycast Extension comply 
with RFC2870?

There is a technical standard for Root Server operation. There are technically
unambiguous ways to determine compliance with RFC 2870. Since there is no IETF
approval of the Anycast Extension, and since this Anycast Extension can't work
in general for those users that exercise fine grained load splitting according
to RFC1812, a Root DNS server with this extension cannot meet the requirements
of RFC2870 Section 2.6.  So, the answer to question 3 is "No". Therefore, this
unapproved extension should not be deployed on Root Nameservers, and ISC should
not be encouraging root server operators to do so by telling people it is safe,
approved, or "uncontroversial".

And Therefore the following are true:

1) my criticism is valid
2) Kessens' threat is plainly inappropriate
3) My complaint about Kessens threat is substantiated

There is no case where Kessens complaint in retaliation to my administrative
complaint of his threat is justified.  This is because even if I and the others
were wrong in our criticism, I am still allowed to complain about the threat.  
There is no case where Kessens is allowed to retaliate for my complaint.

Second, my criticism of ISC F Root operation is well-justified, footnoted, and
technical. And it also has the characteristic of being correct and
substantiated.  But the point of posting any technical criticism is to discuss
the issues. A well-justified, footnoted criticism could possibly turn out to be
wrong. But even if some such criticism was subsequently found wrong,

Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

On Mon, 26 Sep 2005, Brian E Carpenter wrote:

> No, but on the other hand WGs, the IESG and the IETF as a whole are fully
> entitled to defend themselves against denial of service attacks. 

There have been only 2 denial of service attacks: 

1) When Dan Bernstein's subscription address was posted by Randy Bush on the
DNSEXT WG in violation of list and IETF policy, making possible forged
unsubscriptions, denying service to Dr. Bernstein on the issue of Anycast
Extension.

2) Kessens' instant attack trying to suppress valid technical criticism of ISC's
F Root operation, also on the issue of Anycast Extension.

> If someone persistently sends off-topic mail over a long period, or mail
> making acccusations that are clearly outside the IETF's scope, or simply
> repetitions of the same point over and over, that is in effect a DoS and that
> is why we have RFC 3683.

True statements generally, but this hasn't happened, and this does not describe
the current situation.  My emails are plainly on-topic. Dan Bernsteins' email
were plainly on-topic, and relevant to current issues discussions within the
IETF.

Plainly off-topic and plainly disruptive is school-yard name-calling, as has
been repeatedly documented.

> And to be very clear, if two parties are at odds outside the IETF, that must
> stay outside the IETF. Inside the IETF (i.e. on our mailing lists and at
> our meetings) there is no place for external disputes.

And of course, it is up to the IETF upper management to make sure that a WG 
chair employeed by one company (ISC) does not abuse his IETF position in that 
dispute.  The IETF has clearly failed in that aspect, by allowing Rob Austein 
to 
continue using his official IETF role to defame Av8 Internet.

Plainly school-yard namecalling on the IETF lists is within "scope", and 
prohibited by both the IETF Code of Conduct and the ISOC Code of Conduct.

Plainly abuse of privileges by IETF WG Chairs and Area Directors is within 
scope.

> WG Chairs, the Area Directors, and the IESG do have authority here.

Indeed they have not only authority, but also legal responsibility and legal
obligation to comply with the rules, but they haven't acted in the IETF interest
or acted according to the well-documented IETF and ISOC rules.  This conflict of
interest and lack of fidelity to the IETF and ISOC rules is a scandal for the
IETF, and for the ISOC.

Dean Anderson
Av8 Internet, Inc

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

None of my emails have been abusive.  The IETF is not some random list that can
make up rules as it pleases. Nor is the IETF a popularity contest. Unlike
members of "joes barbecue list" or Nanog, or other such lists, IETF Participants
have an opportunity to participate and under the ISOC and IETF codes of conduct,
a right to be free of unwarranted personal attacks and threats.  Valid,
justified, technical criticism is not a violation of any IETF rule. Nor is valid
criticism a disruption.

Kessens' fallacious complaint is just revenge in an attempt to squash valid
technical criticism of ISC's operation of F Root.  Valid criticism of Root DNS
operation is an appropriate topic for the DNSOP list.  I think that the IESG
ought to address the validity of my criticism of ISC Root DNS operation and
deployment of the Anycast Extension, and I think that the IESG should address
the abuse of WG Chair privileges by the Mr. Kessens, and consider the failures
of the WG chairs to properly criticize actual abuse.  Kessens is not the only
abuser.

Kessens further claims falsely below that I "immediately followed up by sending
more abusive mails to the dnsop and ietf mail lists".  Plainly, there is nothing
abusive about complaining about Kessens' threats, nor is there anything abusive
about defending my criticisms as being valid, justified, and appropriate to the
DNSOP list. Plainly, my complaint about Kessens' behavior to the IETF list is an
administrative issue, and so it is within the administrative purpose of the main
IETF list. There is nothing abusive about that.

However, this is not to say that abuse isn't happening. Besides Mr. Kessens'
instant abuse of his position, there is a history of unchecked abuse against
myself and others, including Dr. Dan Bernstein, who have been abused several
times on the IETF main list as well as a particular pattern of disruption on the
DNSOP and DNSEXT lists.

>From RFC 3683:

   Notably, in a small number of cases, a participant has engaged in
   what amounts to a "denial-of-service" attack to disrupt the
   consensus-driven process.  Typically, these attacks are made by
   repeatedly posting messages that are off-topic, inflammatory, or
   otherwise counter-productive.  In contrast, good faith disagreement
   is a healthy part of the consensus-driven process.

My activity hasn't been disruptive of any IETF activity. In fact, Mr. Kessens'
complaint is plainly meant to disrupt consideration of my (but not just mine)  
valid technical criticism.  The only possible disruption is to ISC financial
income from selling Anycast DNS Root services.  But since the technical
contributions of myself, Dan Bernstein, Iljitsch van Beijnum and others is that
those services can't work in general, the IETF DNSOP WG has an obligation to
investigate and discuss that.

However, there has been much disruptive behavior by others especially on the
subject of the ISC Anycast Extension. Activity that is clearly intended to
disrupt or even deny email service. Here is a short list:

In 2002, after Dr. Bernstein reported on the DNSEXT list about the ISC Anycast
Extension described by ISC in a presentation to Nanog, his subscription address
was posted by Randy Bush (then DNSEXT WG chair) on several occasions to the
DNSEXT list.  The enabled forged unsubscriptions of his email address,
disrupting Dr. Bernstein's email subscription. The posting of the unsubscription
address only happened to Dr. Bernstein. This eventually disrupted the discussion
of the ISC Anycast Extension, as discussion turned to the abuse of Dr.
Bernstein.  This is plainly a violation of IETF rules on participation.  Bush
stepped down as WG chair afterward, and many including myself thought that this
was a punishment. However, Harald Alvestrand informed me in his role as IETF
Chair that Bush was not punished. So no action was ever taken for this abuse.

Other incidents happened, generally involving Nanog participants and
ISC-friendly people. For example:

The 2002 Nanog Presentation on Anycast Extension was made by ISC Project Manager
Suzanne Woolf. In September, 2004, on the subject of the ISC Anycast Extension,
John Brown made a vicious personal attack on the DNSOP list against Dean
Anderson. A complaint was made to DNSOP and the IETF main list on September 30,
2004.  In his attack, Brown claimed no affiliation with ISC:

"...I felt it important to reply as someone thats NOT in
any shape fashion or form, ISC or its staff"  --John Brown.

It turned out that Brown was involved with Suzanne Woolf in at least
Chagres.net, at the time. The same Woolf who was in charge of the Anycast
Extension at ISC.  Still, non-affiliation doesn't justify unwarranted personal
attacks, but affiliation and false claims of non-affiliation certainly makes
those attacks look more self-serving.  No action was ever taken by the IETF or
by the DNSOP WG chair in res

Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]

[Dean Anderson]

On Sat, 24 Sep 2005, Steven M. Bellovin wrote:
> I'm sorry, David's note wasn't an "attack" -- it was David excercising 
> his responsibility as an AD.  Have a look at Section 2 of RFC 3683 -- 
> to revoke someone's posting rights, he *must* make a public statement 
> on the IETF mailing list.

Kessens offlist email was a threat. 

Kessens only made the complaint in revenge for my administrative complaint 
about 
his threat.

Kessens complaint, being unjustified revenge, is an attack.

But lets not forget, Mr. Bellovin, just last week you reported in your offical
capacity as Chair of the IPR WG on the contents of a message of mine involving
patent policy. You reported that my message was wrong, and at the end noted you
hadn't even read my message.

Mr. Bellovin: you are a research scientist at a respected institution, and you
know very well that if you haven't read a document, you can't honestly comment
on its contents.

I am still waiting for your honest acknowledgment that my message was not wrong,
and for you to acknowledge honestly as Chair of the IPR Working Group that the
IETF policy is to prefer non-encumbered technology as documented in RFC3979
Section 8.

--Dean
-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Mismanagement of the DNSOP list

[Dean Anderson]

FYI: I am being threatened for posting operationally relevant criticism of 
mis-operation of the F DNS Root server on the DNSOP list.



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


-- Forwarded message --
Date: Fri, 23 Sep 2005 15:55:20 -0700
From: David Kessens <[EMAIL PROTECTED]>
To: Dean Anderson <[EMAIL PROTECTED]>
Cc: David Meyer <[EMAIL PROTECTED]>, Rob Austein <[EMAIL PROTECTED]>,
 Bert Wijnen <[EMAIL PROTECTED]>
Subject: [EMAIL PROTECTED]: Re: [dnsop] An attack that DNSSEC would
have defended against...]


Dean,

To avoid any misunderstandings: My message is an official warning to
you that I will propose to the IESG to remove your posting privileges
if I see one more abusive mail from you.

Thanks,

David Kessens
---

- Forwarded message from David Kessens <[EMAIL PROTECTED]> -

Date: Fri, 23 Sep 2005 15:36:11 -0700
From: David Kessens <[EMAIL PROTECTED]>
To: Dean Anderson <[EMAIL PROTECTED]>
Cc: Harald Tveit Alvestrand <[EMAIL PROTECTED]>, dnsop@lists.uoregon.edu
Subject: Re: [dnsop] An attack that DNSSEC would have defended against...

Dean,

You are welcome to post to this list if you have DNS operational
issues to discuss.

Any issues that you might have with ISC are outside the charter of
this working group and I would like to request you to take them up
privately with ISC. 

Thanks,

David Kessens
---

On Fri, Sep 23, 2005 at 06:09:23PM -0400, Dean Anderson wrote:
> Harald, you may be right about DNSSEC protecting from this. I haven't looked 
> at
> your data, yet. However, you probably aren't about to be very well protected 
> by
> DNSSEC, despite the progress of specifications on DNSEXT.
> 
> DNSSEC isn't deployable on F-root nor the other anycast'ed* roots, nor a lot 
> of
> other anycast'ed non-root servers.  DNS servers with the Anycast Extension are
> increasingly popular due to suppression of discussion of negative aspects of 
> the
> Anycast Extension on forums such as Nanog as recently as May, 2005 because 
> only
> information that promotes ISC's view is allowed on Nanog, misleading network
> operators about the Anycast Extension.  Many root server operators accepted
> ISC's assurances as an unofficial IETF liason and deployed Anycast Extension 
> on
> production servers and on root servers in violation of RFC 2870**. They appear
> not to have understood that they were deploying an untested, undocumented, and
> unapproved Anycast Extension.
> 
> And despite substantiated criticism on DNSEXT and DNSOP by persons including 
> Dan
> Bernstein, Iljitsch van Beijnum, Dean Anderson, and others since the 2002 
> Nanog
> presentation by ISC, ISC has not yet even publicly acknowledged the problems
> with the Anycast Extension, and continues to promote the extension as 
> completely
> safe. ISC even describes it to prospective customers as "uncontroversial",
> despite the controversies on DNSEXT, DNSOP, and Nanog beginning after the 
> Nanog
> presentation in 2002.  
> 
> The Anycast Extension is now proposed to the GROW working group some 3 years
> after being described to Nanog as operationally safe and stable.  At present,
> the Anycast Extension proposal appears to be dead or dying on both DNSOP and
> GROW WGs because of evidence that it can't work in general, and the 
> specialized
> conditions where it can work are uninteresting to the current users such as 
> root
> DNS operators and other DNS operators, and thus uninteresting to ISC.
> 
> The only reason there are no present complaints with root operations is that 
> DNS
> is mostly still stateless small UDP packets, reducing to RFC 1546 Anycast***,
> which works fine with stateless small UDP packets. And it may well be that 
> those
> working on DNSSEC testing comply with the assumptions stated on the Anycast
> Extension.
> 
> So the question is when will F-root and other roots be able to handle TCP and
> large UDP packets from any internet host, including those hosts serviced by
> networks that use fine-grained load-splitting as described by RFC1812?.  When
> will operators be informed of these problems by ISC?
> 
> Critics of these problems, particularly Dan Bernstein and Dean Anderson, have
> been attacked personally by persons generally associated with ISC or friendly 
> to
> ISC with no remedial action by the respective organizations (IETF and Nanog) 
> in
> spite of well-documented complaints.  Uncontrolled personal corruption at the
> IETF and Nanog appears to be preventing actual progress.
> 
> --Dean
> 
> [* the Anycast Extension
> http://www.ietf.org/internet-drafts/draft-ietf-g

Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion] (fwd)

[Dean Anderson]

Before we are too distracted by personal attacks on me**, could we please
consider the issues contained in the forwarded message.  I think the first
thing should be to direct the DNSEXT WG Chairs to stimulate discussion of
IPR issues rather than ask it to stop, and for them to get IPR disclosure
statement(s) on draft-ietf-dnsext-ecc-key-07.

[**Please ignore the personal attacks on me for the moment. I will get
around to posting formal complaints on a violation of the IETF and ISOC
Codes of Conduct, as I have in other cases.  No doubt, for the short term
at least, these complaints will get the same action as Alvestrand's and
Vixie's namecalling of me, the abuse of Dr. Bernstein, the abuse of Nick
Strand, and the abuse of others too numerous to list. Though the abusers
in these cases are much easier to enumerate. Someday we will have to
address the issues of professional honesty and professional ethics and
such. In the meantime, we document it.  As with defamation, this abuse
eventually results in more harm to the abuser than to the abused. Time is
on our side.]

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   


-- Forwarded message --
Date: Thu, 8 Sep 2005 16:21:52 -0400 (EDT)
From: Dean Anderson <[EMAIL PROTECTED]>
To: Olaf M. Kolkman <[EMAIL PROTECTED]>
Cc: namedroppers@ops.ietf.org, ietf@ietf.org
Subject: Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied
discussion]

[CC'd to the main IETF list]

[Note:  Not very long ago, I argued persuasively to a large and broad
movement within the IETF seeking to have the IETF adopt an anti-patent
position. I took my position pragmatically on the basis that the IETF
should consider patented technology intelligently on a case-by-case basis
in order to ensure participation by pro-patent groups and organizations
whose cooperation is necessary and beneficial to the IETF. This is a
pragmatic and reasonable view;  The IETF interests in patented technology
are different from my ideological interests in abolishing software
patents, even if those interests have broad support. Interoperable
standards are more important than ideology.  Placing interoperation ahead
of ideological interests, I saw the value in having participation and
cooperation on standards regardless of ideological differences.  However,
having persuaded people to take a pragmatic and cooperative view,
pro-patent persons shouldn't try to exploit that cooperation by attempting
to prevent or suppress consideration of IPR issues by working groups.]

The statement of the WG chair (included below) is not consistent with the
IETF rules on IPR disclosure and consideration.

For your reference: RFC 3979:

6.1.1.  A Contributor's IPR in his or her Contribution

   Any Contributor who reasonably and personally knows of IPR meeting
   the conditions of Section 6.6 which the Contributor believes Covers
   or may ultimately Cover his or her Contribution, or which the
   Contributor reasonably and personally knows his or her employer or
   sponsor may assert against Implementing Technologies based on such
   Contribution, must make a disclosure in accordance with this Section
   6.

   This requirement specifically includes Contributions that are made by
   any means including electronic or spoken comments, unless the latter
   are rejected from consideration before a disclosure could reasonably
   be submitted.  An IPR discloser is requested to withdraw a previous
   disclosure if a revised Contribution negates the previous IPR
   disclosure, or to amend a previous disclosure if a revised
   Contribution substantially alters the previous disclosure.

   Contributors must disclose IPR meeting the description in this
   section; there are no exceptions to this rule.


The fact that a discussion may be legal in nature is of no relevance. We
live in a professional world bounded by legal constraints. The working
group must ensure that IETF requirements on IPR disclosure are met, and
that IPR encumbrances are properly and fully considered by the working
group participants in the selection of technology.  Patent encumbrance is
a valid basis for comparison of any proposal. And IPR encumbrance is in
fact not limited mere comparison, but even whether to adopt a given
technology at all; Rejection because of IPR encumbrance is a valid option 
to be decided on a case-by-case basis.



I do not see that the WG Chair is allowed by IETF policy to exclude or
suppress information or discussion about IPR encumbrance, which seems to
be the purpose of suppressing this discussion. This is contrary to IETF
policy, which is to have each WG intelligently consider IPR issues.



Also, the WG chair makes mention of two documents. In fact, there are 3
documents noted in the minutes which seem to have IPR encumbrances:

Two are reported in the minutes under the heading of "IPR Issues upd

Re: Was: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion]

[Dean Anderson]

On Fri, 9 Sep 2005, Frank Ellermann wrote:

> Dave Crocker wrote:
>  
> > I've lost track of the procedures for formally taking
> > exception to ad hominem attacks
> 
> You have collected the related documents on this page:
> 
> 
> Maybe add 3683 (BCP 83) to the collection, just in case.
> 
> If something with the references in the SPF or SID RfCs
> is wrong I'm sure that the authors would like to know it.

The SPF/RMX credit problem was corrected, after a contentious debate, and
only after complaint to the main IETF list by Hadmut Danisch.

> But whatever that might be, this can't be your fault, by
> no stretch of imagination.

The SPF issue was not Dave Crocker's personal fault.  I raised the SPF
issue because it reflects a pattern of trying to shift credit where it
isn't due. Crocker's most recent attack on me, refusing to credit my
contributions to pragmatic compromise and cooperation are further evidence
of a pattern of behavior by Mr. Crocker and associates.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion]

[Dean Anderson]

On Thu, 8 Sep 2005, Dave Crocker wrote:

> Folks,
> 
> I've lost track of the procedures for formally taking exception to ad hominem 
> attacks, but I think we (the IETF) are overdue in needing to get quite strict 
> about enforcing that requirement, and doing the enforcement in a timely 
> fashion.l

I agree entirely.

> We simply must purge patterns of personal abuse out of our public discussions 
> and start requiring professional demeanor.

Yes, as the target of repeated personal abuse, I completely agree. 

However, you are one of the abusers.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion]

[Dean Anderson]

On Thu, 8 Sep 2005, william(at)elan.net wrote:

> Neverheless if I understand it, it has always been a position of IETF
> to consider patented technology as being less preferable then patented
> for standardization (ok, it also has a lot to do with kind of licese
> patened technology has and if its available to everyone's use or not)
> and that in case standardization of certain patented technology is
> being considered IETF should look at if alternative to it that is
> non-patented is available.

The IETF position has gone from what might be described as studious
neutrality (ie you may consider things such as licensing terms) to a
definite preference for non-encumbrance. (Section 8 of RFC 3979):

8.  Evaluating Alternative Technologies in IETF Working Groups

   In general, IETF working groups prefer technologies with no known IPR
   claims or, for technologies with claims against them, an offer of
   royalty-free licensing.  

I think many people at the IETF have no-IPR preferences, but it wasn't
written explicitly as a policy anywhere that I know of prior to RFC3979

> What Dean wrote makes lots of sense to me, so I primarily agree with
> him, except for his typical dnsext chair bashing - I'm not sure there
> is really a case there that chair is blocking discussion. I do agree

Olaf Kolkman (WG co-chair) said:  

>Message-Id: <[EMAIL PROTECTED]>
[...]
> "Rat Hole Alert" [*]
>
> Please stop this discussion.
 
Doesn't get plainer.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   







___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion]

[Dean Anderson]

On Thu, 8 Sep 2005, Steven M. Bellovin wrote:

> In message <[EMAIL PROTECTED]>, "william(at)elan
> .net" writes:
> >
> >On Thu, 8 Sep 2005, Dave Crocker wrote:
> >
> >>> [Note:  Not very long ago, I argued persuasively to a large and broad
> >>> movement within the IETF seeking to have the IETF adopt an anti-patent
> >>> position. 
> >>
> >> my memory is slipping worse that I thought.
> >> i don't recall seeing evidence of the community's being persuaded.
> 
> It wasn't -- he's wrong.

I see: I'm wrong, but you didn't see the original note.  How thorough of
you.  Sounds more like: "Crocker is right, no matter what".

> Wearing my IPR WG hat and citing a product of that WG...

Maybe if you are going to make official statements, you could do a more
thorough job of consulting both the statements being made, and your RFCs.  
I just cited RFC3979, a more recent product of your working group. But
nothing I said was in contradiction to RFC3669, either. Not that you 
bothered to read it before commenting.

[Didn't I just say something about fabrication of statements and
professional dishonesty...]

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion]

[Dean Anderson]

Mr Crocker. I know you'd rather not give credit to anyone you disagree
with, which I suppose leaves only a preference to plagarize the work of
others and give undue credit to someone else, say, Vixie [ala the SPF/RMX
plagarism in which Vixie was improperly credited for the idea and the real
contributors and the originator of the idea were improperly removed***].  
However:

Since we [the anti-software-patent community -- and the LPF President is
an acknowledged leader of that community] mostly collectively dropped the
demand for no patents in lieu of a much more pragmatic and cooperative
view, a view that I originated and promoted, I think I can say they were
persuaded.

Of course, that must be very jarring to your world in which I represent no
one else's view, and have no valid point of view on any subject with which
you disagree.  And indeed, I would be unsurprised if your world does not
admit that I have a valid point of view even on any subject on which we
_do_ happen to agree.  I hope I don't rattle your world too much. Or
perhaps in your world, the IETF has already adopted a strict no-patent
policy. I couldn't tell. How'd that no-patent policy work out in your
world?  Did it alienate any pro-patent companies?

--Dean

*** The SPF/RMX issue is just one example of professional dishonesty.  
Professional dishonesty is very much like academic dishonesty.  The IETF
is supposed to be a professional organization, an activity of The Internet
Society, which is a professional organization.  Improper attribution of
statements or plagarism, theft of ideas, etc in a referee'd paper would
not be acceptable in any professional or scientific journal. Plagarism,
theft of ideas, fabrication of statements, etc is unacceptable, under the
category of professional dishonesty. Particularly in official interactions
by the leadership of the IETF.  Academic dishonesty is grounds for
expulsion from higher educational institutions. Yet, professional
dishonesty at the IETF is grounds for...exactly nothing. It is hard to
consider the IETF a professional organization since it adheres to no
professional standards.  We shouldn't forget this, but it isn't my focus
at the moment. Someday, this issue should be addressed.

On Thu, 8 Sep 2005, Dave Crocker wrote:

> 
> 
> > [Note:  Not very long ago, I argued persuasively to a large and broad
> > movement within the IETF seeking to have the IETF adopt an anti-patent
> > position. 
> 
> 
> my memory is slipping worse that I thought.
> 
> i don't recall seeing evidence of the community's being persuaded.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: DNSEXT Minutes @ IETF-63 [Software Patent issues denied discussion]

[Dean Anderson]

 of non-infringement to be credible.  An IPR disclosure should
be made on this document. According to RFC 3979, Section 6.1.1 "there are
no exceptions to this rule".  Further, the IETF is not to take any
position on the validity of an IPR claim. The IETF can't ignore the claim
as being invalid--that would be taking a position on its validity.  The
claim has to be documented and disclosed, even if it may not be valid.

And also, the working group chairs should be directed to _encourage_
discussion and consideration of the IPR issues, not try to suppress the
discussion.

Note RFC 3979 Section 6.2:
6.2.  The Timing of Providing Disclosure

   Timely IPR disclosure is important because working groups need to
   have as much information as they can while they are evaluating
   alternative solutions.

If the WG chairs are working to suppress IPR information and discussion,
it is not available for evaluation, in violation of the purpose of section
6.2.

Dean Anderson
President of the League for Programming Freedom.




On Wed, 7 Sep 2005, Olaf M. Kolkman wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> "Rat Hole Alert" [*]
> 
> Please stop this discussion.
> 
> For this working group the only relevance at this point is rough  
> consensus on the technical specification and running code. We have  
> neither at this point in time.
> 
> Lets get back to the technical task at hand. Compare the two proposals.
> 
> - --Olaf
> 
> 
> [*] http://ops.ietf.org/lists/namedroppers/namedroppers.2005/ 
> msg00381.html
> 
> > We want to issue is a "rat hole" alert:
> > Working groups tend to discuss the validity of patent claims, the
> > licensing terms and such at great lengths. In the end patent issues
> > are not technical but legal issues. It is up to the implementors of
> > technology under IPR to deal with these issues, not the working group.
> > If the IPR prohibits implementation than the WG would like to know,
> > from implementors. As rough consensus without running code does not  
> > make sense.
> >
> > Or to paraphrase the above: we all have an opinion on IPR, this
> > is not the list to rehash those.
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (Darwin)
> Comment: This message is locally signed.
> 
> iD8DBQFDH0yntN/ca3YJIocRAsn8AKCk1l4ZqCW/OenPsgcFWGUBWC42HQCgujeK
> jWRDXuu83+1FIWVP96Mzi4g=
> =9z4g
> -END PGP SIGNATURE-
> 
> --
> to unsubscribe send a message to [EMAIL PROTECTED] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   








___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

A Complaint to the IETF and IESG (was Re: Please change the Subject: when you change the subject [Re: Sarcarm and intimidation])

[Dean Anderson]

I haven't changed the subject. The correct subject is "sarcasm and
intimidation". I have just provided specific examples of "sarcasm and
intimidation" that have happened while working on spam issues for the
IETF. Those specific exmaples fall under the topic of the subject header.
Your complaint about subject change is frivolous.

Nor am I playing rhetorical games with Noel Chiappa. I asked him a direct,
relevant, specific question, and he didn't answer it. Instead he gave me a
sarcastic, frivolous, and irrelevant response.  The original story Chiappa
gave about "Parry meets the Doctor" is often cited to mean: "Did I give
you the impression I cared about your feelings?", which means that they
don't care what you think. This is sarcasm, and is exactly what
Hallam-Baker started to complain about under the topic "sarcasm and
intimidation".

The recent behavior by Carpenter and Chiappa has rather proved the point
by Hallam-Baker, myself, and others.  The frivolous complaints about
message topic give the impression of intimidation. And I feel intimidated
by the Chair's insistence on squelching the topic of "sarcasm and
intimidation" and specifically any examples of sarcasm and intimidation
involving IETF work on spam.  So do others.  This is inappropriate
behavior by the current Chair, and by former IESG members.

It is rather amazing that someone (a former IESG Member!)  would be so
brazen as to be sarcastic during a complaint about sarcasm and
intimidation.  Plainly, they seem to feel a right to be sarcastic. But I
find no such right in the IETF or ISOC Code of Conduct, nor in the Mission
Statement of the IETF.  Just the opposite: One is expected to be courteous
and respectful, and sarcasm is neither courteous nor respectful.

A complaint on this inappropriate behavior is hereby brought to the
attention of the IESG.

Dean Anderson
President
Av8 Internet, Inc

On Fri, 22 Jul 2005, Brian E Carpenter wrote:

> ...
> > Does this mean that you think the IETF should disband the ASRG, drop all
> > current I-D's relating to spam, and quit working on spam issues?  
> 
> What I think is that if you change the subject, you should change
> the Subject:, so that people who might be interested in "Sarcarm
> and intimidation" but aren't interested in "Spam" don't waste their
> time.
> 
> Brian
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Sarcarm and intimidation

[Dean Anderson]

On Thu, 21 Jul 2005, Noel Chiappa wrote:

> > From: Dean Anderson <[EMAIL PROTECTED]>
> 
> >> Anyway, I hereby propose the IETF Corollary to Godwin's Law: whenever
> >> any IETF thread migrates to the subject of spam, it's time to end the
> >> thread.
> 
> > Does this mean that you think the IETF should disband the ASRG, drop
> > all current I-D's relating to spam, and quit working on spam issues?
> > ... if Chiappa genuinely thinks the IETF should stop spam work, he
> > should say so directly, so as to be clearly understood.
> > .. if the IETF is going to work on spam, then occasionally the main IETF
> > list will have to discuss the issue
> 
> You seem to have missed the word "migrate" in my post.

I see.  I thought you were talking about the current thread, not some
hypothetical migration of some other thread. 

Hallam-Baker started the current thread to complain about sarcasm and
intimidation relating to anti-spam efforts. And there clearly is
intimidation. The current thread did not migrate; hence I mistook your
comments as being somehow relevant to the current thread.

It is too bad you didn't take the opportunity to clear up the ambiguity of
whether you want the IETF to stop work on spam issues.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Sarcarm and intimidation

[Dean Anderson]

On Thu, 21 Jul 2005, Noel Chiappa wrote:

> > From: Dean Anderson <[EMAIL PROTECTED]>
> 
> > Hallam-Baker is active in anti-spam issues.
> 
> Wow. I've just had a major "cognition", as Scientology members would say. I
> assume everyone's read "Parry meets The Doctor"? Nuff' said.

Probably not everyone gets "Parry meets the Doctor"

I couldn't find the article by Vint Cerf online [Cerf, Vinton, "PARRY
meets THE DOCTOR", DATAMATION, pages 62-64, July, 1973.] [BTW, The Doctor
is the Eliza program]

Excerpt from 
http://www2.mit.bme.hu/services/vimm3241/tanul/beadott/regi/BenkoKatona/extra_eng.html
does it pretty well:

===

Parry meets the Doctor

There are many other programs that cannot communicate so sophisticated
like SHRDLU. The Doctor was created to simulate the "non-controlled
therapy" of psychiatrists and Parry's task is to simulate a paranoid's
misthoughts. A confrontation of these two programs was arranged on a
computer network.  This is the a short part of the conversation log:

Parry: I don't understand your motivations. Doctor: Why don't you 
understand my motiwations? P: Shall I understand? D: Now why do you say 
this? P: Because it's exactly the way it isn't. D: Let's suppose it's 
exactly not that way. P: And? D: I guess I don't really understand you. P: 
You're stuck at the same question. D: What consequence do you make of this 
similarity? P: I really can't see where you're intending to get into. D: 
You want me to get into something? P: It's time to show a little bit of 
interest in direction of my feelings. D: Oh! Have I shown interest of your 
feelings?

These programs were designed to have conversations width real people and 
so they are expecting that the living "partners" are going to give much 
useless information which is not really meaningful in the context. And 
there it was: the Doctor rose the illusion that "he" really understood the 
conversational partners - the people who talked with the Doctor said this. 

===

If you have no interest in spam, why do you keep making such posts?

> Anyway, I hereby propose the IETF Corollary to Godwin's Law: whenever any
> IETF thread migrates to the subject of spam, it's time to end the thread.

Does this mean that you think the IETF should disband the ASRG, drop all
current I-D's relating to spam, and quit working on spam issues?  I rather
doubt that Chiappa genuinely doesn't want the IETF to work on spam issues,
[at least that's not my perception of his comments] but instead means only
to disparage the current discussion. But if Chiappa genuinely thinks the
IETF should stop spam work, he should say so directly, so as to be clearly
understood.

But if the IETF is going to work on spam, then occasionally the main IETF
list will have to discuss the issue, and also discuss the administrative
issues that arise from the discussions.


--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Sarcarm and intimidation

[Dean Anderson]

On Thu, 21 Jul 2005, Hallam-Baker, Phillip wrote:
> 
> The problem is at least made worse by the fact that the first thing that
> happens when a focussed proposal is made people start saying 'That is no
> good, the [bad guys] will just do X'.

Often, it has actually been the case that the bad guys just did X, which
was obviously possible beforehand.  We went to great expense for nothing.  
Why didn't anyone think about what the bad guys could do?  [we tend to
characterize such obviously failing schemes as hair-brained, (or perhaps
"hare-brained" for the rabbit-watchers), but this is probably unfair in
some respects. An honest and direct answer is appropriate.]

You can't fight spam on the assumption that abusers can't change. But
nearly every anti-spam proposal does just that.  That is, if it has any
rationale about how it will affect spam or anyone at all.  Anyone who
suggests that the abuser can simply do X is generally not well received.  
For example The email authentication scheme promoters don't even consider
reactions or ill-effects. They just take it as given that spam will be
prevented if we have authentication.  But even perfect authentication
would have no effect on spam. [skip the details, assume users are
perfectly authenticated, then ask "so what?"] A very expensive
authentication system doesn't even require much change to what spammers do
now.  Yet the "best technical minds of the IETF" don't agree with this. Or
rather, just ignore the "so what?" part.  That isn't engineering, that's
just amateurish experimentation at our expense, and perhaps their profit.

Of course, if you take that analysis of channel usage to its logical end,
one will find that you can't prevent spam. Or more specifically, can't
secure a communication channel against topically inappropriate messages.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Sarcarm and intimidation

[Dean Anderson]

Hallam-Baker is active in anti-spam issues.  More inline.

On Wed, 20 Jul 2005, Iljitsch van Beijnum wrote:

> > I am sure the majority of the people in this forum would prefer to
> > look at ways of securing the Internet to protect against the real
> > internet criminals stealing pensioners' life savings
> 
> ???
>
> How can you secure a communication channel against crime in general?

They can't. Information Theory (covert channels et al) shows its
impossible.  This fact does not deter anti-spammers in anyway from saying
they can and will "if only they'd get cooperation".  They've known about
the theoretical impossibility since 2003 from me, at least, not counting
the actual experience of failure of every scheme conceived over a ten+
year period.  Anti-spam is a whackamole game, and information theory shows
it will always be a whackamole game.

Hallam-Baker responded to this question and offered "proof" the internet
can be so secured:

  >Accountability.
  >
  >They did it for the telephone system in the 1920s
  >
  >We can do it for the Intetnet.

Another innaccuracy. We still have telephone fraud today. Catching
telephone fraud is also still (similarly) a "whackamole" game.  They only
thing they did was start looking for fraud and trying to catch and
prosecute it. That process still continues. Telephone fraud is not
__prevented__. It is merely detered by penalties, like most crimes against
civil society.  Indeed, the telephone system is mostly "open relay", with
relatively little user pre-authentication (calling cards).  Fraud is
detected post-use, from call detail records (ie logs), just like open
relay and other kinds of abuse. [And I think you can read "telephone
fraud" in my statements here as meaning either "unauthorized calls", or as
"scams conducted over the telephone", or just about anything else that
would qualify as a crime the telephone system is somehow supposedly secure
against.]

> If you expect the IETF to stop pensioner savings stealing, you're  
> setting yourself up for a big disappointment.

Right.  Exactly.  Yet we still have IETF people promisng they are going to
stop spam through expensive, patented email authentication systems.  
That's just complete nonsense.  If only it were a simple mistake on their
part, but it isn't simply a mistake.  A great deal of money is involved.  
And lies, defamation, and intimidation against anyone who speaks against
it.

However, there is certainly intimidation by the IETF. I've experienced it
from former IESG members Dave Crocker and Noel Chiappa just recently.  
And public hostility from Harald Alvestrand (former IETF chair).  I've
experienced retribution in the form that IETF leaders who refuse to
chastise plainly ad hominem attacks on people with unpopular views. I've
experienced undeclared conflicts of interest by working group chairs. I've
even experienced the Sergeant of Arms using his official role to argue
merits of an Internet Draft [message: don't disagree on the draft or else]
in front of the current chair, who did nothing, even after I commented on
the irrelevance of the I-D argument made by the Sergeant at Arms Ted T'so.  
Carpenter (IETF Chair) told Nick Staff his views were a waste of time.

There are many people on several sides of the spam argument: Those who
agree with me (no technical solution), and those who agree with
Hallam-Baker (technical solutions) (not that either of us are speakers for
the respective sides), and the pro-spam viewpoint is entirely
unrepresented. But I haven't seen any intimidation of Hallam-Baker's side
at the IETF.  If it is there on working groups, it hasn't been
specifically brought to the attention of the ietf list.  Hallam-Baker's
posts on the current thread seems more to do with facts of disagreement
rather than evidence of misbehavior in communicating those facts.  If
there is intimidation of Hallam-Baker, I'm against the intimidation. His
side has a right to make their case. My side has a right to show why its
wrong.

But there is some evidence of misbehavior against myself and my views, and
others who share those views, as I outlined above.

It is most interesting that Crocker and Alvestrand want to have a new AUP.  
They are among the intimidators. The leaderhip can't fairly enforce the
current rules without bias against unpopular viewpoints or "irritating"
people. An additional AUP is just more for them to abuse.


--Dean

[it is an interesting asside that "irritating" is often used agains those
who are correct, but their information is unwanted. For example, a crowd
catches a known criminal, and wants to lynch the criminal, but one person
stands up and says he should be tried in court. That person is
"irritating".  But engineering isn't a popularity contest. "Irritating" is
a fact one may have to simply accept.]

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   






_

Re: I'm not going to listen to this any more.

[Dean Anderson]

On Thu, 30 Jun 2005, Theodore Ts'o wrote:

>   Calling someone a "lair" is making a claim that they are
> knowingly stating a falsehood.  

That is correct. Fortunately, there is a legal procedure to redress a
"knowing falsehood": It's called defamation. A "court-proven liar" is
someone who has been found responsible in defamation lawsuit.  That's what
it means to be guilty of defamation: To have knowingly stated a falsehood.

> However, making assumptions about another person's motivations is never
> a good thing to do if you are trying to promote conversation.

I make no assumptions. The Judge in a court of law has already
investigated that person's motivations: They were seeking financial gain.

>   They may have observed a different set of facts in their
> geography or in the circles they frequent; they may see a few cases
> which you consider to be highly important which they classify as
> unimportant exceptions; they may simply be mistaken.

Truth is an absolute defense to defamation.  If they spoke truth, they
wouldn't lose defamation lawsuits.  Simple mistakes are not usually
sufficient for a defamation lawsuits.

>   Instead of writing a treatise about lairs and defamtion law,
> it would have helped moved the debate forward if you had written what
> you have observed, why you think it is an important indicator, and

I'm not writing a hypothetical treatise on defamation.  

If you want in terms of "observation": I observed people found responsible
(guilty) in defamation lawsuits, not just once but multiple times, where
the false statements involved open-relays.

This is important to the discussion of an RFC under consideration by the
IETF, because the RFC has statements predicated on claims of people found
in court to be lying on the subject of open relays for financial gain, and
their associates. Supportors of the RFC have offered similar statements,
similarly predicated.

These facts are fairly well-known, I think, unless you have never heard of
ORBS or SORBS.

My statement that Harald found "irritating" is also true, but not specific
to ORBS.  It is an axiom of civil society which applies to the IETF. Here
it is again:

> The IETF cannot accept the statements of known, court-proven liars, nor
> can it suppress this fact in its deliberations.  If the IETF accepts
> court-proven and documented liars as reliable sources of fact, then it
> will have no more credibility in its statements, as they will be based
> on lies, not on truth.

Plainly, those who don't accept the axioms of civil society are by
definition uncivil.  Such axioms should not be irritating. 


--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I'm not going to listen to this any more.

[Dean Anderson]

On Thu, 30 Jun 2005, Brian E Carpenter wrote:

> Dean,
> 
> Please stop repeating assertions about alleged liars.

I haven't made any assertions about "alleged" liars. I have brought
attention to statements of _court-proven_ liars.  That is, those people
who have made false statements, have been sued for defamation, and have
lost those lawsuits. Having lost a defamation lawsuit establishes the
_fact_ of their lying.

It is inappropriate and against the IETF rules for the Chair to try to
suppress facts.  You should consult with the IETF attorney on the matter.

Dean Anderson
Av8 Internet, Inc



> Sergeants-at-arms, please pay attention since I believe that we
> may need to consider action if this continues.
> 
> Brian
> 
> Dean Anderson wrote:
> > On Mon, 27 Jun 2005, Dave Crocker wrote:
> > 
> >>>>I thought we also had a mechanism for taking action against posters who 
> >>>>violate list policy egregiously.
> >>>
> >>>As one of the IETF list's "sargent at arms", I certainly don't see
> >>>Harald's one-time, single line posting as being egregious in any shape
> >>>or form.  I also didn't see it as a personal attack.
> >>
> >>sorry for the badly written note.  i was trying to focus on getting the 
> >>procedure used, not specify who it should be used against.
> >>
> >>harald's posting was not what i considered to be egregious.
> > 
> > 
> > Since when are _true_ facts about liars on a subject (open relays)  
> > discussed in an IETF RFC, egregious?  Is it against list policy to assert
> > that the IETF should be honest, and not associate with liars?  I missed
> > that part. Perhaps you could be so kind as to point it out?
> > 
> > Your beef is with reality.  I didn't create the facts, I'm just the
> > messenger. The people who created the facts of their lies (by lying)
> > thought, like some others, that lies will never return to haunt them.  Of
> > course, that's what reputation is about: the return of past misdeeds.  
> > Associate with liars, and people will say you associate with liars. 
> > Reasonable, civil, rational people won't trust liars nor their associates.
> > Accountability is harsh.
> > 
> > I wrote this for another purpose, but its appropriate here:
> > 
> > Defamation sometimes results in a short term gain for the defamer, and a
> > short term loss for the defamed.  But, given time, it always results in a
> > long term loss for the defamer and a long term gain for the defamed.  Be
> > patient, but don't forget.
> > 
> > Before 1720, British defamation law didn't permit truth as a defense
> > against defamation. In fact, if the defamatory claims were true, common
> > law made the penalty worse because, as the courts reasoned before the 18th
> > century, truth was far more damaging than lies.  But around 1720, 2 people
> > writing under the pseudonym Cato argued that truth should be an defense
> > against defamation. They were subsequently sued for defamation for
> > revealing disparaging true facts. They won. Since then, truth has been an
> > absolute defense against defamation.  
> > 
> > It is remarkable that truth is more damaging than lies.
> > 
> > --Dean
> > 
> 
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I'm not going to listen to this any more.

[Dean Anderson]

On Mon, 27 Jun 2005, Dave Crocker wrote:
> >>I thought we also had a mechanism for taking action against posters who 
> >>violate list policy egregiously.
> > 
> > As one of the IETF list's "sargent at arms", I certainly don't see
> > Harald's one-time, single line posting as being egregious in any shape
> > or form.  I also didn't see it as a personal attack.
> 
> sorry for the badly written note.  i was trying to focus on getting the 
> procedure used, not specify who it should be used against.
> 
> harald's posting was not what i considered to be egregious.

Since when are _true_ facts about liars on a subject (open relays)  
discussed in an IETF RFC, egregious?  Is it against list policy to assert
that the IETF should be honest, and not associate with liars?  I missed
that part. Perhaps you could be so kind as to point it out?

Your beef is with reality.  I didn't create the facts, I'm just the
messenger. The people who created the facts of their lies (by lying)
thought, like some others, that lies will never return to haunt them.  Of
course, that's what reputation is about: the return of past misdeeds.  
Associate with liars, and people will say you associate with liars. 
Reasonable, civil, rational people won't trust liars nor their associates.
Accountability is harsh.

I wrote this for another purpose, but its appropriate here:

Defamation sometimes results in a short term gain for the defamer, and a
short term loss for the defamed.  But, given time, it always results in a
long term loss for the defamer and a long term gain for the defamed.  Be
patient, but don't forget.

Before 1720, British defamation law didn't permit truth as a defense
against defamation. In fact, if the defamatory claims were true, common
law made the penalty worse because, as the courts reasoned before the 18th
century, truth was far more damaging than lies.  But around 1720, 2 people
writing under the pseudonym Cato argued that truth should be an defense
against defamation. They were subsequently sued for defamation for
revealing disparaging true facts. They won. Since then, truth has been an
absolute defense against defamation.  

It is remarkable that truth is more damaging than lies.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Proper behaviour towards irritating persons (RE: I'm not going to listen...)

[Dean Anderson]

These are generally good rules.  Too bad you don't follow them.

Crocker, Royer, and Alvestrand et al should try to apply rule 1 to
themselves.  The fact that they engage in personal attacks (including
further attacks of "having to put up with Mr. Anderson", "Proper behavior
towards irritating persons [Anderson and Staff]") demonstrates that they
have no rational arguments to make.  It is an axiom that personal attacks
are the last resort of the wrong and weak-minded. I'll leave it up to
others to categorize those making the personal attacks.  They are very
vague about my "egregious irrational bad behavior", yet I am very specific
about theirs.

On the subject which brought their attacks:  I think it is an axiom of
civil society that accepting the claims of well-known, court-proven liars
is unreasonable and unacceptable. For some (plainly irrational) reason,
they find this axiom irrating. They are being unreasonable on this count,
not I.  By contrast, there is logic and wide civil agreement to this
axiom: its an axiom of society.  They just don't like that I've revealed
their unreasonable behavior, and don't like that I've revealed facts
they'd rather not have revealed.  They would prefer us to ignorantly
accept the word of court-proven liars unaware they are court-proven liars
on an RFC topic.

They don't like it that this fact of court-proven lying on the subject of
open relays has been pointed out, thus making it unacceptable as the basis
for an RFC.  But this isn't a trivial Homer-Simpson mistake on their part:
They are not shocked by the fact of the court-proven lying.  They do not
recoil from the fact. They attack the messenger of this fact. It is not a
mistake by their own ignorance of the fact. They knew about this fact.  
They intended to mislead. They are angry that the attempt to mislead has
been foiled.

And what they've had to "put up with" in the past has also been merely
unwelcomed truth about flawed schemes and false assertions.  Schemes which
were then abandoned by rational people, I might add.  And I've been
vindicated in many disputes on both spam and non-spam subjects, as well as
in disputes with spam radicals and liars. I am President of the League for
Programming Freedom, I have a fairly impressive resume, and a good
education with good grades at MIT, and my associates are leading people in
Computer Science. I have proven some organizational and political skills.  
I can articulate my arguments without excessive vitriol.  It is reality
that is annoying them.  I'm just the messenger: I didn't create these
facts, nor the court judgements, nor pass the laws.  They just hate the
facts that they can't dispute, so their only recourse is personal attack.  
The personal attack is a distraction and diversion from the facts under
discussion.

I will try to apply rule 3 to the rather spiteful and angry responses of
Crocker, Royer, Alvestrand, etc.  But it is good to know who prefers to be
associated with known, court-proven liars, and who would like to mislead
both the IETF and the public.  This knowledge is a useful set of facts to
be documented.  Eventually, there is always an accounting of such things.
It is just a matter of time.

The IETF and the ISOC have rules and codes of conduct that should be
enforced impartially by those in charge. Redress in several documented
instances has not been made. These cases will not be forgotten, and the
longer they are ignored, and as patterns develop, the more serious the
problem becomes. These problems don't go away because those in charge
ignore them. They fester in the public mind, and harm the IETF and the
ISOC.

Dean Anderson
Av8 Internet, Inc

On Tue, 28 Jun 2005, Harald Tveit Alvestrand wrote:

> Since Nick Staff's response is edging towards the subject of proper 
> behaviour towards irritating people on the IETF list, I thought it might be 
> worthy of response I found no reason to respond to earlier messages in 
> this thread.
> 
> I learned long ago some rules for reasonable behaviour on mailing lists.
> 
> Some of those include:
> 
> 1 - Argue rationally. Use arguments related to what's being discussed. 
> Support those arguments with facts. When the facts don't support your 
> argument, shut up. RFC 3184.
> 
> 2 - When you think that other people behave unreasonably, ignore their 
> unreasonable behaviour unless your role requires you to respond to it 
> ("don't feed the troll"). Alternatively, complain off-list. RFC 3005.
> 
> 3 - When other people respond angrily to the unreasonable behaviour, you 
> may sometimes advise them that following rule 2 may be a better option.
> 
> I've chosen to apply my strongest version of rule 2 to mr. Anderson - I 
> won't see his messages unless I look for them. The reason being t

Re: I'm not going to listen to this any more.

[Dean Anderson]

Mr. Alvestrand's comments certainly demonstrates the animousity of the
former chair and they demonstrate his motive for not enforcing the IETF
and ISOC Code of Conduct against those making personal attacks against
Dean Anderson, Av8 Internet, and perhaps others, such as Dan Bernstein,
who were abused but the abuse was never properly redressed, nor were the
abusers chastisted or punished in any way.  Abuse of Mr. Bernstein by
Randy Bush was on the Namedroppers (DNSEXT) list, and included publishing
his subscription address enabling forged unsubscriptions, and altering or
delaying his messages and other inappropriate "special treatment" for
which Mr. Bush was never chastised or punished, nor made to apologize.  

Mr. Alvestrands recent comments shows again the substance to this
complaint:
http://www1.ietf.org/mail-archive/web/ietf/current/msg30614.html

Therefore, I would like to renew the earlier Code of Conduct complaints
made against Mr. Vixie and others, with the additional provision noting
the personal hostility of the former chair, Mr. Alvestrand, and his
failure to act appropriately regardless of his personal hostility.

I believe the IETF owes an apology to Dan Bernstein, Dean Anderson, Av8
Internet, and possibly others.

Dean Anderson
Av8 Internet, Inc

On Sun, 26 Jun 2005, Harald Tveit Alvestrand wrote:

> Since I'm no longer responsible for anything that Dean Anderson has a 
> legitimate role in, and Dean Anderson has proved that he irritates me, I 
> can stop listening to Dean Anderson.
> 
> Goodbye, mr. Anderson.
> 
> --On 25. juni 2005 20:21 -0400 Dean Anderson <[EMAIL PROTECTED]> wrote:
> 
> >
> > The IETF cannot accept the statements of known, court-proven liars, nor
> > can it suppress this fact in its deliberations.  If the IETF accepts
> > court-proven and documented liars as reliable sources of fact, then it
> > will have no more credibility in its statements, as they will be based on
> > lies, not on truth.
> 
> 
> 
>  
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I'm not going to listen to this any more.

[Dean Anderson]

This would be a personal attack, I think.

--Dean

On Sun, 26 Jun 2005, Harald Tveit Alvestrand wrote:

> Since I'm no longer responsible for anything that Dean Anderson has a 
> legitimate role in, and Dean Anderson has proved that he irritates me, I 
> can stop listening to Dean Anderson.
> 
> Goodbye, mr. Anderson.
> 
> --On 25. juni 2005 20:21 -0400 Dean Anderson <[EMAIL PROTECTED]> wrote:
> 
> >
> > The IETF cannot accept the statements of known, court-proven liars, nor
> > can it suppress this fact in its deliberations.  If the IETF accepts
> > court-proven and documented liars as reliable sources of fact, then it
> > will have no more credibility in its statements, as they will be based on
> > lies, not on truth.
> 
> 
> 
>  
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: SpamOps claims about Email Authentication and open relays

[Dean Anderson]

On Fri, 24 Jun 2005, Doug Royer wrote:

> 
> Of the two of us, you would NOT HAVE A CLUE about if I can or
> can not read and understand my own logs :-)

I'm not saying you can't read logs. I'm saying there aren't any reliable
automated methods of determining whether a message came from an open 
relay.  So you are assuming too much about the meaning of your log 
entries.  That it came from a machine on an "open relay" blacklist, 
doesn't mean it came from an open relay.

> I am sure that those 22,000+ spams were blocked by the DNS
> list that "says" its an open relay list by SORBS and the other one.

I've no doubt they did. But the blacklists' word doesn't mean anything for
several reasons. And furthermore, even by their own definition of what's
in their blacklist, it doesn't mean that. You are misquoting them. They 
indicate that their blacklist also contains open proxies.

> > Note that 235.245.195.212 is not allocated. This is a forged header.  
> > 66.59.238.35 isn't running an open relay. Indeed, I could not find a
> > single open relay spam in a sample of 15 of the 605 spams I've received in
> > the last 24 hours. But I did find forged headers pretending to be open
> > relay. Though that is also becoming the exception. Much spam doesn't even
> > bother with forged headers.
> 
> I do NOT rely on ANY information from the content of SPAM to tell me
> anything. I use the getpeername() OS call to get the IP of the remote
> sending system - live as they send it.

The rest of this, I won't address. Its basically circular, since you are
subscribing to a list known to promote abuse open relays; You probably get
more open relay abuse as a result. This makes them appear more effective, 
and thus more valuable.

My only point is that by the indicator of hand analysis of recieved ppam,
and by the indicator of actual abuse of open relays, open relay abuse has
dropped off to nearly nothing since Fall of 2003. So it seems interesting
that you are still getting a lot of open relay abuse, and that open relay
abuse accounts for 90% of your spam.  This does not seem credible as a
general statement.  I'm not saying you are lying, but only that your
experience isn't generally experienced by others.

> At this point, I'll take this off the ietf list
> and we can continue this between ourselves.

You'll have to quit using SORBS, if you want off-list email from me.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: SpamOps claims about Email Authentication and open relays

[Dean Anderson]

The IETF cannot accept the statements of known, court-proven liars, nor
can it suppress this fact in its deliberations.  If the IETF accepts
court-proven and documented liars as reliable sources of fact, then it
will have no more credibility in its statements, as they will be based on
lies, not on truth.

My statement was not an ad hominem, but a statement of fact.

This is an ad hominem: 
http://www1.ietf.org/mail-archive/web/ietf/current/msg30606.html
In it, Paul Vixie calls my company by a derogatory name. It is a personal 
attack.   [No objection to that (and others), I note.]

Black's law dictionary defines Ad hominem as "To the person. A term used 
in logic with reference to a personal argument."

The key here is "logic". An ad hominem is a fallacy: Even if the person is
X (whatever), that does make not their argument invalid.  To have an ad
hominem, one have to refer personally to someone they are arguing with, as
Paul Vixie did in the reference above.

If a person really is a Jerk, their statements might still be true. Their 
being a Jerk, doesn't make them wrong.

The one and only exception is if "X" is "liar".  If a person really is a 
liar, then their statements probably are not true, and cannot be accepted. 
However, this is a serious charge, and needs proof. 

In this case, we have irrefutable in the form of multiple court decisions
which declared their associates to be liars, having defamed people on the
subject of open relays.  Our question is open relays, and their current
statements are about open relays.  

A fact, well established, that anti-spammers engage in lies about open
relays is certainly relevant to the question of whether the SpamOps
assertions about open relays are based in true facts or in lies.  Mr.  
Royer quotes the opinions of associates of known COURT-PROVEN liars to
support his arguments.  One person he quotes is well documented to have
perpetrated similar false statements against people (myself) who revealed
the lies of the court-proven liar.  The fact of their previous lack of
honesty on the subject is relevant to the truth of their assertions.


--Dean



On Sat, 25 Jun 2005, Brian E Carpenter wrote:

> >  is a documented liar, and 's associate 
> > (formerly of ) has been proven in court to be a liar on 3 separate
> > court cases.  And 's only regret in those cases is that he told the
> > court the truth when asked if he had subscribers.  was shut for
> > contempt of court when  published his blacklist instead of complying
> > with a court order to remove false entries.  You should review
> > http://www..org, although it is not complete.
> 
> This sort of assertion really has no place on an IETF list, regardless
> of whether it's true. It's as ad hominem as you can get, and that
> isn't how we debate here. Facts yes, people no.
> 
> Thanks
>  Brian
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: SpamOps claims about Email Authentication and open relays

[Dean Anderson]

Facts, yes.  

"When you associate with anti-semites, you become one."

--Dean

On Sat, 25 Jun 2005, Brian E Carpenter wrote:

> >  is a documented liar, and 's associate 
> > (formerly of ) has been proven in court to be a liar on 3 separate
> > court cases.  And 's only regret in those cases is that he told the
> > court the truth when asked if he had subscribers.  was shut for
> > contempt of court when  published his blacklist instead of complying
> > with a court order to remove false entries.  You should review
> > http://www..org, although it is not complete.
> 
> This sort of assertion really has no place on an IETF list, regardless
> of whether it's true. It's as ad hominem as you can get, and that
> isn't how we debate here. Facts yes, people no.
> 
> Thanks
>  Brian
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

SpamOps claims about Email Authentication and open relays

[Dean Anderson]

Brian Carpenter asked that the subject be changed.  I've also removed the 
IESG from the cc-list.

Doug, you've been misled. Inline.


On Wed, 22 Jun 2005, Doug Royer wrote:
> I have not been following this topic closely.
> To the point of open relays being a problem.
> 
> I think that the judgment as to if open replays are a problem
> or not depends on which spam lists you are on.
> 
> With my system and by grep-ing through my last 4 weeks of logs
> there were 22,870 of 26,157 spams blocked by my usage of two open
> relay DNS-black lists blocking them from 14,131 UNIQUE IP addresses.

You cannot know from logs whether you are blocking spam or ham. You can
only see that you blocked messages. Like many before you, you've been
misled, but you probably feel much better thinking that you are blocking 
spam.

I'm not sure which blacklists you consider being "open relay" blacklists.
Since fall 2003 after most of the open relay blacklists shut, the
remaining "blacklists" don't search for or block open relays anymore.  
(though SORBS started up in March, 2005) Indeed, Matthew Sullivan of SORBS
recently tried to convince people on Nanog that he/SORBS was never
interested in open relays, but rather in open proxies. This claim (like
many of Sullivans), is belied by the facts: SORBS stands for "Spam and
Open Relay Blocklist", and there is a SORBS project on sourceforge from
2002, with an open relay scanner program.

> 6,676 of which have no reverse-DNS. They seem to be in IP blocks of 
> 10-12. The other 2,616 spams that were DNS-blocked were from
> non-open-relay lists. I still get 20-50 spams that make it to
> my inbox every day.
> 
> The SORBS pages say they have over 3 Million such open relay or open
> proxy (hacked or not) sites.

SORBS/Sullivan is a documented liar, and Sullivan's associate Alan Brown
(formerly of ORBS) has been proven in court to be a liar on 3 separate
court cases.  And Brown's only regret in those cases is that he told the
court the truth when asked if he had subscribers. ORBS was shut for
contempt of court when Brown published his blacklist instead of complying
with a court order to remove false entries.  You should review
http://www.iadl.org, although it is not complete.

> Spammers seem to setup open relays and use them. 

I think you are incorrectly analyzing headers. See below.

> And as I do not think that there are 14 thousand spammers, my guess is
> that the spammer machines change their IP nightly or find a lot of open
> relays.

I keep logs of TCP SYN packets to port 25 over a group of about 68,000 IP
addresses, and run non-production queue-only relays that serve as
honeypots for open relay scanning.  No one is scanning for open relays,
and no one has been scanning since most of the open relay blacklists shut
in 2003, with the exception of SORBS which only restarted in March.  
Prior to 2003, only open relay blacklists were doing the scanning. We
tested these blacklists as previously described, and fouund that they were
associated with, and a necessary component to open relay abuse. Block the 
open relay blacklists and prevent their scanning, and open relays aren't 
abused.

Further, I don't delete or block spam to several personal mailboxes.  
Years ago, I used to be able to go through my recently received spam and
quickly find an open relay abuse delivering spam to my av8 (and non av8)
email addresses. Today, this is the closest I could find:

Received: from dial-66-59-238-35.lcinet.net (dial-66-59-238-35.lcinet.net 
[66.59.238.35])
by odie.av8.com (8.9.3/8.8.5) with SMTP id QAA24726
for <[EMAIL PROTECTED]>; Fri, 24 Jun 2005 16:43:27 -0400 (EDT)
Received: from chastiser ([235.245.195.212] helo=lurched.lcinet.net)
by dial-66-59-238-35.lcinet.net with SMTP id 17C396B7
for [EMAIL PROTECTED]; Fri, 24 Jun 2005 16:43:26 -0400

Note that 235.245.195.212 is not allocated. This is a forged header.  
66.59.238.35 isn't running an open relay. Indeed, I could not find a
single open relay spam in a sample of 15 of the 605 spams I've received in
the last 24 hours. But I did find forged headers pretending to be open
relay. Though that is also becoming the exception. Much spam doesn't even
bother with forged headers.

> If it were not for open-relay DNS black lists, I could not run my
> company.

These are probably doing you more harm than you realize. Or are you a
promoter? (there are basically two kinds of users of these blacklists: The
misled who don't know, and the promoters, who know and don't care)

Most "open relay"  blacklists are revenge lists, and while they may block
some real spam [or possibly block pretend spam that they generated--they
call this "mailbombing"], their purpose is revenge and extortion.  This is
well documented: ORBS and its successors, SORBS, Osirusoft, Monkeys.org,
IMRSS. Most people "in the know" know that none of these blacklists are
suitable for blocking spam, and few ISPs or professional mail staff use
them.  You will just wind up 

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

[Dean Anderson]

There are several issues for the IESG:

In summary, people have brought up several reasons that this draft 
shouldn't be approved. But I think these are sufficient:

1) End run around SMTP developers, as Keith Moore pointed out. 

2) "spamops" past unreasonable and irrational demands and views require
careful scrutiny: Spamops needs to give consideration to lawful and
legitimate activity. People loosely associated with this group promised in
1997 to give a "technical solution" to spam. They have failed for more
than 8 years to do that, but have instead been associated with various
schemes to charge/extort fees for email services. In 1997, they rejected a
compromise with IEMCC that in retrospect was quite reasonable, and in at
least one way better than the CAN-SPAM law that was finally passed,
because IEMCC proposed to label spam with a header.  In retrospect, the
spamops community has been extremely unreasonable and irrational, and has
failed to deliver anything that was promised.

3) Assertions and assumtions in the draft are based on spamops "lore"  
rather than fact. This is bad engineering. The "issue" in the draft is
whether its assumptions and assertions about open relays and email
authentication are based on facts, versus the opinions of zealots.  
Neither open relays nor email authentication has been shown to be related
to spam: Neither promoting spam, nor preventing spam.

4) There are also numerous detailed problems with the language in the 
draft. However, in comparison with the major issues 1-3 above, these are 
minor, but also indicate that the document is not suitable for last call.


More inline.

On Tue, 21 Jun 2005, Bill Sommerfeld wrote:

> On Tue, 2005-06-21 at 00:28, Nicholas Staff blames the victims:
> > whats funny to me is if anything would have given spammers a reason to
> > exploit open relays it would have been the blacklists.  I mean when
> you 
> > arbitrarily blacklist millions of their ISP's addresses you leave them with 
> > no other option.
> 
> "if anything would give burglars a reason to break windows, it would
> have been locked doors.  i mean, when you put locks on millions of
> doors, you leave them with no other option."

Yes, there are some "burglars". But the open relay situation is much more
like gas pumps: Anyone can drive up and put gas in. That doesn't give them
the right to drive off without paying.

> people who send spam *always* have the option of changing their line of
> work. 

Nonsense.  Real spammers, advertizing real products and real services have
the legal right to do so.  Blacklists have no legal right to block them.  
Exactis V.  MAPS, CAN-SPAM.  

Real spammers have no reason to abuse open relays.  And if they did use
them without permission, they would be easily blocked, easily found, and
then billed for those services. In 9 years, we've never found real
spammers abusing our relays. But we have found anti-spammers abusing them;
We've found anti-spammers soliciting abuse for them; We've found
anti-spammers telling people that open relays are free; And we've found
anti-spammers doing other mischief.  The "open relay" problem, is purely
due to anti-spammers.  The operational response:  Prevent anti-spammers
from discovering the relays, and you prevent abuse.  Real spammers aren't
searching for open relays, either.


--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

[Dean Anderson]

On Mon, 20 Jun 2005, Nicholas Staff wrote:

> Dean,
> 
> I couldn't agree with you more - thanks for saying it.

You're welcome.

> whats funny to me is if anything would have given spammers a reason to 
> exploit open relays it would have been the blacklists. 

No, this isn't the case, and ironically, it is anti-spammers that usually
made this assertion.  It isn't the case because intelligent spam-blocking
requires that the headers and message content be analyzed, ala spamassasin
and other tools.  Years ago, the unreasonable spamops folks insisted on
trying to block spam without receiving it: That is, to send a "550 no spam
accepted" type message before the SMTP DATA command. This kind of blocking
is not reasonable, since use of a relay, any relay (open or closed),
defeats the blocking scheme.  The often asserted goal of "saving
resources" is not valid because it is faster to queue the message and
analyze it afterwards than it is to hold up the mail process trying to
decide whether to reject it before receipt.

By contrast, intelligent analysis of the message headers and content can
block the message from a blocked host no matter what relays they used.  
(open, closed, authenticated, or unauthenticated). And this is what one
wants.

You should probably read http://www.av8.net/FTC.pdf, which details the
many fallacies promoted by anti-spammers about open relays.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

[Dean Anderson]

On Mon, 20 Jun 2005, Tony Finch wrote:

> On Sun, 19 Jun 2005, Dean Anderson wrote:
> >
> > Neither open relays nor lack of email authentication are
> > problems that are exploited by spammers.
> 
> Neither of those statements are true. I've already addressed the first.

No, you haven't addressed anything. You made an assertion that doesn't
stand up: What is probably your customers' attempts to relay externally
does not represent spammers trying to abuse open relays. This is very
likely legitimate, by legitimate users.  This doesn't make your point.

The fact that you seem to get gratification at "blocking email" and
ASSUMING it is abuse, doesn't do you, us, your customers, or anyone any
good. It doesn't show that open relays are exploited by spammers. The fact
is, open relays aren't abused by spammers.  In 9 years, no genuine
commercial operation has ever abused our relay. And we look. We don't just
look at "relay denied"  log messages and impute bad motives, as you do.  
Instead, we look at the queued messages. We try to find the company
selling something; And there hasn't been any.  We found instead that this
is abuse queued by self-described anti-spammers aka "spamops" people
trying to "teach us a lesson" about running open relays. And when they
gave up on abuse and shut their "blacklists", we had no further abuse,
either.

> Regarding the second, we dealt with an incident last year where a spammer
> exploited an open proxy on our network to send spam; 

An open proxy on a machine run by your customer is still your customer,
and is therefore entitled to send email.

> they evaded our port 25 block by using an unauthenticated outgoing SMTP
> relay.

But they were your customer, and were therefore authorized to send email.  
If you had run SMTP AUTH, they would have obtained the password, because
they can INSTALL AN OPEN PROXY ON YOUR CUSTOMERS MACHINE.  Authenticating
the relay will do nothing.  Your problem is the open proxy.  Deal with the 
problem, don't invent a solution that won't fix the problem.

> This attack was easy for us to stop because they discovered the relay by
> looking up our MX record; 

Funny that you should call this as an "exploit". SPF (the email
authentication du jour)  will identify your outbound relays, too.

You are arguing in circles, making my points for me.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

[Dean Anderson]

On Sun, 19 Jun 2005, Dave Crocker wrote:
> The methods in the draft BCP are intended to close some holes and improve
> up-stream (source) accountability.  It's a small but necessary step towards
> finding ways to develop trust, since trust begins with accountability.

Except that, it doesn't close any "holes", nor does it improve up-stream
accountability.  Neither open relays nor lack of email authentication are
problems that are exploited by spammers.

All the BCP does is propogate myths that have never held up to analysis.
And somewhat worse, the BCP propogates these myths by assumption, without
discussion or analysis that reveals the fallacies of those myths.

So, this BCP should be rejected.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

[Dean Anderson]

This is an interesting observation, and the SPF group shed some light on
this quite by accident last year.  One of the differences between CAN-SPAM 
and the IEMCC proposal that was rejected by anti-spammers in 1997, is that 
IEMCC proposed to label commercial bulk email with a special header. 
CAN-SPAM merely requires a postal address, phone number, unsubscribe URL 
and no forged headers. Its harder to automatically identify commercial 
bulk email, and so harder to count how much of "spam" is really CBE, and 
how much is just non-commercial annoyance.  Enter SPF:

Bulk commercial emailers jumped on the SPF bandwagon on the assumption
that SPF would mean their email would be subjected to fewer tests.  
People monitoring SPF records support noticed this, and reported it.  
Temporarily, this gave a fairly good label for commercial bulk email. It
was found that about 6% of SPAM was SPF-PASS.  So, it may very well be
that as much as 94% of what we call "spam" is non-commercial annoyance
rather that genuine commercial bulk email.  I had previously thought that
frauds and junk was probably a high percentage, but not that high.

It gives further credence to the view that we have an "pretend spam"/fraud
abuse problem, not commercial bulk email problem.


But some people would complain about genuine CBE, anyway. Although you
hear less of it today, the view of many more radical antispammers is that
spam (Commercial Bulk Email, ie Bloomingdales, etc) needs to be banned
completely. One of the early "spam" complaints is about Network Solutions
sending CBE to its domain registry subscribers. Today, many wouldn't think
that abuse, because the recipients were the customers of Network
Solutions.  

--Dean


On Thu, 16 Jun 2005, Nicholas Staff wrote:

> Because I have already recieved several comments relating to one aspect of 
> my original post I thought a clarification was in order as I didn't explain 
> myself properly and there is some misunderstanding.
> 
> When I wrote that "nobody would be complaining if spam primarily consisted 
> of Bloomingdale's catalogues and coupon val-paks" I didn't mean we wouldn't 
> complain if we recieved the same amount of spam but it was from legitimate 
> companies.  I meant that maybe 1% of my spam comes from legitimate companies 
> so if we got rid of the frauds we would have effectively reduced spam by 99% 
> (by no means is that percentage anything more than a rough approximate 
> estimate).
> 
> Best regards,
> 
> Nick Staff
> 
> 
> Original post:
> 
> 
> I'm sure many will think this a stupid comment, but in the hopes that some 
> don't I'll point out that the largest and arguably most efficient messaging 
> system in the world is built upon open relay.  Anyone can anonymously drop a 
> letter in any mailbox in the US and while there's junk mail it's proportions 
> are certainly nothing like spam.  Why the difference?  Well first I split 
> spam into 2 categories:
> 
> 1.  legitimate advertisements for legitimate products (whether solicited or 
> unsolicited).
> 2.  Fraudulent mail, scams, cons, etc.
> 
> I think the email abusers almost entirely fall into the second category and 
> that nobody would be complaining if spam primarily consisted of 
> Bloomingdale's catalogues and coupon val-paks.
> 
> So I think we are attacking things the wrong way.  The methods we are 
> using - whether blacklists or 'authorized email' is going to either prove 
> fruitless or end up ruining the big picture, which for me is electronic 
> communication for everyone, to everyone.  Using electronic means, I don't 
> see how we can ever prevent spam and still have open global communication 
> among disparate systems.  It would be a different story if one organization 
> ran all email servers worldwide but that horrible thought aside there will 
> always be holes and breaks in an authentication/authorization scheme unless 
> people limit who they can communicate with, and even then there will be 
> spam.
> 
> There's also the returns we see on our efforts to consider.  Think of the 
> millions of man/woman hours spent trying to stop spam - so many hours it 
> probably would have taken less to inspect every email by hand.  And then 
> when you think (if you believe as I do) that everything can be gotten around 
> and that security holes are as infinite as the imagination, well then you 
> know there will always be some kid with a script (which also includes any 
> real spammer) who will be able to get around your defenses within a week of 
> them being implemented.
> 
> My last unconstructive comment is that simple systems scale lossless and 
> complex systems grow in a complexity proportionate to their size.
> 
> Funny enough, I think the postal inspector's department came about because 
> of the amount of scams being sent via mail shortly after the civil war (such 
> a glut that it was bringing the postal service to their knees).  Yet the 
> postal service remained open-relay - why?  Ma

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Dean Anderson]

I have no religion about top or bottom posting. Bottom posting is a
variation of posting inline.

On Thu, 16 Jun 2005, Larry Smith wrote:

> Since you top posted, I will, against nature, respond in kind.
> 
> The one "item" you missed from your analogy is that postal mail is "paid" for 
> up front, by the person "posting" (anon or not) - eg the post-office gets 
> paid _before_ your letter gets delivered.  The problem with spam is that the 
> receipient is "paying" the cost (cod with no chance to refuse delivery)...

This "spammers don't pay" claim isn't true, except for viruses.  This myth
was first leveled against Cyberpromo and others in the 1990s. But
Cyberpromo (and the others)  frequently had T1 connections that they paid
for.  We occasionally hear of "pink contracts" that spammers presumably
pay more for.  Commercial bulk emailers have always paid at least as much
as everyone else. Sometimes more.

Second, junk postal mail costs the recipient much, much more in time and
trash handling, landfills, and garbage pickup than spam does.  Both sender
and receiver incur expenses with postal junk mail. An the case of postal
mail, bulk mailers pay substantially _less_ than everyone else. Regular
people pay 37 cents. I think bulk mail is still at 15 cents (it could be
higher now).  But even if the bulk mail rates are higher now, they are
less than 37 cents.  Imagine if we were to charge commercial bulk emailers
less for their internet service.

Third, for the case where viruses are used, the spam problem exists but
pales in comparison to the problems of distributed DOS attacks, extortion
of various sorts, and other criminal activity and mischief available to
the virus operator.  That they are "spamming on someone else's dime" is
the least of the worries with a virus/botnet.



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Dean Anderson]

On Thu, 16 Jun 2005, Tony Finch wrote:

> On Wed, 15 Jun 2005, Dean Anderson wrote:
> >
> > What sort of mail volume to you handle?  2000-4000 attempts isn't a lot
> > for large volume domain handling millions of messages per day.
> 
> About 250K legit messages each day, and about a million junk messages.
> Yes, it isn't a very large proportion of our total volume, but I would
> expect that to change rapidly if the probes were successful.

Yes, indeed. It will change if the probes are successful. But it is easy
figure out who is doing the probes. Open relay probing requires an valid
emailbox. So just queue up the probes, identify the blacklist (its usually
something like relaytest@). In the rare case it is not plainly
a blacklist, send in an abuse report on the destination emailbox.

Another technique is to run non-production open relays, let them be
scannned, and see what blacklists the relays turn up on, and then start
blocking (and reporting) any IPs that try to connect to the non-production
relays.  

Anti-spammers also scan the /24 around any known open relay before abuse.
This behavior started shortly after I reported that I could identify abuse
with the specific blacklist that was promoting the abuse. I did this by
adding different non-production relays to different blacklists, and then
tracking the IPs and spams that came through.  After that, they started to
scan the /24 immediately before abuse to obscure which blacklist was doing
the abuse.  If you have enough address space, you can still conduct the
tests with each relay on a different /24. After that, they started
claiming that 130.105/16 was stolen.

> > You said it is more prevalent on hosts named mail or smtp---one would at
> > minumum need a list of domains to search. Where do you suppose they
> > obtained this list?
> 
> Where do you suppose they get lists of email addresses to send spam to?

That's not the same thing. Most of those lists have AOL and MSN and the
top 50 or 100 or so domains. I have the spam email lists, too. The email
addresses show up in my logs and the block email messages' envelope
recipient lines [RP.*FD in sendmail]. That doesn't give them enough to
find very many open relays by simply adding mail or smtp to the domain
names from a list of email addresses.

Open relay abuse just doesn't scale. Too much searching, too few relays.

> > Who is doing this searching?  Internal viruses?
> 
> The probes are external, and appear to be mostly from compromised home
> computers. Our network is reasonably well managed and infections are
> quashed promptly.
> 
> > What sort of commercial companies are abusing your open relays?
> 
> You misunderstand: We don't operate open relays, but despite your claims
> about the rareness of open relay abuse, our email servers are frequently
> probed with open relay attacks. I believe you are depending on security
> through obscurity to avoid attack. One of our main outgoing relay services
> has an obscure name (ppsw.cam.ac.uk) and is probed 100 times less
> frequently than our MXs or our MSA service named smtp.hermes.cam.ac.uk.

Well, script kiddies may do many odd things. Further, if you aren't
running open relays, how do you know for certain that it's not just
misconfigured clients?  "Relaying denied" is a frequent problem
experienced by real customers who aren't spammers.

Adding mail or smtp to a domain is probably something your legitimate
users are doing, trying to figure out how to relay remotely. Very likely,
this represents the number of legitimate mails your users would like to
'open relay.'

> > You also haven't shown that the abusers would be prevented from emailing
> > if open relays were closed.
> 
> That's irrelevant: it's still my responsibility not to abet them.

I'm not "abetting" them.  They send email no matter what. They didn't get
anything they don't already have.  And in practice, its the anti-spammers
who are abusing open relays (to teach us a lesson), not real bulk
commercial emailers.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Dean Anderson]

On Thu, 16 Jun 2005, Dave Crocker wrote:

> Keith,
> 
> >  it's possible to have open relays that don't contribute to spam.  but
> >  those relays need to employ some other means, e.g. rate limiting, to
> 
> Rate limiting is a relatively recent technique.  Though very useful it has...
> ummm, limited applicability.

I tried a "rate limiting" freeware a couple years ago. It didnt' work,
largely due to very poor programming. It had no locking. The programmers
didn't seem to understand that the program could be invoked
simultaneously. It worked only so long as there was only one message at a
time, a rate so slow as to not require rate limiting.

But abusers do look and behave differently from regular users.  This can
be exploited to some extent.  Slow queues that wait for an abuse pattern,
and so forth.  But the best thing is to just block the blacklists from 
scanning. And the techniques I just described to Tony Finch.

> The problem is with zombies.  They make mush of old-time models of spam, since
> they demonstrate that a very small data stream from a single source can be
> leveraged into a very, very large data stream, given enough sources.

It is interesting that the most recent "email authentication" scheme (SPF)
asists the zombies by identifying the ISP's (possibly closed) outgoing
relays. If the ISP happens to block port 25, which may be attractive to
residential ISPs which also happen to have the most zombies, then the
zombie needs to use the ISPs relays.  Finding that relay for a thousand
different mail clients is a chore, and would have to be performed by a
severely limited virus payload. But along comes SPF, and identifies those
relays for the zombie.  Foot, gun, trigger. Or perhaps SPF was more
intentional, and also happened to be a great source of money.

> I don't know how much experience you have trying to do such tracing, but the
> spamops folks have made quite clear that it is both vastly more effort and
> considerably less productive, than one might expect.  Again, there is no way
> that relying on that is a reasonable best practise on the current Internet.  
> As
> a small example, not that spammers now are stealing IP Address blocks.  That
> pretty much kills backtrace accountability.

The spamops folks are frequently unreasonable in this respect. They have
asserted, for example, that one cannot trust _any_ mail headers.  They
expect _immediate_ results. Those are just unreasonable demands.  No ISP
is going to cancel a users account on the say-so of some unreasonable
anti-spammer, who (as a group) are already well-known for outright lying,
revenge, and defamation.

Tracking a spam zombie requires a bit of patience and persistence. There
is nothing that will make that easier, except perhaps a standard abuse
submission protocol (which I proposed back in 1999).

> >  unfortunately, the vigilante character of various open-relay blacklists
> 
> blacklists are not the subject of this BCP.

Its couched in terms to avoid that, and just assumes the blacklists claims
about open relays are right.

> >  killed any attempt at this kind of innovation.  just as we're now in
> >  danger of various kinds of brain-dead "authentication" methods and
> >  meaningless requirements killing useful email functionality.
> 
> new authentication methods are not the subject of this BCP.

It doesn't specify a specific method. It just says that email
authetication should be used.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Dean Anderson]

I don't see that sort of probing on our MXs, except on rare occasions, and 
we haven't seen it recently.

What sort of mail volume to you handle?  2000-4000 attempts isn't a lot 
for large volume domain handling millions of messages per day.

You said it is more prevalent on hosts named mail or smtp---one would at
minumum need a list of domains to search. Where do you suppose they
obtained this list?  Do you have a particularly well-known domain?

Who is doing this searching?  Internal viruses?  Perhaps your should
report it to the organizations doing the probing.

What sort of commercial companies are abusing your open relays?  We
haven't found any commercial advertising in open relay abuse in the 9
years that we've run open relays.

People should and do use open relay when it is necessary: When you have to
provide email services to persons and organizations outside your address
space.

You also haven't shown that the abusers would be prevented from emailing
if open relays were closed.  There are number of myths about open relays
that are debunked in http://www.av8.net/FTC.pdf which was submitted to the
FTC spamforum in 2003, after the FTC issued a press release against open
relays. The FTC didn't permit participation by open relay operators, and
an FTC lawyer supervising the forum even ridiculed John Gilmore.  
However, the FTC did allow known spammer Scott Richter to attend. It was
later learned that MAPS employees were working for Richter.  And the FTC
did use a blacklist called Osirusoft run by Joe Jared. Among other revenge
activity, Jared blacklisted his ex-girlfriend out of spite after the
relationship failed.  In spite of this incident, the FTC continued to use
the blacklist until it shutdown later in 2003, blacklisting the entire
world, and disrupting the email of all the blacklist subscribers,
including the FTC.

Part of the fallacy embodied in the open relay myth and also in the email
authentication jihad is that:

Every user has relay services until they are no longer a user. 

That includes viruses and spammers.  So why should it be anti-spam "best
practice" not to use open relays?  Open relays have nothing to do with
spam. They never have.

--Dean


On Thu, 16 Jun 2005, Tony Finch wrote:

> On Wed, 15 Jun 2005, Dean Anderson wrote:
> >
> > Had anyone bothered to ask, I would have reported that open relay abuse
> > has dropped off to nearly nothing since the open relay blacklists shutdown
> > in 2003.
> 
> MXs are routinely probed by relay attempts: we see about 2000-4000 such
> attacks each day. A similar volume of relay attempts occurs for machines
> named 'mail' or 'smtp'. More obscure mail hosts might see a more
> manageable number of attacks, but I still think it is valid for this draft
> to state that it is best practice that MTAs must not be configured for
> open relaying.
> 
> Tony.
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

[Dean Anderson]

There is a tremendous amount of myth propogated in this document.

The notion that email authentication has helped reduce spam is completely
unsubstantiated by actual practice. We have just recently observed the
failure of SPF, largely due to the fact it didn't work.  Email
authentication, even if possible by some other method, doesn't solve the
problem, since it is the equivalent of dialup problem:

Every user is authorized to send email until they aren't. 

Only their service provider can remove that authorization

And of course, it isn't just users who send email. Devices send email, 
too.

Service providers aren't complaining that they can't identify they users.  
Rather, the people frustrated by email authentication are the end user
recipients of spam. Email authentication isn't going to lessen that. Even
if it were do-able (and done), end-users and other carriers wouldn't have
access to the subscriber identity information.  And if they are your
subscriber, you usually don't have any lack of identity information given
a spam and its headers.

Service providers implementing protocols like SMTP-AUTH have not reported
that SMTP-AUTH results in less spam.  Just the opposite is usually the
case: No change.  

Email authentication isn't a weakness that is exploited by spammers.  
commercial bulk emailers are by and large compliant with the CAN-SPAM act.  
The CAN-SPAM Act has demonstrated a distinction between commercial bulk
emailers and abusers with no direct commercial purpose. (see
http://www.av8.net/SpamTypes.txt).  Abusers have been using viruses and
rooted computers to send abuse email. It is not the economics of
commercial bulk email, nor the lack of email authentication that is the
problem. It is the economics of anti-spam blacklists that shows that
"economic value" of virus/abuse "spam".  Blacklists such as SORBS are now
charging (extorting) money from both users and victims.

And lastly, it seems inappropriate that such a draft would be proposed
with language about open relays without seeking the input of open relay
operators such as Av8 Internet. Av8 Internet is one of the very few open
relay operators that is willing to publicly discuss these operations.  
Av8 has operated open relays since 1996 and has considerable experience
with abusers and the methods of protecting open relays from abuse. While
groups like Nanog have worked to suppress certain viewpoints
(http://www.iadl.org/nanog/nanog-story.html -- this page is not yet
finished, but I've made an early version available) it is still well-known
that I am willing to discuss the issues and have a lot of research to
support my views.

Had anyone bothered to ask, I would have reported that open relay abuse
has dropped off to nearly nothing since the open relay blacklists shutdown
in 2003. Previous testing of open relay blacklists had revealed that they
were involved in directly or indirectly supporting abuse, promoting abuse,
and even soliciting the abuse of open relays. Logs revealed that these
blacklists were the only groups systematically searching for open relays
to abuse, and that open relays were only abused after discovery by the 
open relay blacklists. 

I do note that open relay abuse has resumed slightly since SORBS.NET
started scanning for open relays in March 2005, but there are presently
only about 5 IP addressses abusing our relays, despite the well-known fact
that we operate open relays. In the past, we would sometimes see as many
as 2400 IP addresses trying to abuse our relays.  Nearly all of this abuse
is fairly trivially detected and blocked. Open relays do not present any
"problem" to be addressed.

I think the IETF should make more efforts to make sure that its
recommended best common practices are based on facts rather than myths.

Dean Anderson
Av8 Internet, Inc

=

   Best practices are:

   o  Operators of MSAs MUST perform authentication during mail
  submission, based on an existing relationship with the submitting
  entity.  This requirement applies to all mail submission
  mechanisms.

   o  For email being received from outside their local operational
  environment, email service operators MUST distinguish between mail
  that will be delivered inside that environment, from mail that is
  to be relayed back out to the Internet.  This allows the MTA to
  restrict this operation, preventing the problem embodied by "open"
  relays.

   o  Mail coming from outside an email operator's local environment,
  and having a RCPT-TO address that resolves to a destination that
  is also outside the local environment, MUST be treated as mail
  submission, rather than mail relaying.  Hence it must be subjected
  to mail submission authorization and validation checks.

   o  MDAs SHALL NOT accept mail

Re: Uneccesary slowness.

[Dean Anderson]

The size of an RFC has nothing whatsoever to do with its impact. It takes
time for people review, test, document problems, and propose alterations.
That's the point of delay and a gradual process.

Anyone can give you a one page document that will break just about 
everything. Because its only one page doesn't mean it should be less well 
tested and reviewed. Nor does it mean that its somehow easier to test and 
review. 

--Dean

On Sat, 14 May 2005, Will McAfee wrote:

> I think the minimum time before a document can pass to another
> standards-track state is ridiculously long.  If an rfc is huge, I can
> understand that.  But to sweep that over all of them?  A two-page
> proposed standard can take an absolutely ridiculous amount of time to
> pass through!  I say we have variations based on how long the document
> is.
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: improving WG operation

[Dean Anderson]

On Tue, 10 May 2005, Tom Lord wrote:

> 
>   > But if you aren't interested, why are you here?  What's your interest? I
>   > don't understand your point.  Are you here to convince the rest of us that
>   > the IETF is irrelevant?
> 
> Absolutely not.  Nearly the opposite.  I hope that if you look back at
> some of my other messages in this thread that's clear.
> 
>   >> You're complaining that some application-layer stuff like IM
>   >> isn't as orderly as you'd like.
> 
>   > Disorder isn't good for the users, either. Its not just a personal
>   > view of orderliness. And it isn't good for the market to have such
>   > unnecessary and gratuitous disorder. That's why standards of any
>   > form exist.
> 
> I'm not so sure IETF can help user's other than by producing very
> good, easily accessed documents with available reference
> implementations. 

The IETF doesn't produce documents that are meant to be accessible to
users. Nor does it produce reference implementations. IETF documents are
meant to be accessible to engineers and operators, creating and running
interoperable services of various types. One and possibly two
implementations are usually required for a standard to be acceptable. The
point of this is to require that specifications be both implementable and
complete.

> An endorsement/trust-based system for calling attention to good
> standards seems like all you've ultimately got -- why not
> institutionalize *that*?

The trust-based system we have has a track record of obtaining good
specifications.  We have institutionalized that, vaguely though it might
be.  This doesn't mean this process can't be improved, nor that it
shouldn't be critically examined.  But I don't see that this has anything
to do with calling attention to good standards.

The IETF has no marketing or promotion department to call attention to
anything it does. It is all through word of mouth and the interaction with
participants.  I don't think such a department is necessary. 

> Why *isn't* the rest of the governance simply noise?  Why *isn't* the
> rest of the governance simply a game a professional organization has
> agreed to play that will ultimately turn it into just another
> consortium?  Isn't the rule-mongering just a very indirect attempt to
> find rules that coincidentally create the effects an endorsement/trust
> system would render in a more naked form?  What's the "value add" of
> anything beyond an endorsement/trust system?  My answers to those
> questions are clear and that's why I say: strike while the iron is hot
> -- while there are still recognizable names who roughly essentially
> deserve trust?

I'd offer one point: Name recognition has nothing to do with trust. In the
past few years, we've seen some very recognizable and previously highly
trusted names turn out to be untrustworthy in a number fields, endeavors,
and organizations. Whether someone is still trustworthy is also something
that needs to be critically examined now and again.  An organization's
trust assets only remain assets if they remain trustworthy.  Trusted staff
isn't the only thing going for the IETF, but it is a critical component.
But untrustworthy staff can be replaced without damage so long as they are
replaced promptly.  It is usually delay in replacement of trusted staff
that creates the most damage for organizations that depend on trust.

So far as "striking while the iron is hot", well, "urgency" is usually and
historically a sign of weak technical arguments that won't hold up to
careful and critical scrutiny.  There is nothing here that needs attention
so urgently we can't analyze the problem and the proposed solutions. So
far as I am aware, in _every_ case where "urgency" was cited as a reason
for foregoing analysis, it has been found both that there wasn't any
urgency, and that the proposal was seriously flawed.


--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: improving WG operation

[Dean Anderson]

On Sat, 7 May 2005, Tom Lord wrote:

>>> it's not that cut-and-dried.  it can be very costly to users to  
>>> let the market decide.  sometimes the market doesn't decide, it  
>>> just  fragments.
>>
>> So?
> 
>so "let the market decide" is a lousy rule.  there's no justification  
>for it.  it's just the sort of thing that someone says when he fears  
>competition from a better product.

I agree with Keith. But how about:

  "So...  We all work very hard to create standards using a 
   vendor-neutral, open process that work for many parties, not
   just a single vendor"

> The original focus of IETF was to create and firm-up the Internet.  
> That war was won.

The internet evolves. New standards are created. Old standards are 
modified.  That process doesn't stop.

But if you aren't interested, why are you here?  What's your interest? I
don't understand your point.  Are you here to convince the rest of us that
the IETF is irrelevant?  The IETF will "end" when people lose interest in
its works.

> You're complaining that some application-layer stuff like IM isn't as orderly
> as you'd like.

Disorder isn't good for the users, either. Its not just a personal view of
orderliness. And it isn't good for the market to have such unnecessary and
gratuitous disorder. That's why standards of any form exist.

> I don't see the connection between your complaint and the original
> focus.
> 
> Now, refining a few core protocols -- that'd be great.  Trying to be
> the government of all protocols -- huh?  

> The SRFI process, in the world of Scheme programming, seems to me the
> more utilitarian approach to working on higher-level protocols: there's
> nearly nothing to fight over in that process.

I suspect that the architecture of Scheme and Lisp has a lot to do with
this.  You have a few core language constructs and everything else is
built on top of that. Try to take away CAR or CDR and you'd have big
problems with consensus, I suspect.  Better examples is the Common
Lisp/Scheme schism.  There can easily be many languages, but its harder to
say there will be multiple BGP or TCP variants.  Some order, beyond the
"you're welcome to create a code fork" is necessary when you have
different pieces of hardware that have to interoperate.  A program only
needs its particular runtime, and we can easilly have many runtimes for
different languages.  If you were making scheme/lisp hardware, there would
be more concern about the compatibility of language primitives. (Didn't we
already have this battle with LMI and Symbolics?)  So I don't think the 
Scheme programming analogy works.

But I agree that the "consensus" is a vague term.  Most of the people who
don't like it are the ones where the consensus didn't go their way.  In
any specific case, its hard to tell whether they have a valid complaint or
not. I agree that's a problem. And partly because the definition and
determination of "consensus" is so vague, there is sometimes genuine cause
for suspicions about motives, politics, and such. However, putting
together a simple voting process won't work either.  Like democracy, its
just about the worst thing there is, except for the alternatives. So I
think collective judgement by the WG chairs and the IAB is the only way.  
I think trustworthy and honest WG chairs and IAB members are critically
important, and a fair complaint resolution process is also important.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: improving WG operation

[Dean Anderson]

On Sun, 8 May 2005, Sam Hartman wrote:

> > "Tom" == Tom Lord <[EMAIL PROTECTED]> writes:
> 
> Tom> All I mean is that, for higher level protocols, letting
> Tom> people do what they will ("the market decides") seems to me
> Tom> to be the best option.  Yes, using your example, IM protocols
> Tom> fragment, interop suffers, there's lots of crap --- so what?
> 
> 
> I think our concern is that we have finite resources here in the IETF.
> If you want a market decides standards, go set up an industry
> consortium or go to a market decides standards body.

The market always decides.  And people will always "do what they will".  
If you want different standards, you can always go to another standards
body. There are many to choose from.

However, before the market can decide, standards must be chosen, and put
forth. Standardizing what the big vendors want isn't really
"standardization". That's just rubber-stamping a big vendor.  Since the
big vendors can create their own defacto standards without the need for
rubber stamps, such groups tend not to last too long.

There may indeed be improvements to the IETF process, but the fundamental
ideas have worked reasonably well, and radical divergence isn't necessary.  
It is sign of good health that people are seeking improvements.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: french crypto regulations relating to personal encryption usage by visitors?

[Dean Anderson]

On Sat, 2 Apr 2005, Jaap Akkerhuis wrote:

> To my opinion, one threat to the international nature of the IETF are
> the continuous increasing difficulties entering the US. This morning I
> read in the local papers that starting the 25th of october the
> Visa-Waiver program will grind to a halt for (most) Europeans.

And as an American, I'd just like to say that this is an embarrassment to 
me.  Free trade, but not free travel. How can you have one without the 
other?

In the NYTimes this week was an article about a Uruguayan Flight
Instructor who worked at the Oklahoma Flight School attended by Moussaui
(sp?) the so-called 20th hijacker.  He was very cooperatative with the
FBI, and wound up on a no-fly list, apparently as a result of his
cooperation--The FBI found him helpful, so they wanted to keep track of
him.  So now he isn't allowed to learn to fly light business jets, the
logical next step in the career of a professional pilot.  Sigh. I have to
find a hole to crawl into, to hide my shame.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: french crypto regulations relating to personal encryption usage by visitors?

[Dean Anderson]

The IETF could write a letter to the appropriate Ministry to ask for a
special exemption.

This may also motivate them to continue the liberalization of the crypto
laws.

'Rarely enforced' doesn't mean that they should be ignored.

--Dean

On Fri, 1 Apr 2005, Bill Sommerfeld wrote:

> As the next IETF meeting will be in Paris, and France has had something
> a reputation for placing strict controls on the use of cryptography, I
> took a look..
> 
> (This is, of course, a matter of potential concern to those of us who
> carry laptops with encryption software for personal use to every IETF
> meeting...)
> 
> It appears that France may have recently substantially liberalized its
> regulation of cryptography.  A site at:
> 
> http://rechten.uvt.nl/koops/cryptolaw/cls2.htm#fr
> 
> has what claims to be a summary.  There appears to be a personal use
> exemption of some sort but there's no mention of re-export of the laptop
> you imported when you entered the country..
> 
> I'm not particularly worried as most of these laws are rarely enforced
> in other countries.  Anyone have a better idea?
> 
>   - Bill
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: reduce jitter in routed network for voip applications

[Dean Anderson]

On Mon, 28 Mar 2005, Daniele Giordano wrote:

> RTP is transparent at the transport layer. We analyse TCP and UDP:
> TCP is connection oriented and so the communication begins with the
> definition of a virtual circuit.
> A virtual circuit is a temporary connection of sequence nodes with relative
> reservation of bandwidth.
> A connection oriented service gives the certainty that all information units
> use the same nodes with a same medium latency.
> Same latency maintains reduced the jitter.

The variable latency is usually introduced as a result of queuing due to
transient congestion in the path, and to a lesser extent, due to path
variations due to load balancing.  It has (almost) nothing to do with
whether the packets are TCP or UDP.  QOS protocols may alter the queueing
priorities, but QOS should be helping to reduce VOIP latency by pushing
the VOIP packets to the front of the transmission queue.

Extensive testing done at Genuity around 2000 showed that congestion is
mainly a problem in the tail circuit and that low latency queuing (and I
think smaller MTU) allowed good RTP latencies right up to full t1
utilization. Partly, this solution is specific to Genuity, which had (I
think)  larger than typical headroom in the core.

RSVP won't really do much unless you have end-to-end implementation--I
won't go into any criticisms of RSVP, but suffice it to say I think its
still a work in progress (good work, but more needed), and as a practical
matter isn't widely implemented in the general internet and isn't likely
to be widely implemented between carriers, I think. RSVP as it stands is
really only useful to some fortune 500 companies that have their own
large, private, wide area networks.  QOS in the core networks is
impractical for a number of reasons.  Building in excess headroom is a
good idea for a voip network.  A voip-only side-network is also a good
idea.

I don't think TCP is a solution to latency. Indeed, that would possibly
subject voice streams to RED and WRED congestion control.  (these drop tcp
packets randomly to cause windowing reductions to reduce packet rates
which then reduces congestion)

> I think that RTP should use a layer 4 connection oriented protocol (like
> TCP) but without retransmissions of information units with excessive delay
> or errors (like UDP).
> 
> What do you think about this?

What connection oriented features would you add besides retransmission and 
windowing? You said that your'd remove retransmission, and windowing is 
already essentially implmented in the jitter buffer.

One could say that (voip) RTP is already connection-oriented with H323 and
SIP handling the RTP connection setup issues. Usually, this is necessary
because the h323 and SIP functions are intimately tied to call routing and
stream setup.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: reduce jitter in routed network for voip applications

[Dean Anderson]

On Sun, 27 Mar 2005, Daniele Giordano wrote:

> voip applications use connectionless layer 4 protocols and this increases
> jitter. A layer 4 connection oriented protocol limits jitter but it must not
> use packet checks in voip applications.

Connection oriented protocols don't limit jitter. Jitter is the same no
matter what. However, a very late packet is discarded by a jitter buffer.  
(you don't care what joe said 10 seconds ago--if it didn't get here in the
jitter buffer, its too late.)  But it would not be discarded by a
connection oriented protocol. You'd hear what joe said 10 seconds ago, and
then you would have to wait 10 seconds to hear what joe just said. This is
OK for streaming a song. Its not fine for two way voice.

> Is there an intefrace between TCP and UDP? Isn't there a "TDP" (transfer
> datagram protocol) that joins the two features?
> What do you think about this?

Right protocol for the right purpose.  We already have RTSP for streaming, 
and RTP for voip.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'The wais URI Scheme' to Historic

[Dean Anderson]

I'm in agreement with the purpose of updating these (and probably other 
documents) to reflect the current state of affairs.

My comment is that the it is RFCs that move through the process, not parts
of RFCs. So, it would seem to me that an update to RFC 1738 needs to be
written: that drops wais, etc, and includes telnet, etc to be moved to
Proposed Standard status. RFC 1738 can then move to Historic.  If there
are still experimental URIs, then they should be documented as such,
reflecting their current status.

Maybe you are doing that already, and I missed it or it wasn't clear. If 
so, I'm sorry.

--Dean

On Mon, 7 Feb 2005, Larry Masinter wrote:

> I previously sent my comments to the IESG, but I was
> asked to re-raise the issue on the IETF mailing list
> because  "... The IESG at this point 
> seems to want public guidance on a document by document
> basis..." on the topic of how to move old documents
> or protocols to Historic status. In this case, it is
> the raft of URI schemes currently only documented in
> RFC 1738.
> 
> So, to recap:
> 
> I think it is good to update the URI scheme documents
> that are in widespread, current and growing use:
> "ftp", "file", "telnet" to move these beyond their
> "Proposed Standard" status, update the descriptions,
> and bring the results along on standards track, by
> insuring that the documents are consistent with
> widespread interest.
> 
> I think it is a bad idea to issue new documents for
> URI schemes merely to move those schemes to Historic
> status, "wais", "prospero", and even "gopher". I include
> "gopher" even though there may be active or even new
> "gopher" client implementations, because I don't believe
> the gopher protocol or the gopher URI scheme will ever
> move to full standard.
> 
> Does anyone see any real need to issue a new
> document on the "gopher" URI scheme merely
> to declare it "Historic"?
> 
> Larry
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Proposed consensus text: #725 Appealing decisions

[Dean Anderson]

On Fri, 28 Jan 2005, John C Klensin wrote:

> "...believed to violate..."
> "...putatively violates..."
> "...alleged to violate..."
> 
> and other phrases would, I think, satisfy both Scott's concerns
> and yours.

Sure, I'm good with that. How about:

"...an explanation of how the decision or action is thought to violate 
the BCPs..."

> These are the sort of language/presentation details that I wish
> we could assume that final editing would straighten out.  It is
> not a good sign that we think we need to fix them on the IETF
> list.

Oops, I thought that had been done, and we were looking a final drafts.

>john
> 
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Proposed consensus text: #725 Appealing decisions

[Dean Anderson]

On Fri, 28 Jan 2005, Scott W Brim wrote:

> On Fri, Jan 28, 2005 03:02:00PM +0100, Harald Tveit Alvestrand
> allegedly wrote:
> >The request for review is addressed to the IAOC chair and should
> >include a description of the decision or action to be reviewed,
> >an explanation of how the decision or action violates the BCPs or
> 
> violates -> is presumed to violate

The text is correct as is. "Presume" is to "assume before". Indeed,
perhaps the decision under review may be presumed not to violate before 
the review concludes otherwise.

The explanation to be given to the review is about how and why the
decision under review should be found to violate something. It would be 
incorrect to say "...an explanation of how the decision or action is 
presumed to violate the BCPs..."

In court, the defendant is presumed innocent. That is, they are assumed
before a decision to be innocent. The prosecution presents an explanation
of why they should be found guilty, not why they are presumed guilty.  
Indeed, they should not be presumed guilty, and no one should need to
explain why that happened, except perhaps after someone's civil right to 
presumption of innocence was violated.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Legal review results 1: Intellectual property (fwd)

[Dean Anderson]

This didn't seem to make it

-- Forwarded message --
Date: Wed, 26 Jan 2005 15:51:43 -0500 (EST)
From: Dean Anderson <[EMAIL PROTECTED]>
To: "Contreras, Jorge" <[EMAIL PROTECTED]>
Cc: ietf@ietf.org, Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Subject: Re: Legal review results 1: Intellectual property (fwd)


Did you get a look at this below? It seems to have been lost in the noise, 
so I'll repost.

The notion of giving source code but retaining patent rights is not
entirely academic.  Novell asserted (for a while anyway) that it never
transfered patents covering Unix to SCO.  Some people/companies are
certainly interested in selling/transferring copyright and patent rights
separately, as well as trademarks (e.g. the Unix trademark now owned by
The Open Group)

The IETF needs to get everything necessary to use the software and/or
data, and everything necessary to give the software/data to someone else
to use.

--Dean


-- Forwarded message --
Date: Mon, 24 Jan 2005 00:09:57 -0500 (EST)
From: Dean Anderson <[EMAIL PROTECTED]>
To: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Cc: ietf@ietf.org
Subject: Re: Legal review results 1: Intellectual property

One problem:

One can have full control over the software source code copyright but not
over the patents that cover use of the software.  If you don't have a 
patent license, you can't use patented software.  

The text should be modified to include specifications that one is given
control over the applicable copyrights, patents, and trademarks as
necessary for use by the general public.  As someone pointed out, open
source software should meet the definition. Open patents should also meet
this definition.

Aside: This is an example of why you should avoid the term "intellectual
property". There is really no such thing as "intellectual property".  
Instead there are patents, copyrights, and trademarks. Each of these are
unique.  Thinking of a single concept of "intellectual property" leads one
to miss the differences between them.  "patents, copyrights, trademarks"  
is just a few more letters to type, and leads to much greater clarity.
"intellectual property" is a term, like "partial-birth abortion" that was
made up by one side to advance its views. Neither are technical terms.  
Both are misleading.

--Dean


On Fri, 21 Jan 2005, Harald Tveit Alvestrand wrote:

> In this and a few later messages, I'm relaying comments from Jorge 
> Contreras, the IETF's pro bono legal counsel.
> 
> 1.  Intellectual Property.  I think I understand the reason for including 
> an explicit requirement that IP created in support of IETF activities be 
> usable by IETF on a perpetual basis.  The way this concept is expressed, 
> however, should probably be adjusted slightly to reflect the way IP rights 
> are actually conveyed and licensed.
> 
> Old Text (Sec. 3.1, paragraphs 5-6)
> 
> The IAD is responsible for ensuring that all contracts give IASA and
>the IETF the perpetual right to use, display, distribute, reproduce,
>modify and create derivatives of all data created in support of IETF
>activities.  This is necessary to make sure the IETF has access to
>the data it needs at all times, and to ensure that the IASA can
>change contractors as needed without disrupting IETF work.
> 
>Whenever reasonable, if software is developed under an IASA contract
>it should should remain usable by the IETF beyond the terms of the
>contract.  Some ways of achieving this are by IASA ownership or an
>open source license; an open source license is preferable.  The IAD
>shall decide how best to serve the IETF's interests when making such
>contracts.
> 
> Suggested new text (Sec. 3.1, paragraphs 5-6)
> 
> (A)  If a contract entered into by ISOC on behalf of IASA and/or the IETF
> (an "IASA Contract") provides for the creation, development,
>  modification or storage of any data (including, without limitation, any
> data relating to IETF membership, documents, archives, mailing lists,
> correspondence, financial records, personnel records and the like)
> ("Data"), then the IAD shall ensure that such contract grants to ISOC
> the perpetual, irrevocable right, on behalf of IASA and IETF, to use, 
> display, distribute, reproduce, modify and create derivatives of such Data.
> ISOC will permit IASA and its designee(s) to have sole control and
> custodianship of such Data, and ISOC will not utilize or access such
> Data in connection with any ISOC function other than IETF without
> the written consent of the IAD.
> 
> (B)  If an IASA Contract provides for the cre

Re: Legal review results 1: Intellectual property (fwd)

[Dean Anderson]

Did you get a look at this below? It seems to have been lost in the noise, 
so I'll repost.

The notion of giving source code but retaining patent rights is not
entirely academic.  Novell asserted (for a while anyway) that it never
transfered patents covering Unix to SCO.  Some people/companies are
certainly interested in selling/transferring copyright and patent rights
separately, as well as trademarks (e.g. the Unix trademark now owned by
The Open Group)

The IETF needs to get everything necessary to use the software and/or
data, and everything necessary to give the software/data to someone else
to use.

--Dean


-- Forwarded message --
Date: Mon, 24 Jan 2005 00:09:57 -0500 (EST)
From: Dean Anderson <[EMAIL PROTECTED]>
To: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Cc: ietf@ietf.org
Subject: Re: Legal review results 1: Intellectual property

One problem:

One can have full control over the software source code copyright but not
over the patents that cover use of the software.  If you don't have a 
patent license, you can't use patented software.  

The text should be modified to include specifications that one is given
control over the applicable copyrights, patents, and trademarks as
necessary for use by the general public.  As someone pointed out, open
source software should meet the definition. Open patents should also meet
this definition.

Aside: This is an example of why you should avoid the term "intellectual
property". There is really no such thing as "intellectual property".  
Instead there are patents, copyrights, and trademarks. Each of these are
unique.  Thinking of a single concept of "intellectual property" leads one
to miss the differences between them.  "patents, copyrights, trademarks"  
is just a few more letters to type, and leads to much greater clarity.
"intellectual property" is a term, like "partial-birth abortion" that was
made up by one side to advance its views. Neither are technical terms.  
Both are misleading.

--Dean


On Fri, 21 Jan 2005, Harald Tveit Alvestrand wrote:

> In this and a few later messages, I'm relaying comments from Jorge 
> Contreras, the IETF's pro bono legal counsel.
> 
> 1.  Intellectual Property.  I think I understand the reason for including 
> an explicit requirement that IP created in support of IETF activities be 
> usable by IETF on a perpetual basis.  The way this concept is expressed, 
> however, should probably be adjusted slightly to reflect the way IP rights 
> are actually conveyed and licensed.
> 
> Old Text (Sec. 3.1, paragraphs 5-6)
> 
> The IAD is responsible for ensuring that all contracts give IASA and
>the IETF the perpetual right to use, display, distribute, reproduce,
>modify and create derivatives of all data created in support of IETF
>activities.  This is necessary to make sure the IETF has access to
>the data it needs at all times, and to ensure that the IASA can
>change contractors as needed without disrupting IETF work.
> 
>Whenever reasonable, if software is developed under an IASA contract
>it should should remain usable by the IETF beyond the terms of the
>contract.  Some ways of achieving this are by IASA ownership or an
>open source license; an open source license is preferable.  The IAD
>shall decide how best to serve the IETF's interests when making such
>contracts.
> 
> Suggested new text (Sec. 3.1, paragraphs 5-6)
> 
> (A)  If a contract entered into by ISOC on behalf of IASA and/or the IETF
> (an "IASA Contract") provides for the creation, development,
>  modification or storage of any data (including, without limitation, any
> data relating to IETF membership, documents, archives, mailing lists,
> correspondence, financial records, personnel records and the like)
> ("Data"), then the IAD shall ensure that such contract grants to ISOC
> the perpetual, irrevocable right, on behalf of IASA and IETF, to use, 
> display, distribute, reproduce, modify and create derivatives of such Data.
> ISOC will permit IASA and its designee(s) to have sole control and
> custodianship of such Data, and ISOC will not utilize or access such
> Data in connection with any ISOC function other than IETF without
> the written consent of the IAD.
> 
> (B)  If an IASA Contract provides for the creation, development or
>  modification of any software (including, without limitation, any
> search tools, indexing tools and the like) ("Developed Software")
> then the IAD shall, whenever reasonable and practical, ensure
> that such contract either (a) grants ownership of such Developed
> Software to ISOC, or (b) grants ISOC a p

Re: Legal review results 1: Intellectual property

[Dean Anderson]

One problem:

One can have full control over the software source code copyright but not
over the patents that cover use of the software.  If you don't have a 
patent license, you can't use patented software.  

The text should be modified to include specifications that one is given
control over the applicable copyrights, patents, and trademarks as
necessary for use by the general public.  As someone pointed out, open
source software should meet the definition. Open patents should also meet
this definition.

Aside: This is an example of why you should avoid the term "intellectual
property". There is really no such thing as "intellectual property".  
Instead there are patents, copyrights, and trademarks. Each of these are
unique.  Thinking of a single concept of "intellectual property" leads one
to miss the differences between them.  "patents, copyrights, trademarks"  
is just a few more letters to type, and leads to much greater clarity.
"intellectual property" is a term, like "partial-birth abortion" that was
made up by one side to advance its views. Neither are technical terms.  
Both are misleading.

--Dean


On Fri, 21 Jan 2005, Harald Tveit Alvestrand wrote:

> In this and a few later messages, I'm relaying comments from Jorge 
> Contreras, the IETF's pro bono legal counsel.
> 
> 1.  Intellectual Property.  I think I understand the reason for including 
> an explicit requirement that IP created in support of IETF activities be 
> usable by IETF on a perpetual basis.  The way this concept is expressed, 
> however, should probably be adjusted slightly to reflect the way IP rights 
> are actually conveyed and licensed.
> 
> Old Text (Sec. 3.1, paragraphs 5-6)
> 
> The IAD is responsible for ensuring that all contracts give IASA and
>the IETF the perpetual right to use, display, distribute, reproduce,
>modify and create derivatives of all data created in support of IETF
>activities.  This is necessary to make sure the IETF has access to
>the data it needs at all times, and to ensure that the IASA can
>change contractors as needed without disrupting IETF work.
> 
>Whenever reasonable, if software is developed under an IASA contract
>it should should remain usable by the IETF beyond the terms of the
>contract.  Some ways of achieving this are by IASA ownership or an
>open source license; an open source license is preferable.  The IAD
>shall decide how best to serve the IETF's interests when making such
>contracts.
> 
> Suggested new text (Sec. 3.1, paragraphs 5-6)
> 
> (A)  If a contract entered into by ISOC on behalf of IASA and/or the IETF
> (an "IASA Contract") provides for the creation, development,
>  modification or storage of any data (including, without limitation, any
> data relating to IETF membership, documents, archives, mailing lists,
> correspondence, financial records, personnel records and the like)
> ("Data"), then the IAD shall ensure that such contract grants to ISOC
> the perpetual, irrevocable right, on behalf of IASA and IETF, to use, 
> display, distribute, reproduce, modify and create derivatives of such Data.
> ISOC will permit IASA and its designee(s) to have sole control and
> custodianship of such Data, and ISOC will not utilize or access such
> Data in connection with any ISOC function other than IETF without
> the written consent of the IAD.
> 
> (B)  If an IASA Contract provides for the creation, development or
>  modification of any software (including, without limitation, any
> search tools, indexing tools and the like) ("Developed Software")
> then the IAD shall, whenever reasonable and practical, ensure
> that such contract either (a) grants ownership of such Developed
> Software to ISOC, or (b) grants ISOC a perpetual, irrevocable
> right, on behalf of IASA and IETF, to use, display, distribute,
> reproduce, modify and create derivatives of such Software
> (including, without limitation, pursuant to an open source style
> license).  It is preferred that Developed Software be provided and
> licensed for IASA and IETF use in source code form.
> ISOC will permit IASA and its designee(s) to have sole control and
> custodianship of such Developed Software, and ISOC
> will not utilize or access such Developed Software in
> connection with any ISOC function other than IETF without
> the written consent of the IAD.  The foregoing rights are not required
> in the case of off-the-shelf or other commercially-available software
>  that is not developed at the expense of ISOC.
> 
> (C)  If an IASA Contract relates to the licensing of third party software,
> the IAD shall ensure that such license expressly permits use of such
> software for and on behalf of IASA and/or IETF, as applicable, and
> that such license is transferable in accordance with the provisions of
> Section 7 (Removability).
> 
> In addition, the principle stated in 2.2(7) should be expanded to
> incl

Re: Consensus? IPR rights and all that

[Dean Anderson]

Not to interject specifics into a near consensus, but wouldn't it be 
reasonable to require that either:

1) Software to access and alter data be open-source and provided, 

or 

2) data be in a well-defined and documented format for which software to
manipulate the data can be promptly produced (e.g., ASN.1, CSV, XML, Fixed
Length Field etc). Examples: Distribution of genome data is in ASN.1,
distribution of the LERG (Local Exchange Routing Guide -- distributed to
all LECs, CLECs) which is in both MS and fixed length field.  

As long as there is clear, specific, and accurate documentation for the 
file format, access usually isn't a problem.  Indeed, one might think of 
source code as concise documentation. 

--Dean

On Mon, 6 Dec 2004, Leslie Daigle wrote:

> 
> 
> I think this mostly works, though a couple of comments, in-line:
> 
> Harald Tveit Alvestrand wrote:
> > Hi folks,
> > 
> > it seems that we are drawing close to a consensus here:
> > 
> > - Access to data that the IETF has created and needs to function is a 
> > paramount basic principle. Not to be compromised. So it needs to go VERY 
> > plainly into section 2.2 "principles".
> > 
> > - Access to software is a very-nice-to-have, but it's only critical if 
> > not having it limits our ability to effectively access the data. And 
> > open-source is a quite-nice-to-have; we see a number of advantages in 
> > doing things that way, but there may be cases where other considerations 
> > apply. So this belongs in the document, but under "advice", not 
> > "principles".
> > 
> > So - I'd like to propose a specific text change to address that:
> > 
> > Replace the current section from 2.2 that says:
> > 
> >   6.  The right to use any intellectual property rights created by any
> >   IASA-related or IETF activity may not be withheld or limited in
> >   any way by ISOC from the IETF.
> > 
> > with the following:
> > 
> >   6.  The IASA, on behalf of the IETF, shall have an irrevocable,
> >   permanent right of access and later use to all data created
> >   in support of the IETF's activities, including
> >   the right to disclose it to other parties of its choosing.
> > 
> > And in section 3.1 "IAD Responsibilities", add after paragraph 4 ("The 
> > IAD negotiates service contracts"):
> > 
> >  The IAD is responsible for ensuring that all contracts give the IASA
> >  and the IETF the rights in data that is needed to satisfy the principle
> >  of data access.
> >  This is needed to make sure the IETF
> >  has access to the data it needs at all times, and that the IASA can
> >  change contractors when needed without disrupting IETF work.
> >  If software is developed under an IASA contract, the software should
> >  remain usable by the IETF beyond the terms of the contract; this may
> >  be accomplished by IASA ownership or an open source license; an open
> >  source license is preferable. The IAD will decide how the interest of
> >  the IETF is best served when making such contracts.
> 
> This reads to me like the IAD can choose to have that software owned by
> the IETF or open sourced, but nothing else.
> 
> And I think that flies if, and only if, such things as providing sums
> of money to ensure that a service provider updates their own software
> to meet our specified needs (e.g., something mundane like a sort
> order on attendance records) is not ever considered "software developed
> under an IASA contract".
> 
> Is it still English, and does it still scratch the itch for others,
> if the 2nd to last sentence is broken up and changed (borrowing from
> Carl's suggestions):
> 
> Whenever reasonable, if software is developed under an IASA contract
> it should should remain usable by the IETF beyond the terms of the
> contract.  This may be accomplished by IASA ownership or an open source
> license; an open source license is preferrable. The IAD will decide how
> the interest of the IETF is best served when making such contracts.
> 
> 
> Leslie.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

On Thu, 21 Oct 2004, Eric S. Raymond wrote:

> Brian E Carpenter <[EMAIL PROTECTED]>:
> > I don't think we can require the IESG to negotiate anything. There are
> > all kinds of legal issues there. To my knowledge, both WGs and the IESG
> > do think carefully about this, but often conclude that the default IETF
> > conditions (RAND) are realistic and acceptable.
> 
> If IETF continues to believe this, groups like Apache and Debian will continue
> to have to end-run IETF by doing the job of defending the Internet commons
> that IETF is abdicating, and IETF's authority will evaporate.

Neither of the groups you mention are standards organizations. They can't
"end-run"  the IETF because they don't produce standards, any more than
Microsoft produces standards. Nor can they "end-run" the IETF any more
than Microsoft can end-run the IETF. The "defacto standards" promoted by
one company are often rejected by the wider community, even though they 
might have a profitable and sizeable user base.

It is also not the IETF's role to "defend the internet commons". It is the
IETF's role to produce open standards.  Defense of the internet commons,
while necessary and good, is not a job of the IETF, nor is it a job the
IETF can take on at present.  The FSF and other groups (including Apache
and Debian) are doing a good job of defending the internet commons.

> It is not 1982 or even 1992 any more.  Conditions have changed dramatically.
> I would hate to see IETF dwindle into irrelevance, but that is exactly
> where statements like this are pointing.

People are interested in standards and useful technology, and will be for 
the forseeable future. 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

On Tue, 19 Oct 2004, shogunx wrote:

> >
> > When the open-source tide really turns, and the best quality source code
> > and technology is free, then it will be subject to theft of the sort where
> > it is made improperly not-free.  Then it will be the open-source community
> > that is trying to enforce the copyright and possibly even patent law. That
> > is why alterations must be careful.
> 
> This is already the situation in many parts of the world, with the
> developers left little recourse.

Things are in a very sorry state.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

On 19 Oct 2004, Paul Vixie wrote:

> > I've been around for decades and know at least a few people who have
> > written more than 10,000 more or less freely redistributable and popular
> > lines.  Few of them are members of either your or Mr. Stallman's
> > organizations, although both of you frequently claim to speak for us.

I suspect that if one were to count lines of source or number of packages,
you would find the majority of "open source" code to be under GPL. The
suggestion Mr. Schryver makes above is pretty plainly wrong.  If open
source were a parliamentary system, Stallman and the FSF would be the
prime minister and ruling party.  He represents a lot of people.

But of course, the definition of "open source" is itself somewhat vague. I
would not, for example, count Paul Vixie or ISC as an "open source"
proponent; because of his support software patents, his advocacy of the
BSD copyright which allows persons to take this code private if it suits
them, and because Vixie/ISC trademarked other people's software (BIND).
This is all pretty antithetical to the open source goals and mindset as I
see it.

As a short aside: The BSD copyright wasn't made for "open source", but for
allowing the public to exploit and commercialize the University of
California's government sponsored work.  BSD code was originally not open
(though essentially free) due to the inclusion of ATT code.  It just
wasn't necessary to pay Berkeley, except a nominal fee for the 9track
tapes.  I suspect that if the BSD code wasn't DARPA/HP/DEC (and later OSF)
funded, it would very likely have had a copyright more similar to other
Univerity developed code like AFS.  I don't mean to ignore the free
software disposition of people at CSRG, but developers rarely have control
of such decisions.  Most universities have technology licensing
departments to obtain money for University work. The BSD Copyright was
appropriate 15 years ago, for the output of the CSRG and other work.
This codebase certainly assisted the open source movement.  But the BSD
copyright isn't really "open source" by many definitions.  The frequently
cited problem is the profiteering and re-privatization of derived
proprietary propducts.  Some groups haven't liked the infectious nature of
the GPL, but nearly all reject the BSD equivalent copyright.

But such terms as open source are often vague and hard to pin down because
they mean different things to different people. I recall that Sun once
tried to trademark "Open Systems"---if successful this would have turned
things upside-down: making the term "Open Systems"  proprietary to Sun!
Of course, at about the same time Scott McNeely also said that Motif would
never be shipped by Sun.  That turned out to be wrong, too, in small part
to my credit.

> in particular, neither i personally nor isc as a company shares the
> views expressed here by mr. raymond with respect to ietf's patent
> policies.  i think of myself, and of isc and the various people who
> have written the software isc publishes, as part of what mr. raymond
> calls "the 5%", and i agree with mr. schryver that mr. raymond's
> claims of representation don't help me and might, by creating
> misunderstanding amongst the consumers of "open source" software, hurt
> me.

I think that's probably right: You are part of the 5% not least because 
you're pro-patent.  Mr. Raymond, Mr. Stallman nor other represent you 
because you aren't really proponent of open source.  You're welcome to 
your point of view, but its substantially different from the open source 
point of view.

If preventing you from using open source software as the basis for your
proprietary products harms you (and I suppose it would in your case), then
I can forsee your concerns.  I suppose if Eric Raymond promotes the idea
that open source software should be free of patents, impossible to take
private, and free of trademark encumbrances, then I suppose that could
hurt //Vixie// and open source profiteers. However, it would prevent open
source profiteers from harming the open source community.  None of this is
purely hypothetical:  EG what Vixie did with the BIND trademark was very
similar to the Linux trademark schenanigans a few years ago)

I think most open source proponents would agree that the proper way to
make money on open source is to package it or offer consulting services to
improve it keeping the modifications open source or install it or
administer it, etc.  I think most would agree that the wrong way is to try
to use open source software as the basis for a proprietary product, by
making propietary improvements that then aren't shared.  Some people
disagree. They are welcome to their opinion.  I wish those people wouldn't
try to pass themselves off as open source proponents.  I can acknowledge
that being pro-patent/closed source is a point of view, and I can even
make accomodation and compromise to work with those people for the greater
good.  And if some think I'm a radical proponent of open s

Re: Shuffle those deck chairs!

[Dean Anderson]

On Mon, 18 Oct 2004, Michael Richardson wrote:

> >> Obviously, there is a problem if a patent claims to invent
> >> something commonplace such as 'xml', and grants its use only for
> >> the purpose of IETF standards or a specific standard.  But I'm
> >> not sure if I recall something like that.

This is a question of licensing and particularly the wording and
limitations imposed by the license.  Hypothetically, it could go either
way.  You would only be permitted to do what the license permits.  If the
license specifically only permits use of the technology for SIP, then you
can't use the patented technology for something else, because "something
else" is not permitted, assuming the language of the license was very
restrictive.  The trick is the specification of the permissions in the
license.  The answer depends on the license wording. Sometimes even
restrictive licenses leave loopholes. Sometimes not.  That's why we have
lawyers.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

On Tue, 19 Oct 2004, Brian E Carpenter wrote:

> Dean Anderson wrote:
> ...
> > When the open-source tide really turns, and the best quality source code
> > and technology is free, then it will be subject to theft of the sort where
> > it is made improperly not-free.  Then it will be the open-source community
> > that is trying to enforce the copyright and possibly even patent law. That
> > is why alterations must be careful.
> 
> s/When/If/ if you want this statement to be read without laughter.

I don't know why you'd think that statement is funny. I suspect that you 
are just completely unaware of the issues.

Certain large organizations have made assertion that the GPL is not valid,
arguing that a contract requires exchange of money.  That is, that the GPL
is not enforceable and that one can take GPL code private.  We would
consider this a copyright violation.  The counter argument is that a
license is not a contract, but a permission. Its a fine point of law for
which there is no direct precedent, so it could be argued in court, and
its //possible//(*) a court could invalidate the GPL. (*)We think that is
unlikely, but it is not impossible.  What is more likely is that someone
simply takes GPL code, uses it in violation of the license as the basis
for a proprietary product. When this is discovered, we would consider this
a copyright violation subject to demands/litigation.  As the quality of
the GPL codebase improves, so does the temptation to steal GPL code in a
proprietary product.

The LPF has also considered in the past holding software patents in order
to ensure that technology remains free.  There are presently individual
patent holders who have obtained patents just to make sure that licensing
remains free, who have suggested that the LPF is a better repository for
these patents, than individuals.  When the US changes to first-to-file,
creation of a free patent repository may be the _only_ way to prevent
non-inventors from patenting technology.  The first-to-file change is
presently required under treaty, and we expect that it will be
implemented. The best hope at present is that we obtain a change in
whether software can be patented.  Venture Capital is finally coming 
around to the LPF viewpoint, so a change may be possible.

There is also a group working to weaken copyright law so that software
would not be protected in the same way other works are. This group is
apparently responding to the SCO-IBM lawsuit. While well-intentioned, such
a weakening would probably have a long-term harm to open-source.  I would
prefer them work on a change to patent law so that free software is not
subject to patents instead.

> But you're right, of course. If *you* held all the software patents,
> *you* could decide who got to use them.

The point of a free patent repository is to make sure that _everyone_ gets 
to use them for free.

> Meanwhile, the IETF process deals with the real world, not with
> hypotheticals.

If you think these are hypotheticals, then you are seriously uninformed.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

On Fri, 15 Oct 2004, Paul Vixie wrote:

> > ...  notwithstanding, how can a specification be considered a standard
> > if over half of the operators on the planet refuse to deploy it
> > because of patent/licence issues.
> 
> i can't understand why this matters.  if ietf were to change its policies
> so that only "open technology" was allowed in the standards, there would
> still be patent fights (both from submarines and ships-in-the-night).

Well, given that Mr. Vixie told me that he is a supporter of software
patents, and that we know he only supports BSD-style copyrights which can
be taken closed source, and is someone who has claimed trademarks on other
peoples software, it is more obvious why he doesn't understand 'why it
matters'.

So I'll explain why it matters.

There is a pro-patent/closed-source point of view, and there is an
anti-patent/open-source point of view. These sides are not difficult to
understand.  But they take some effort to reconcile into cooperation on
standards. Why should they be reconciled? Because there are a lot of
constituencies in the IETF: There are many large, closed-source,
pro-patent vendors that we want to have participate in the IETF. There are
also many groups that implementing anti-patent, open-source technology
under a variety of copyrights.  The particulars of the copyright vary from
group to group, and reflect the goals and ideals of each group. There is
no consensus on the "one-great-copyright", even though each group probably
thinks theirs is best.

In order to obtain benefits of standardization and interoperablilty, the
IETF (and other standards organizations) have made some compromises:  
Patent claims must be disclosed early, and there is no requirement that
implementation of protocols be made free or open-source. There is no
obstacle to open-source either. Each working group is able to evaluate and
select technology based on many factors, including whether the technology
is subject to patents.  However, patents need not stand in the way of
standardization if the working group decides to adopt the technology. 

Patents were a significant obstacle for the IETF-MX working group. They
were not an obstacle for certain PPP RFCs, and perhaps other RFCs.  The 
ITU has similar policies and some ITU standards are subject to patents. 
Usually, the assurance of fair and universal licensing was an important 
consideration.

It is important not to adopt a knee-jerk anti-patent position.  That this
is important can be seen:  It is not just pro-patent organizations that
may obtain patents.  Anti-patent organizations may find it necessary to
patent technology in order to ensure that the technology remains free.  
Like many other areas, knee-jerk, absolutist responses are wrong, and a
more nuanced approach is necessary.

Similarly, Open-Source organizations such as GNU and others depend on the
copyright law to keep open-source remaining open.  If the copyright law
were weakened, then GPL code would be vulnerable to being stolen and made
closed.  So it is important that copyright remain.  

When the open-source tide really turns, and the best quality source code
and technology is free, then it will be subject to theft of the sort where
it is made improperly not-free.  Then it will be the open-source community
that is trying to enforce the copyright and possibly even patent law. That
is why alterations must be careful.

However, the tide hasn't yet turned. But even after the tide does turn
there will still be many players who will still pursue closed-source,
patented solutions. We will still need to accomodate them for sometime
even as a minority.  So, the IETF will probably be the last organization
to be purely open-source.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

There are very good arguments as to why "intellectual property" and
derivatives should be avoided as a term.   One should talk instead about 
patents, copyrights and trademarks instead. The issues represented by the 
three are substantially different among the three and they can't be 
successfully generalized.

To illustrate the inappriateness of the "intellectual property" as a term,
all we have to do is examine the current state of patents, copyrights, and
trademarks:  It is unlikely that Patents are on the way out. It may be
that software patents are on the way out. It may be that biotech patents
are on the way out.  It is unlikely the copyrights are on the way. It may
be that copyright abuse may be limited.  It is unlikely that trademarks
are on the way out.

--Dean


On Tue, 12 Oct 2004, Ted Faber wrote:

> On Tue, Oct 12, 2004 at 09:44:02PM +0200, Iljitsch van Beijnum wrote:
> > On 12-okt-04, at 19:36, Thomas Gal wrote:
> > 
> > >and IP is on it's way out
> > 
> > Please note that in the IETF the letters "IP" first and foremost mean 
> > "Internet Protocol". To use them for something else is confusing.
> 
> To forestall the question, when communicating with the IETF one
> shortens "intellectual property" to "IPR."  You can pretend it
> abbrieviates "Intellectual Property Rights" or "Intellectual PRoperty."
> It replaces both phrases in discourse and writing.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

On Tue, 5 Oct 2004, Eric S. Raymond wrote:

> Eliot Lear <[EMAIL PROTECTED]>:
> > We're not out to rid the world of patent-laden work, nor are we out to 
> > make patent owners rich.  The IETF exists to promulgate relevant and 
> > correct standards to the Internet Community, and educate people on their 
> > intended safe use. 
> 
> You'll talk yourself right into the dustbin of history with that line.

Its always the people that have the The Final Ultimate Spam Solution that
shrilly and stridently claim it must be "done now!" or its "into the
dustbin".  In fact, the only thing that has gone "into the dustbin" are
some of the wacky anti-spam schemes, like open relay testing/blocking.

> Reality check: Apache has 68% market share.  Open-source MTAs handle 85% of
> all email traffic.  

Yea for open source!  

Reality check: The IETF is not here to promote __open source__, only open
standards.  There is a subtle but important difference.  If you can't
distinguish between them, you need to learn a bit more about them.  And
if you can distinguish between them, perhaps you need to make an effort to
work with people who don't share your views.  Important participants in
the IETF are not proponents of open source, and some important
participants are also pro-patent.  We make some compromises to work with
them. They make some compromises to work with us.  Eliot Lear describes
those compromises: The IETF is neutral on patents (with disclosure), and
produces open standards which may be implemented in closed source.

> When Meng Weng Wong was thinking about how to evangelize SPF, his first
> instinct was to bypass IETF and go straight to the open-source MTA
> developers -- I had to lobby hard to persuade him to go through the RFC
> process, and now I wonder if I was right to do that.

The RFC process was the right decision because as a result of the
objective critical technical analysis by many people, it was shown that
SPF doesn't stop spam, and that it actually makes a number of problems
worse (i.e. it causes one to get 100% of backscatter, instead of just the
backscatter from non-existant addresses).  And further, it was evident (at
least to me anyway) that SPF/Sender-ID were also targets of exploitation
by spam-profiteers.

By contrast, If Meng Weng Wong had just written his own document without
benefit of objective critical technical analysis, a lot of system
administrators who are unable to perform the necessary critical analysis
would have gone along with the recommendations and wasted their time and
effort deploying something that was just going to make their problems and
the problmes of others much worse.  And then the spam-profiteers would
have decended anyway with patents and other schemes, anyway.  The effort 
would finally be abandoned, and technical progress delayed.  

As it stands, Meng Weng and others can continue researching other avenues 
that may lead to something productive. Or not. But the rest of the world 
isn't wasting its time on this particular scheme that won't work.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Shuffle those deck chairs!

[Dean Anderson]

On Wed, 6 Oct 2004, Randy Presuhn wrote:

> Hi -
> 
> > From: "Scott W Brim" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, October 06, 2004 4:54 AM
> > Subject: Re: Shuffle those deck chairs!
> ...
> > The US patent office is overwhelmed, and acting like it's under a DoS
> > attack.  I agree it would be great if we all offered technical
> > assistance, but not as the IETF.  If needed we could create some other
> > organization.  Let the IETF have a clear focus.
> ...
> 
> I've heard claims that the patent office will be switching to a European-style
> "first-to-file" process, rather than the current "first-to-invent".  Would this
> make matters better or worse?

It makes things much worse: No more will you be able to challenge a patent
based on the premise of prior art.

I'm not sure what the legislative schedule is for the change, but
grandfather/transititional legislation has already been passed: An
exception has been put into place so that you really did invent the
technology, you can't be prevented from using it. 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   





___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf

Re: Patents (Re: Shuffle those deck chairs!)

[Dean Anderson]

On Tue, 5 Oct 2004, Harald Tveit Alvestrand wrote:

> Since I'm not at my best in being clear this week..
> 
> I agree very much with ESR that current US IPR practices are a huge 
> problem, and that the IETF needs to deal with these issues in a rational 
> fashion.



Its not US IPR practices that are a problem, comparatively.  It previously
had a 17 year limit, which has now been extended to 21 years, same as
Europe & elsewhere. Actually, the practices in nearly the entire developed
and developing world are worse. Except for GATT changes, the US is the
still most reasonable at present, and that's a sorry state, too, but still
better than elsewhere. The US, unlike most of the rest of the world, has a
first-to-invent rule, so that prior art can (for now)  invalidate a
patent.  The rest of the world (or nearly so) has a first-to-file rule,
which means the first one to dash to the patent office gets the prize.  
Clearly, those large companies that can pay to have lawyers with offices
across the street will have an advantage over everyone else.

The bad news is that the US is obligated by the GATT Treaty to move to a
first=to-file rule. It has already moved from 17 year terms to 21 year
terms as required by GATT.

> Unlike ESR, I think that it's possible to find such a rational fashion 
> within the formal structure of the present IETF IPR rules - that we have a 
> number of patents on IETF-specified technology that do not create any 
> problem for implementors, and that we need to build on and extend those 
> examples into true "best current practices" (the OTHER meaning of the term, 
> not "IETF rules").
> 
> I don't think the IETF can rid the commons of patents.
> I do think we (the community) have a chance at finding ways to render those 
> patents that crop up in the commons harmless.

This is quite wrong.  Indeed, its not the bad patents that scare me. They
cost money and harm a relatively few companies, and enrich some lawyers.
Rather, its the truly novel patents that cause the most damage.  They have
the potential to cripple entire subject areas. Being truly novel, they
won't be reversed, and will stand.  And being novel, they may be hard or
impossible to overlap and cross-license.

--Dean



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf