Subject: Re: Reminder: Poll about restructuring options

From: [email-masked] (Kai Henningsen)
Date: 01 Oct 2004 18:51:00 +0200

[email-masked] (Brian E Carpenter)  wrote on 30.09.04 in <[email-masked]>:

> A poll that asks for choice between X, Y and Neither seems like
> the only rational way forward in that situation.

Only Harald disagrees with that, because that is certainly not the  
question his poll asked - there was no "neither" option.

Now, I don't expect such an option to collect any significant number of  
votes - but extremely lame arguments as to why an entirely different  
question is the correct alternative certainly don't impress me.

MfG Kai

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Oct 2004 20:09:49 +0200

> question his poll asked - there was no "neither" option.

Nor need there be.  If the leadership is down to these two choices and 
one of them is going to be The One<tm>, then you might as well run with 
those two choices.  Even if the leadership want to know hypothetically 
which one is best, there is still no need to have to state "I don't like 
either".

Everyone has had plenty of airtime on this issue.

Decisions, please.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sat, 02 Oct 2004 12:55:41 -0400

--On Friday, 01 October, 2004 20:09 +0200 Eliot Lear
<[email-masked]> wrote:

> Kai Henningsen wrote:
>> Only Harald disagrees with that, because that is certainly
>> not the   question his poll asked - there was no "neither"
>> option.
> 
> Nor need there be.  If the leadership is down to these two
> choices and one of them is going to be The One<tm>, then you
> might as well run with those two choices.  Even if the
> leadership want to know hypothetically which one is best,
> there is still no need to have to state "I don't like either".

Eliot, 

I have hoped to not have to get into this explicitly, and have
been talked out of it (or talked myself out of it) several
times.  But part of your note calls for a response.

"The Leadership" (the reason I'm capitalizing that term will be
clear below) has only the authority that the IETF community,
rather explicitly, gives them.  We have, for example, given the
IESG rather broad authority to interpret the standards process
and to determine community consensus on what should be
standardized.  Even there, that distinction is important -- the
IESG has no authority to make or proclaim standards on their own
and has not attempted to do so.  But, to take the IESG as an
example, there is nothing in the various procedural documents
that gives them _any_ authority to reorganize the IETF, create
new organizations, etc.

Without such authority, there is rather little difference
between 

	* Harald (whom I'm picking out only because of the chair
	he occupies, not because of anything he has or has not
	done) standing up and saying "I am the IETF Chair.  With
	IESG and IAB support, I have decided X" and
	
	* Joe Blow (a hypothetical person) standing up and
	saying "I am the Bozo.  With the support of a dozen or
	two of my close friends, I have decided Y"

Now, I'm actually a big fan of leadership (small "l").  Without
it, especially in a complex discussion, there are high odds of
everyone going off wandering in the weeds.  So I appreciate the
efforts and good intentions of Leslie, Harald, the IAB and IESG,
and those they have worked with, to draw these issues together
into coherent form and to offer good summaries and advice to the
community on what _The Community_ should decide.   Those efforts
to summarize the issues and delineate and differentiate choices
have been at least moderately successful in some parts of this
and, in my personal opinion, rather disappointing in others (as
has been pointed out, my producing a summary of an even more
complex discussion and not being able to get it under 360 lines
is not a sign that we have understood all of the issues in a
crisp way).

> Everyone has had plenty of airtime on this issue.

But I get very concerned, partially because of my doubts about
the extensive training and experience of most of the IAB and
IESG in organizational behavior and structures, enterprise-level
management, large-organization budget management, contracting
and handling multiple subcontractors with interlocking tasks and
critical deadlines, etc., when someone says something that
sounds to me like "ok, start behaving like the King(s) (or
Tyrant(s)) you are and decide for us".   We need either clear
community consensus on where we are headed, or clear community
consensus that the IESG and/or IAB (or their Chairs) really
should have decision authority for the community in this
non-standards area.    I suggest we have neither at the moment,
although community consensus seems to be becoming more clear on
some parts of the issues.

   john

---

From: Eliot Lear <[email-masked]>
Date: Sun, 03 Oct 2004 15:54:19 +0200

John,

I agree with you that there is reason to be concerned about a group of 
technical people who are not lawyers having to make decisions about the 
organization.  However, I don't see delay at this point in time 
assisting our cause.  In fact, the general membership of the IETF 
(whatever that means) has very few lawyers, and probably very few MBAs. 
  One would have to wait a LONG time for community consensus.  As it is 
I question the validity of the poll answers simply based on the 
qualifications of the respondents to answer.  Rather I hope that the 
considerably smaller group has been consulting subject matter experts on 
the best ways to go forward.

As I responded to Margaret, if you want me to lawyer up, fine but that 
costs time and quite frankly which one of 0 or M (or any other) gets 
chosen doesn't seem worth waiting.  That a decision gets made by people 
we in fact empowered through the NOMCOM process (the IAB & IESG) seems 
to me more important.  If you do not like the decision you have every 
right to make your displeasure known to the NOMCOM.  And If the 
[Ll]eadership of this organization screws up badly enough, the Internet 
Community *WILL* route around the damage.  It's happened before.  That's 
how W3C came to be.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Sun, 03 Oct 2004 15:11:24 -0400

Eliot,

I'm obviously not being successful at explaining what I'm
concerned about it and my getting this deeply drawn into this
whole discussion violates a promise I made to myself some time
ago, which was to concentrate my IETF time on only those things
in which I had a strong technical interest and was convinced
would go somewhere.  So, having posted the "clerk's office"
note, which I think ought to be much more relevant and important
than this one, I give up.  Three parting observations:

	(1) I actually agree with the conclusion that seems to
	be emerging.  I am worried, deeply, about means and
	process, not about ends and results.
	
	(2) The Nomcom process is good for many things, but has
	repeatedly and convincingly demonstrated that it is not
	effective in "curing" the IESG or IAB of particular
	forms of bad behavior.  It has been especially
	ineffective at curing behavior consistent with the
	belief that the "leadership" is in control of the
	organization rather than a reflector, facilitator, and
	determiner of consensus.  That is either a problem or
	not, depending on whether we care: it has often been
	observed that most organizations end up with the
	leadership they deserve, regardless of the selection
	mechanisms used to pick them.
	
	(3) We claim to not believe in voting or Kings, but in
	rough consensus, running code, and an extremely open
	process.  So we are trying to make decisions by counting
	"votes" in not-particularly-well-crafted polls.  The
	IAB and IESG continue to appoint secret (i.e., not
	announced and minuted) committees to hold secret (i.e.,
	not announced in advance to the community) meetings,
	despite promises in San Diego that this would stop.  And
	I think you and others are arguing, with the very best
	of intentions, that leadership groups, who have not been
	selected using criteria that include qualifications
	needed to make these sorts of administrative/legal
	decisions, and who have never been authorized by the
	community to do so, should now go off and make precisely
	those decisions -- decisions that might include options
	with which the IETF community has no experience and
	which the experience of other bodies has proven very
	poor.  

Especially about the third issue, I see serious contradictions
with what we claim to be our principles and with what
distinguishes the IETF from the typical, goer-dominated,
"procedures are more important than content", standards body.  I
think that is far more serious than the outcome of these
particular "decisions".  If we change things by giving up the
"no voting", "no kings", "rough _community_ consensus", and
"openness" principles and start ignoring experience comparable
to running code (or the lack thereof) in favor of ideological
arguments, then the particular experiment that is the IETF
itself is over, regardless of what particular decisions are made
in this case and regardless of how long "over" takes to become
obvious.

I wish I were wrong, but I'm just out of energy for these
particular windmills.

     john

--On Sunday, 03 October, 2004 15:54 +0200 Eliot Lear
<[email-masked]> wrote:

> John,
> 
> I agree with you that there is reason to be concerned about a
> group of technical people who are not lawyers having to make
> decisions about the organization.  However, I don't see delay
> at this point in time assisting our cause.  In fact, the
> general membership of the IETF (whatever that means) has very
> few lawyers, and probably very few MBAs.   One would have to
> wait a LONG time for community consensus.  As it is I question
> the validity of the poll answers simply based on the
> qualifications of the respondents to answer.  Rather I hope
> that the considerably smaller group has been consulting
> subject matter experts on the best ways to go forward.
> 
> As I responded to Margaret, if you want me to lawyer up, fine
> but that costs time and quite frankly which one of 0 or M (or
> any other) gets chosen doesn't seem worth waiting.  That a
> decision gets made by people we in fact empowered through the
> NOMCOM process (the IAB & IESG) seems to me more important.
> If you do not like the decision you have every right to make
> your displeasure known to the NOMCOM.  And If the
> [Ll]eadership of this organization screws up badly enough, the
> Internet Community *WILL* route around the damage.  It's
> happened before.  That's how W3C came to be.
> 
> Eliot

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 04 Oct 2004 09:41:57 +0200

John,

--On søndag, oktober 03, 2004 15:11:24 -0400 John C Klensin 
<[email-masked]> wrote:

>       The
> 	despite promises in San Diego that this would stop.

I am sorry that you misunderstood what I said in San Diego.

The IESG and IAB has had the substantive discussion of the restructuring 
right here on the IETF list. That's what we promised, that's what we 
delivered. The cards we have been dealt are on the table.

It has also continued to have discussions among the IESG and IAB, as I 
believe is their right and duty, and to have discussions with the ISOC 
Board of Trustees, also in private, which I believe is their right and duty 
too.

In the course of these discussions, some facts and arguments have come to 
light that I have not yet seen reflected on the list. Those, as far as they 
influence what the IESG and IAB proposes as solutions, need to be brought 
to the list.

But I cannot accept the world picture that your accusatory sentence above 
seems to be painting.

It's WRONG.

                     Harald

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 04 Oct 2004 11:36:06 +0200

Dear John,
your last two mails do not point out all the problems (I am quite 
interested in Dave's remark on IANA), but they give a good account of a 
pure technical (management) problem. Internet is defined as the adherence 
of its users to the documents resulting from the Internet standard process. 
This process is well defined in theory but faces practical problems we can 
name an authoring quality, cost and pertinence loop. Let try to break the loop.

We are in exactly the same situation as every publisher on earth: good 
texts cost. However unlike other publishers we do not pay authors and we do 
not pay media (for example we are proud RFC documents are free, while ITU 
documents are not). What every publisher on earth -  and on the net - do 
when his revenues do not match the costs of his publication (readers do not 
pay, or do not pay enought)?

Three possibilities :
- either he pays (in our case : volontary work and contributions)
- either advertizing pays the media - it means that sponsors think that 
pertinence will attract readers who will pay them back
- or author pay the service - it means that the authors think quality is 
worth it

Let consider publications like Nature or other professional publishers have 
advertzing pages. Then let think about the following ideas :

- signing a draft (what makes publicity to the author and to the author's 
organization) should be charged in proportion to the author's organization 
possible commercial return. This is actually the case today, but not 
transparently and not oargnizaed so it is not efficient and even 
detrimental). Large organizations spend money ON the IETF (salaries, 
secretariat, translators). This actually slows the process because they do 
not suffer from its increased complexity and are not motivated to simplify 
it. Let now consider that the same total budget is spent BY the IETF: most 
of the problem would be gone because everyone could work in the same 
conditions for better deliverables. Let now consider that the money is 
provided by every Member (what we actually do since voluntaries pay with 
their own time - so they "pay" large organizations for the time their paid 
contributors can more easily spend): everyone would want to go faster.

- this could translate easily in a basic (and polite) information provided 
when joining a WG - listed in the WG page. Who I am, what is my 
organization, what is the amount of time I can spend (salaries), what is 
the turn-over of my organization in datacoms. How much my organization can 
pay to sponsor this effort. Once this is published it would be very poor 
advertizing for an organization not to foot its pledge. But if they don't 
they could explain why ... transparently. Many things could be much clearer 
and benevolent dedication far more acknowledged and assisted. I suppose 
that internationalization could also be helped (non-US firms advertizing 
through their active support of the IETF standard process).

- the interest would also be that before publicly showing interest and 
committing money (they already do it when they tell an employee to join a 
WG) organizations would most probably carry a market study. This would help 
WGs a lot.

- obviously a mechanism should be found for "paying" subjects to sponsor 
more osbcure or research areas. Why nota "Nature-like" publications 
sponsoring IETF meetings. As a result I suppose IETF meetings receiving a 
better coverage could get more sponsoring. WGs would also probably get more 
"dormant" participants who would probably help at the end of the day in 
evangelizing or supporting testing.

Such a system could be easily managed by an indepedent secretariat 
organization gathering the "sponsors" (actually authors and authors 
organizations). All of them being together would nullify the risks of one 
or few taking leadership. All the more if decisions (we are 
in  administrative area only) are voted on a Member basis and not on a 
money contribution basis: contributing one dollar (euro, yen) once for one 
draft would give membership (while showing others if I am a serious 
contributor or a commercial fake). So it would be a resource management 
only organization by authors (large, small, individual and voluntaries) 
only. No impact on the essence of the content, but faster, better, more to 
the point content because a more efficient (fully respected better 
supported) Intenet standard process (cheaper to produce) or more demanded 
content by readers (users). Bill Manning testified that users were the 
problem: they are the IETF readers ... let us attract their interest, they 
will help one way or another - this is what one name commerce.

jfc

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 Oct 2004 06:45:00 -0500

> And If the [Ll]eadership of this organization screws up badly 
> enough, the Internet Community *WILL* route around the damage.  It's 

Erk!

I haven't been involved with W3C since 2000, but I WAS involved in W3C 
during the late 1990s. It's worth pointing out that the "alternate 
routing" mechanism _did_ include a king - at that time, Tim was doing 
final endorsement for all "recommendations", and it looks like 
Director Endorsement is still the case (see 
http://www.w3.org/2004/02/Process-20040205/tr.html#q73).

We need to be careful what we wish for, sometimes... but thinking 
about John's note, and this factoid, is motivating me to finally read 
the drafts!

Spencer

---

From: Eliot Lear <[email-masked]>
Date: Mon, 04 Oct 2004 18:33:32 +0200

Spencer Dawkins wrote:
> final endorsement for all "recommendations", and it looks like Director 
> Endorsement is still the case (see 

You know, Spencer.  We *had* a king for a VERY long time, and it was Jon 
Postel as RFC Editor and IANA.  And somehow we survived.  While Jon was 
around somehow a vast plethora of standards got vetted, not the least of 
which were IP, TCP, UDP, ICMP, SMTP, FTP, SMTP, NNTP and DNS.  I agreed 
with some of his decisions and disagreed with others.  Probably the same 
would be true with Tim Berners Lee.

But you missed my point.  Don't like the IETF or the W3C?  Try the TMF 
or the DMTF or the ITU or the GGF or the IEEE or roll your own (everyone 
else has ;-).  I'm not saying don't make the IETF better.  I think you 
do, by the way, through your participation (same with John Klensin and 
Dave Crocker, fwiw).

I am saying that people have and will route around damage.  Over this 
decision I doubt it will come to this.  I have faith that the people in 
the IAB and the IESG care enough about the organization to listen to 
experts and make a good decision.  I hope my faith is not misplaced.

Regards,

Eliot

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 04 Oct 2004 13:46:56 -0400

I have been trying to be mostly in listening mode, but I'd like to
provide my personal perspective on the process issues.

1/ Openness of process

I don't mind having my mistakes pointed out, but I rather fear
I'm being accused of not having lived up to a promise I didn't
make.  Here's what I actually said on August 27 (on this list
  -- anyone who wants the whole message can dig it up in
the archives):

"We are in agreement that key strategic decisions have to be made
  with the informed consent of the community.  Harald and I have
  made the commitment to put as much on the table as is possible
  to have a rational open discussion that should come before that consent
  phase.  That's the commitment that brought this document out,
  and it will continue to surface material input if, as, and when
  it comes to light. "

And I'm comfortable in asserting this is what we've done.

Have subsets of the IAB & IESG had discussions about this
material?  Yup.  That's what brought us Scenario O and the
revised Scenario C.  To the list.  For public discussion.

Have there been other private discussions with various &
sundry folk?  Yup.  And there will be more.   Are we inking deals at
private breakfast meetings?  No.  If, as, and when private
discussions develop to a point that they can produce concrete
material for discussion/impacting directions, we will put it out
probably with a statement outlining how we see it fits into
the discussional puzzle, and possibly with a recommendation for
action on it.

In my opinion, as someone who's been trying to walk the fine line
between getting people informed to the point of being able to
participate in decision discussions (without boring them to
tears, as some folk evidently are...), and have something
vaguely reminiscent of a convergent decision process, that's
about as good as we can get.

2/ Qualifications of IAB/IESG members, [Ll]eadership

The IAB & IESG members are selected to oversee/run parts of the
IETF process.  The folks I've seen in the roles take that
responsibility pretty seriously.  Apart from everything else,
it means that they see more of the inner workings of the IETF process,
because they have operational experience in trying to get stuff to
happen within it, at a meta-level from what document editors
and WG chairs do.  They can tell when the processes aren't working.
I argue further that they therefore have some sense of what changes
would integrate into the functioning system.  Does that make them MBA's?
Nope.  Does that make them god-like?  Nope.

In my opinion, that does make a reasonable filter function.
That is -- we (IAB & IESG) have been collecting data from
all over, including hired professional input (see, eg,
Carl's document) and the IETF working community itself.
We're weighing it, within the context of the above-stated
responsibilities and perspectives.  We've committed to putting
it back out to the community in the shape of a recommendation
that you can make sense of based on the raw data that you've
got to hand.  That means everyone gets a voice, though not
a vote (the poll helped convince us that people are paying
attention, even if they're not posting...  that was real
data for *us*, anyway!).

So -- I do believe NomCom selected folks are able to credibly
lead this process for change, as long as they know the boundaries
of their own competences and solicit additional input where
needed.  I believe that's true for the overall process discussed
here, and I personally believe it's the appropriate guiding
principle for the role of the IETF & IAB Chair positions in any future
organizational structures.

Leslie.

P.S.:  Don't think I quite made the A4 limit...

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: John C Klensin <[email-masked]>
Date: Mon, 04 Oct 2004 16:42:29 -0400

--On Monday, 04 October, 2004 18:33 +0200 Eliot Lear
<[email-masked]> wrote:

> You know, Spencer.  We *had* a king for a VERY long time, and
> it was Jon Postel as RFC Editor and IANA.  And somehow we
> survived.  While Jon was around somehow a vast plethora of
> standards got vetted, not the least of which were IP, TCP,
> UDP, ICMP, SMTP, FTP, SMTP, NNTP and DNS.  I agreed with some
> of his decisions and disagreed with others.  Probably the same

Actually, Eliot, Jon had great powers of persuasion and
influence based on technical skill, knowledge, accomplishments,
and contributions.  He has little formal authority wrt the
standards process, and a huge amount of sense about not trying
to intervene in areas where he lacked knowledge and competence.
And I never saw any symptoms of, e.g., "because I am the
occupant of the RFC Editor chair I have certain 'rights'".
>From where I sit, that is a effective and appropriate style of
leadership in an organization like the IETF.  

In this context, my precise objection to what is going on now
rests on a comparison with that style of leadership.  Jon's
style involved persuasion, logic, facts, and trying to
understand the point of view of those with whom he disagreed.
Like you, I disagreed with some of his positions and decisions,
and I found him quite stubborn when he thought he was right (not
always a bad trait), but I could almost always end up
understanding his point of view.  By contrast, we are now seeing
a different style of position-taking and decision-making, one
that terrifies me.  The new style involves assertions of the
"rights" of the people who occupy IESG and IAB seats (because
they are in those seats) instead of explanation and openness
with the community about details and options, and involves
(virtually) shouting "wrong" instead of engaging in discussion
and persuasion.

The comparison to W3C is really not fair, because they are
organized along different principles.  But, at the beginning,
Tim could unilaterally either establish a recommendation or kill
a proposal, could do so without giving an explanation, and was
_expected_ to exercise the design judgment that implied.  That
is very different from the way the IETF has traditionally worked.

> But you missed my point.  Don't like the IETF or the W3C?  Try
> the TMF or the DMTF or the ITU or the GGF or the IEEE or roll
> your own (everyone else has ;-).

Sigh.  Some of us have dedicated a rather large portion of our
lives over the last decade or so to both trying to get some
technical work done in the IETF and to keeping it productive in
terms of producing high-quality, timely, well-documented,
standards.  Some of us are even deluded enough to believe that
the process problems we see today are aberrations that can be
corrected by explaining the problems and their implications to
both the community and the leadership and calling for a
different way to do things (or a return to most of the old way).
Even though it increasingly feels like a losing battle and a
waste of energy to try, I'd much rather see those who believe in
leadership by either royal authority or strength of personality,
in voting, and in membership structures go somewhere else.  And
I have the odd delusion that a fairly significant fraction of
those who do the technical work around here prefer openness and
consensus processes around here to having their comments
dismissed with "WRONG".

You have made contributions around here.  If someone disagrees
with you, would you prefer an exploration of the differences in
perspectives or an assertion of "rights" and then being told
"WRONG"?

    john

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 04 Oct 2004 14:54:37 -0700

John,

> (virtually) shouting "wrong" instead of engaging in discussion

Perhaps the IETF traditional motto, "rough consensus and working
code" should be revised to make it clear that the "rough consensus"
goes only up to a certain point, but after that point the IETF
operates solely by a decree from the IESG.

Yakov.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 4 Oct 2004 21:10:08 -0700

>   However, I don't see delay
>  wait a LONG time for community consensus.  

1. Nothing about the reorganization is going to make IETF 
standards be more useful or be produced significantly more 
quickly.  Hence, reorganization has nothing to do with the really 
serious threats to IETF long-term survival.

2. The current sense of crisis has mostly come from a loss of 
revenue.  Nothing about the reorganization will necessarily fix 
that.

3. The rest of the sense of crisis is due to interaction problems 
between some people in IETF leadership and some people in the 
organizations that the IETF uses for services.  Nothing in the 
reorganization is certain to improve any of that, especially 
since we do not have precise statements of work for them.  (There 
is a rather mystical sense that the reorganization will fix these 
issues, but in fact nothing in the simplistic, superficial way 
that we are proceeding should give us any sense that that 
improvement is likely.  Quite the opposite.)

4. Most of the reorganization process has been pursued with 
partial statements, incomplete plans, and assertions of urgency. 
It certainly has not been conducted in a way that attended to 
concerns as they were raised.  Quite the opposite. 

So the view that "delay" will not assist us amounts to a 
statement that we should not worry about the considerable range 
of serious problems in how we have been pursuing organization, or 
with our community ignorance about what we are doing, but we 
should charge ahead (blindly) just to get it over with.

I am trying to imagine any sort of serious protocol development 
process that used that sort of logic and then had acceptance 
and/or success.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker@...
brandenburg.com

---

From: "Eric S. Raymond" <[email-masked]>
Date: Tue, 5 Oct 2004 00:57:22 -0400

> serious threats to IETF long-term survival.

Indeed it does not.  I've been lurking on this list for a couple of
months now, and I am fighting an increasing feeling that I am watching
deck chairs being rearranged on the Titanic.

In the last 60 days, the IETF has taken the worst blow to its
credibility that I have observed in the entire history of the
organization.  I refer, of course, to the Sender-ID debacle, which
exposed IETF's inability or unwillingness to defend Internet 
standards against patent predation even when the existence of 
prior art is readily establishable.

Here is what I had to say to Yakov Shafranovich on 7 September:

------------------------------------------------------------------------
I believe the IETF's stated policy of passivity in the face of IPR
power grabs damages the IETF first and foremost.  The whole point of
having standards organizations is that they coordinate multiple
competing interests to create a neutral commons that grows a market
faster.  No standards organization can long remain relevant if the net
effect of its activities is not to do this but rather to rubber-stamp
proprietary control, creating monopolies in slower-growing 
markets rather than commons in faster-growing ones.

In times past, simply ignoring the more outrageous claims may have
been enough of a response.  I don't think it is today.  Conditions
have changed.  Post-DMCA and with the USPTO interpreting the scope of
patents ever more liberally, IPR law has more teeth than it used to
and the perceived risk attached to ignoring IPR claims has escalated.

Accordingly, any standards organization that wants to keep itself
relevant (e.g., useful to multiple competing interests) can no longer
merely describe a commons and piously hope nobody will fence off too big a
chunk. It has to assert and actively defend that commons, signaling
that no raids will be permitted there.

Note that nothing in the previous two paragraphs is open-source
ideology in any sense, just a straightforward discussion of signaling
behavior in markets.  I think you'd be hard put to find any economist
that would disagree with it.  The problems it raises are not unique
to IETF; other technical-standards organizations such as W3C, NIST,
and ISO are grappling with them as well.

I consider the IETF part of the open-source community.  While I
certainly would not object if the rest of the open-source community's
agenda were to affect IETF policy, I think the most pressing reasons
for IETF to act are the effect of surrendering to IPR power grabs on
the IETF's own viability.

Accordingly, the question I think you should be asking is: can the
IETF long survive a policy of simply ignoring IPR claims in the hopes
they'll go away?

You'll have to judge for yourself, but I think the answer is "no".

As for the rest of the open-source community's position, I think that
has been made very clear by the open letters from ASF, Debian and
elsewhere.  If IETF is not prepared to actively assert and defend a
commons, then we have no choice but to write off the IETF as part of
the problem rather than part of the solution and do the IETF's
signaling job ourselves.  

Those responses were all about "no raids will be permitted here".
That is what they *mean*, and IETF's authority took a bad hit from the
fact that they had to be issued at all.  I think it would be in
everyone's interest for the IETF's standing not to be further eroded,
and I think the authors of the open letters would agree.  But for that
good result to obtain, the IETF has got to get off its butt and take
back the job of defending the commons.  The *whole* job, including 
rejecting RAND terms and proprietary licensing.
------------------------------------------------------------------------

A month later, my assessment of the political damage the Sender-ID
mess has done to IETF has only gone up.  You are on a fast road to
irrelevance, gentlemen.  You'd best be thinking about how to change
*that* rather than conducting meaningless exercises in rearranging
your bureaucracy.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Oct 2004 08:20:35 +0200

Hi Dave,

> process that used that sort of logic and then had acceptance 

Here-in lies the rub.  If you try to use our rules of protocol 
development to develop an organization we'll never get there.  And you 
and I agree that there are bigger fish to fry, and right now the kitchen 
is backing up.

No, I'm not going to pick apart the rest of your message.  I disagree 
with some of your points but aside from one point to John and perhaps a 
response to Mr. Raymond, I've had my say.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Oct 2004 08:56:16 +0200

Eric,

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.  There is a fine balance to be had between the two 
extremes.  We are only part of the open source community if what you 
mean is that participation is open to all, and our documents are freely 
available to all.  Keep this in mind: the vast majority of participants 
in the IETF are funded by their employers to attend, and MOST of the 
resulting code is NOT open source.

The history of complex standards is that it takes time to get them done 
correctly.  Take a look at MIME, one of the standards that you used in 
the construction of your email message.  That effort was the outcome of 
a huge debate that started in 1990 and didn't get out the door until 
1992, and that was an argument amongst a relatively small group of 
people.  So just because MARID didn't finish doesn't mean the IETF is 
done with spam.

Eliot

---

From: "Eric S. Raymond" <[email-masked]>
Date: Tue, 5 Oct 2004 04:06:18 -0400

Eliot Lear <[email-masked]>:
> intended safe use. 

You'll talk yourself right into the dustbin of history with that line.
I think that would be very sad, considering the IETF's contributions
in times past.  But it's where IETF seems to be headed now.

Reality check: Apache has 68% market share.  Open-source MTAs handle 85% of
all email traffic.  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 ground under software standards organizations has been shifting;
significant parts of the commons-creation function that once belonged
to it have moved to open-source project groups like the ASF or xiph.org.
Nowadays, what the Linux kernel hackers do matters a hell of a lot
more to Unix standardization than anything the Austin Group emits.  A
big issue, in this kind of environment, is what traditional standards
organizations have to do and be in order to retain any utility at all.

Certainly it isn't the IETF's job to "rid the world of patent-laden
work".  But you'd better believe that it *is* the IETF's job to ensure
that Internet standards are an open commons, implementable by anyone
without fear they'll be raped and pillaged by hordes of attack
lawyers.  If you don't embrace that mission, you're soon going
to find you have no mission left that some outfit like ASF or 
xiph.org or W3C isn't doing better.

You've had two direct warnings about this -- the ASF and Debian open
letters.  They interpreted IETF's passivity on the Sender-ID patent
issue as damage and routed around it.  If the IETF doesn't get its act
together, that *will* happen again.  The open-source community and its
allies will have no choice but to increasingly route around IETF, and
IETF will become increasingly irrelevant.

I do not want to see this happen.  You shouldn't either.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 05 Oct 2004 10:52:50 +0200

Eric,

the MARID WG was shut down because it was unable to reach consensus.

That is, indeed, a failure of the IETF. But not the one you argue.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 05 Oct 2004 11:25:56 +0200

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.

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.

But that's not what keeps me awake nights *this* week....

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 5 Oct 2004 07:42:59 -0600 (MDT)

> From: Harald Tveit Alvestrand 

> That is, indeed, a failure of the IETF. But not the one you argue.

On the contrary, recognizing the hopeless lack of consensus and
refusing to continue dancing to the tune of various interests was
an outstanding success of the IETF.

The failure by the MARID WG to reach consensus can be viewed as a
failure or a success.  Neither the IETF nor any other voluntary standards
organization can force standards on the world, as the ISO and governments
demonstrated with the OSI protocols.  When consensus cannot be reached,
it is wrong to continue, as the ISO also demonstrated with the OSI
protocols.  One of the worst things that committees (not just standards
committees) can do in such binds is to produce kitchen sink non-designs.
The essence of designing consists of making choices, and that consists
of saying "yes" to one or maybe few things and "no" to almost everything.
When consensus is impossible for making choices, the right response
is to stop spinning.

As has long been true, a bigger danger to the IETF than patents are
the special interests that try to use the IETF for ends unrelated
to ensuring the interoperability of network protocols.  The baloney
started by some SPF advocates and widely repeated by others about
the reasons the MARID WG was shut down are more harmful to the IETF
than embrace-extend-and-patent games, even if such games were in
play, which is not at clear.

Vernon Schryver    [email-masked]

---

From: "Eric S. Raymond" <[email-masked]>
Date: Tue, 5 Oct 2004 10:35:35 -0400

> patents that crop up in the commons harmless.

And what ways would those be?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Oct 2004 09:33:31 -0700

Eliot,

> >  I am trying to imagine any sort of serious protocol
> >  development process that used that sort of logic and then
> >  had acceptance and/or success.
>  Here-in lies the rub.  If you try to use our rules of
>  protocol development to develop an organization we'll never
>  get there.  And you and I agree that there are bigger fish to
>  fry, and right now the kitchen is backing up.

My point was that the level of naivete and irrationality that 
underlie this reorganization process would never be tolerated in 
any serious design effort for specifications.

So I was not talking about "rules".  

I was talking about being deliberate, constructive risk-averse.

We are being none of those.

d/

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 5 Oct 2004 18:53:03 +0200

On Tue, Oct 05, 2004 at 04:06:18AM -0400, Eric S. Raymond wrote:
> 
> When Meng Weng Wong was thinking about how to

The IETF is a problem, but not the worst one. 

The worst thing in that dirty game was that some were
"evangelizing" and "lobbying hard". 

Wasn't it you who partizipated in the SPF marketing show at 
MIT? Wasn't it you who blamed me for not doing proper marketing?

Security is about engineering, but not evangelizing, lobbying, or
marketing. 

This is what poisoned the whole process, and the IETF is who allowed 
the process to be poisoned. 

While I agree that the IETF made awful mistakes and spoiled MARID, 
I do consider your critics as malicious, because it is exactly
that what you praise what finally caused all that trouble. 

Without SPF and Meng's personality show and all that marketing, 
evangelizing and lobbying, IETF could have finished the work
and defined an RFC about half a year ago, before M$ could have 
applied for a patent. And FYI, Meng did not go straigt to the 
open-source MTA developers. He went to the evil cathedral, not 
to the bazaar. Don't tell tales here. 

You'd better not persuaded him.

Hadmut

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Oct 2004 11:12:13 -0700

In this message, I am speaking as the Area Advisor who was responsible
for MARID.

The reasons for closing the MARID working group are set out
in http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html.
Fundamentally, the working group chairs and I believed that the group
was very unlikely to reach consensus, as it kept re-spinning old arguments.

To boil this very far down, one group felt that it was vitally important that
any anti-forgery additions to email be in some way connected to what a
user sees (i.e., the RFC 2822 headers); others did not agree that this was
necessary or felt strongly that any changes must be made to the RFC 2821
exchange, as this allowed dispositions to be determined without accepting
the DATA.  Attempts to reach consensus on one or the other other of these
positions failed, and attempts to create an infrastructure that would 
allow for both
also did not show much promise of consensus.

The presence of an IPR declaration and license offer related to the 
RFC 2822-based
mechanism muddied the waters, as those who were not in favor of that
approach argued that it implied the group must select the other.  Those who
believed that the RFC 2822-based approach was the best mechanism focused
instead on the viability of the patent application or on the 
acceptability of the
license terms (which, to be fair, seem to have been copied from license terms
that the IETF has found acceptable in other contexts). Despite the efforts of
the chairs, that the two mechanisms  related to very different identities was
largely elided in this discussion, as the group  got bogged down on details of
law that were outside the expertise of all but a  very tiny number of 
participants.

I saw this lack of coherent discussion of the IPR matter as a symptom of the
larger disagreement, not as caused by it.  Were there a very strong consensus
on the right approach, an IPR declaration related to that approach would have
been met with strategies to avoid or accommodate the IPR and offered license.
That it is was met instead with an argument over the abandonment of the
fundamental approach speaks strongly to the consensus of the group on
the work.  It was one symptom, though, among many.  It was not
the cause of the working group's closure.
			regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 5 Oct 2004 12:54:00 -0700

In this message, I am speaking as an individual participant in the IETF.

For those following the discussion over the past few months, it must
be pretty obvious that I believe that the IETF's role in the world is
distinct from that of the Internet Society, and that I believe that
policy concerns are best addressed by ISOC.  Because ISOC's role
in the standards process is at one remove, it can work to educate
legislatures and administrations without appearing to favor one participant
over the other.  It could take a stand like "public policy is ill-served
by blanket grants of patents whose real validity must be determined
by courts".    Working to establish that as a policy statement of ISOC could be
done by discussion in ISOC chapters, by discussion among the members of
ISOC (both organizational and individual), and by discussion with ISOC's board.
I have no doubt that if ISOC were to take on that particular public policy
view, it would draw on individuals who are familiar from IETF contexts to
bolster its case and provide its examples. But it would do so to make 
statements
in an ISOC context, not in the IETF's.

As it stands now, governments use patents to grant monopolies.  That is
a fact of life.  The IETF's goal has long been to write specifications that
the community building and operating the Internet can use.  If the terms of a
specific monopoly mean that the community absolutely cannot use a particular
specification, the IETF must find means to write a different 
specification that the
community can use.  Usually, this means changing the specification so
that the granted monopoly is not in effect.  It may also decide that the
terms related to a specific monopoly do not affect the ability of the 
community to
use the specification, either because the terms are so easy that they
imply no cost or because the need is so great that the cost will have
to accepted.  To reach that decision, it may ask the holder of the monopoly
to give specific terms.   In all of these cases, though, the decision 
is made in
the context of the engineering choices in the specification, not as an abstract
decision which must be applied at all times and in all places.  That
could change, if the IETF decided the effort to determine this on a
case by case basis was too great, but it has not done so to date.

You will notice that the choices above did not include "the IETF can fight
a specific monopoly grant".  I don't think we as a corporate body can in
the common case, though individuals familiar from IETF contexts can and do.
There are several reasons for this, some practical (we don't have the money)
and some organizational (we don't have the right participant mix).
There is also the simple fact that the grant of a patent will have implications
beyond our standards, and so there are elements of the fight which
are literally not our business (note that asking for licensing terms may also
have implications beyond our standards, so there is a gray area here).

Most importantly, though, choosing to fight a patent will be understood
as the IETF judging its participants' external actions.  In any 
organization which
relies on volunteer participation, that has to be taken as a very serious,
very last step.  Disallowing specific participants or acting against 
their interests
based on their articles of faith or their current employer is a strike against
open participation in the IETF's work.   That open participation is, in my
opinion, absolutely critical to the IETF's success.

There are many times in which the IETF process is frustrating for its
participants, because the effort to reach consensus can be extraordinarily
hard.  That it works at all when participants may be from competing
companies or competing camps is a strong statement that its participants
recognize that building a common infrastructure is a common good.
There have been occasions when one set of participants believes another
set are not acting to achieve that common good.  In my opinion,
the best way to handle those situations is by an even-handed application
of the normal rules. If done right, that trains all the participants how to
work together in the IETF context, retaining participants who might
otherwise simply go away.  That may seem frustrating to those who can
imagine how much easier a particular decision would be if only one
or more participants would leave.  But that is short-term thinking;
unlike the usual open source community, our focus on  core  infrastructure
means  that we don't have the same options when we  are thrown together
with those with whom we disagree.  The Internet cannot fork.

We, for a very broad value of we, must work together as best we can.

Again, speaking only for myself,
				regards,
					Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Oct 2004 15:28:42 -0700

>  ... I believe that policy concerns are best addressed by
>  ISOC.  Because ISOC's role in the standards process is at one
>  remove, it can work to educate legislatures and
>  administrations without appearing to favor one participant
>  over the other.  

That sounds wonderful, except that ISOC has no significant 
experience in that work and that work requires skill and 
experience.

As has been commented to me repeatedly in recent months, when 
someone in government wants to obtain advice about the Internet 
and about Internet policy, they do not regularly consult ISOC.  
ISOC does not regularly testify in Congress.

And so on.

More generally, as folks postulate spiffy functions for ISOC, it 
might be worth asking where ISOC's expertise for that function 
has been demonstrated.  

That includes minor items like operational administration of a 
standards body.

d/

---

From: Scott W Brim <[email-masked]>
Date: Wed, 6 Oct 2004 00:12:27 -0400

As Ted says, the IETF should stay out of passing judgment on the
validity of claims and/or fighting patents.  It's really way outside of
our charter.  Anyone can set up a separate organization to do that if
he/she wants.

However, this case is just the worst of many.  It is abundantly clear
that the IETF's current approach of treating each IPR claim on a
case-by-case, ad hoc basis is really hurting us.  I've been involved in
IETF IPR issues for a while and time after time I see Working Groups get
totally stuck trying to evaluate the impact of a particular patent claim
(and then sometimes another, and another ...).

At this point we need more than guidelines.  Our productivity is
suffering because they just aren't effective enough, soon enough.  We
would benefit greatly from something deterministic, IETF-wide.  

Eliminating IPR altogether will be difficult at best, probably
impossible, and I don't think trying to do so is worth our time.
However, there appears to be rough consensus emerging that an IPR
assertion is acceptable if any of the following are true:
  
  - a license is explicitly not required.

  - a license is explicitly free with no restrictions.

  - a license is explicitly free with rights of "defensive suspension"
      (what Harald calls "no first use").

I know of a couple cases where any "encumbrance" at all was considered
unacceptable, but the great majority have found one of these acceptable.

If an IPR assertion falls into any of these categories, then Working
Groups no longer need to consider it as an issue, and no longer should.
They can actually make progress.  What an idea -- to have a general rule
worked out in advance by which you can deal with an IPR issue in one or
two minutes, and then go on.

So that's a proposal: If a claim falls into one of those three
categories it is acceptable, and WGs shouldn't consider it as an issue.  

Let's get some time at the Washington meeting to talk about this.

swb

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 6 Oct 2004 00:28:56 -0400

>       (what Harald calls "no first use").

This is very close to W3C's policy.  OSI could get probably get behind it,
though the details of "no first use" would have to be carefully specified.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Oct 2004 09:59:53 +0200

>       (what Harald calls "no first use").

This makes a lot of sense in cases where a patent is legit (for lack of 
a better word). However, the reason we're in such a big mess is that 
more and more companies are registering patents of questionable merit. 
This brings us right back to:

> our charter.

I gather that the US patent office pretty much rubber stamps patent 
applications in the IETF's area of interest because they don't know how 
to evaluate them. Maybe I'm being naive here, but it seems to me that 
some kind of clue transfer from the IETF to the US patent office would 
be beneficial to all except the patent lawyers who would then have to 
start to do actual work to make a living.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 06 Oct 2004 12:39:11 +0200

At 09:59 06/10/2004, Iljitsch van Beijnum wrote:
>applications in the IETF's area of interest because they don't know how to 
>evaluate them. Maybe I'm being naive here, but it seems to me that some 
>kind of clue transfer from the IETF to the US patent office would be 
>beneficial to all except the patent lawyers who would then have to start 
>to do actual work to make a living.

All of this is pretty much the same as for Domain Name IP. The "US nexus" 
of the IETF is obviously the problem (cf. RFC  3774 diagnosis). Because 4% 
of the world population has a problem with the demeanor of  the USPTO (the 
same as 4% of the world population had a problem with the ACPA (anti 
cybersquatting act) unexpected effects. In the domain name area the 
solution came from the WIPO . The solution for IETF Standards protection 
can only come from them too. For DNs the solution was that TLDs could not 
be registered as common humanity goods and that conflicts should use $200 
arbitration first (UDRP) instead of $ millons actions. For IETF the only 
solution is to declare internet standards common humanity goods (the same 
as languages: nobody has (yet?) patented English or language) and to set-up 
an appropriate low cost conflict management procedure to acknowledge the 
rights of the real inventors.

However, in the DN area, ICANN tried to be international and level with 
Govs and ITU, dialoguing with them.Making them aware of the problem. IETF 
is not. Today UN has a mission given by 190 Chief of States to clarify the 
Internet Governance issues. The first issue for them is to define what the 
Internet may be. Then what is Governance. And then what is the Internet 
Governance. IETF has its basic definition of the Internet (upper "I"): the 
adherence to its Internet documents. Mr. Kummer (the head of the UN 
mission, directly reporting to the General Secretary) is not repeated that 
(so he cannot list what canbe missing in these documents). Governance means 
independence first (this is why the form of governance of the Internet can 
only be an intergovernance and not an US nexus dominance), Mr. Kummer is 
not explained and technically documented that. Internet Governance 
therefore means that IETF documents MUST be independent from any influence 
(and patents). Mr. Kummer MUST be hammered that need. But all this work 
MUST address users real needs, so innovation MUST be fostered:  this is the 
whole problem of the aging Internet system: people must be able to come 
with ideas and to get recognition - not "wrong" barking or to be stolen by 
a big US Corporation patent. And this is something we MUST discuss with Mr. 
Kummer, and other SDOs.

If we do not do it, nobody will do it because politicians have been burnt 
and think "this is technical, this is not our cup of tea". The same they 
said before "the Internet is the cup of tea of ICANN", until Stuart Lynn 
wrote them, calling for help and telling them his problems. IETF is not in 
the business of ruling the world (RFC 1531).

If we continue keeping this internal and not making the world aware (all 
the more than they want to know) the result will be an Internet 
balkanisation because people will develop US nexus/patent free solutions - 
like the Chinese IPv9 political testing. The IETF problem is not its 
incorporation (young entrepreneurs always come with the "incorporation 
first" mistake - incorporation is the last detail). The IETF problem is 
voluntaries motivating deliveries.  If the deliveries are not motivating 
its members, there is no more IETF and the debate has ended.

To be motivating, the IETF deliveries must match today's world challenges, 
not 1980. They must be common humanity goods, not ways for some cute lawyer 
to use voluntary propositions to register blocking patents. They must get a 
proper level of recognition for their authors. That recognition must also 
serve to attract sponsors and address the IETF budgetary problems. If this 
is achieved the adminstrative solution to port it will then be obvious. 
Otherwise why to waste time with IETF?

jfc

NB. As I copy this mail to non-IETF members here are some additional 
information:

http://ietf.org/rfc/rfc3774.txt?number=3774
This RFC describes the internal mood and problems of the IETF
http://ietf.org/rfc/rfc3716.txt?number=3716
This RFC describes the relations with its direct contributors
http://www.ietf.org/internet-drafts/draft-lyons-proposed-changes-statement-00.txt
This draft proposes an administrative response but is interesting in giving 
historical and cultural information.

To my knowledge no similar evaluation has been carried on the relations of 
IETF with its publics (users, operators, Governments, other SDOs) nor on 
its deliverables and their adequation to the market, societal and 
governmental demands.

IRT "intergovernance", I consider the interest of a draft on this key 
matter. This would be a major task and a big workload which makes me 
hesitate. Also it necessarily involves the four governance poles 
(technical, societal, economical and political) and spanns across most of 
the world ecosystems, while there is no ad-hoc structure to help dialoging 
on the issue. To start analyzing the problem I prepared a questionnaire and 
a mailing list (http://intergovernance.org/quest.htm) a few have already 
started responding. This was a quick work a few months ago. Comments and 
suggestions are welcome.

---

From: Scott W Brim <[email-masked]>
Date: Wed, 6 Oct 2004 07:54:28 -0400

On Wed, Oct 06, 2004 09:59:53AM +0200, Iljitsch van Beijnum allegedly wrote:
> a better word). 

Great.

> However, the reason we're in such a big mess is that more and more
> companies are registering patents of questionable merit. 

Even if an IPR claim is "illegitimate", explicit free licensing lowers
the risk to the point where you can separate the questions of technical
merit and legitimacy, and hand off dealing with legitimacy.  

> start to do actual work to make a living.

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.

swb

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Oct 2004 14:50:08 +0200

On 6-okt-04, at 13:54, Scott W Brim wrote:

>> Maybe I'm being naive here, but it seems to me that

> organization.  Let the IETF have a clear focus.

It's probably a good idea to keep the patent politics out of the IETF, 
but if technical information flowing from the IETF to the US patent 
office can reduce certain harmful effects to the IETF process, then it 
would be a bad idea to forego this because the focus may get unclear. 
I'm also unsure where the necessary level of competence can be found 
outside the IETF.

It seems to me that simply uploading all drafts into the prior art 
database wouldn't be a bad idea. (We now upgrade the DoS to DDoS.) And 
if that's unfeasible, keeping those drafts around so that people who 
are looking for prior art outside the patent databases can find them 
would be a good start. (It could be argued that RFCs are the relevant 
documents here, but since drafts exist long before RFCs of the same 
content, drafts are better in this regard.)

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 6 Oct 2004 10:24:05 -0400

Simon Josefsson <[email-masked]>:
> I wouldn't go as far as saying IETF is part of the open-source
> community.

Well, it is in at least the historical sense -- that is, of having
provided an important model for decentralized cooperation that shaped
the open-source tradition.  Fred Baker, representing IETF at the 1998
summit conference where the term "open source" was adopted, expressed
no doubt that IETF belonged in the community we were declaring.

The fact that most implementations of IETF standards are closed-source
is not a disqualifier.  It is sufficient that almost all IETF
standards *can* be implemented in open source -- that, except for
the serious policy defect near patents, the IETF process comes
close to guaranteeing this.

>        However, I do believe that if IETF no longer provide a
> service to the open-source community, IETF will have lost its power in
> shepherding protocol standardization.

Agreed.  And I see this as a problem -- I value the IETF's institutional
knowledge quite highly, and thus do not want it to lose that power.

(Historical note: Yes, I have been an active IETF participant, notably in
the development of the RFC2822 standard.)

I'm mulling over some points for an essay in which I will discuss in
depth the impact of open source on standards organizations.  If and
when I write it, I will post a pointer here.

> The copying condition issue haven't yet reached critical mass, but
> from what I can tell, it is getting closer and closer.

This problem has a solution that should be both technically and
politically easy.  The IETF should adopt the appropriate variant of
the Creative Commons license (permitting derivative works but
requiring attribution) for RFCs.

This change would have at least three good effects:

1. It would eliminate the technical problem with derivative works
   which you have pointed out.

2. It would harmonize IETF's practice with open-source community norms.

3. It would relieve IETF of the burden of maintaining its own legal
   language to solve this problem.  The CC folks are specialists in
   the relevant legal issues and can do a better job.

Since this change would remove restrictions from use of the RFCs rather
than adding them, it probably does not require a plenary session but could
be put through as an adninistrative change by the RFC editor,

Is the RFC editor listening?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 6 Oct 2004 10:02:00 -0700

Hi -

> From: "Scott W Brim" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, October 06, 2004 4:54 AM
> Subject: Re: Shuffle those deck chairs!
...
> 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?

Randy

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Oct 2004 13:02:45 -0700

On Tue, 5 Oct 2004 11:12:13 -0700, Ted Hardie wrote:
>  Fundamentally, the working group chairs and I believed that
>  the group was very unlikely to reach consensus, as it kept re-
>  spinning old arguments.

Since Ted (perhaps unwittingly) explicitly copied me, I thought 
it worth registering my own assessment of the Marid experience:  
     
     It is the same as Ted's.

d/

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Oct 2004 15:32:18 +0200

First, thanks for your two well written posts.  They were the first in
this thread that reflect views that I share.  Over the past week, I've
read both the "O" and "C" proposals, and it seems to me they both fail
to properly address the problems you bring up.  Consequently, in the
straw poll, I didn't feel convinced enough to vote for either
proposal.  At best, they both just miss the point.

I wouldn't go as far as saying IETF is part of the open-source
community.  However, I do believe that if IETF no longer provide a
service to the open-source community, IETF will have lost its power in
shepherding protocol standardization.  I just wanted to share a data
point to support your argument:

> IETF will become increasingly irrelevant.

Another growing concern in the community is the license used for IETF
documents.  The newly adopted copying conditions for RFCs [1] further
restrict borrowing of text from RFCs into free software products.  If
that trend continue, or the current rules are enforced to the letter,
free software products will write their own protocol specifications.
They would do so to be able to incorporate derivative works into the
documentation.  IETF could rubber stamp those documents, and publish
them as RFCs, but then it would have lost control over the process.

Thanks,
Simon

[1] Compare <http://www.rfc-editor.org/copyright.html> with the real
text in RFC 3667, especially section 7.3.  To me, they leave a
significantly different impression.  The web page imply derivative
works can be permitted, but according to RFC 3667, the only
organization permitted to produce such derivative works would be
ISOC/IETF.

---

From: [email-masked] (scott bradner)
Date: Wed, 6 Oct 2004 17:01:54 -0400 (EDT)

> but according to RFC 3667, the only

this is the way that its been since rfc 2026

note that an rfc can be copied in full with no problems
and that an author can give permission to produce derivative works

its just that the IETF only requests limited rights when
receiving a document from an author (the right to publich and the
right to produce derivative works within the IETF) all other
rights remain with the author(s)

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Oct 2004 23:20:36 +0200

> this is the way that its been since rfc 2026

The 2026 copyright notice include:

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain
   it or assist in its implmentation may be prepared, copied,
   published and distributed, in whole or in part, without restriction
   of any kind, provided that the above copyright notice and this
   paragraph are included on all such copies and derivative works.

That text allow me to copy parts of an RFC into my own document or
implementation.  I see nothing in RFC 3667 that grants me similar
rights.  What am I missing?

Thanks,
Simon

---

From: [email-masked] (scott bradner)
Date: Wed, 6 Oct 2004 17:33:44 -0400 (EDT)

the text you quoted says 
> derivative works that comment on or otherwise explain

note that it is restricted to "derivative works that comment on or 
otherwise explain it or assist in its implmentation"  it is not open
ended permission to copy or make derivative works

RFC 2026 sec 10.3.1 (1) says that the right to produce derivative works
is granted to the IETF(ISOC) it is not generally granted

i.e. the rights under 3667 are the same as under 2026 its just stated
more clearly

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 06 Oct 2004 23:52:15 +0200

> ended permission to copy or make derivative works

I would call a manual, that include portions of a RFC, a derivative
work that "comment on" and "otherwise explain it".

> is granted to the IETF(ISOC) it is not generally granted

Fortunately, the copyright boiler plate in old RFCs are self
contained, and does not reference RFC 2026.

> i.e. the rights under 3667 are the same as under 2026 its just stated

Even if that is true, it would not change that the current copying
conditions are a problem for the free software community, and in my
opinion, consequently the IETF.

Thanks.

PS.  I can add that the Unicode Consortium did open up their copying
conditions, after lobbying from the free software community.  Kudos to
them!

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 07 Oct 2004 07:49:44 +0200

> opinion, consequently the IETF.

this was something I did not see clearly raised in the IPR WG, which is a 
pity.

Since changing to a more liberal license would require changing the grant 
of rights that the authors give to the IETF (or to ISOC), we can't just 
change it retroactively either (see debate on retaining I-Ds for more than 
6 months for what happens if we try).

Anyway, this belongs on the IPR WG's mailing list.

                  Harald

PS - I just had another instance of this problem.... someone wanted to copy 
term definitions from an IETF glossary into their own glossary of terms 
(with attribution). I think this should be allowed and encouraged - but 
under the IETF copyright terms, the person had to ask the author for 
permission; the IETF was not in a position to grant the request......

---

From: Eliot Lear <[email-masked]>
Date: Thu, 07 Oct 2004 09:20:47 +0200

Simon,

What is your goal, here?  What is it you want to do that you can't do 
because of either RFC 3667 or RFC 2026?

Eliot

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Oct 2004 10:51:51 +0200

Eliot,

a few examples:

For IDN, I want to be able to extract the tables from RFC 3454 and use
them in my implementation.

For Kerberos, I want to be able to use the ASN.1 schema in my
implementation, and copy the terminology section into my manual.

For SASL, I want to incorporate portions of the introduction section
from the RFC into my manual, to make sure some terminology is
explained correctly.

For GSS-API, I want to be able to copy the C header file with function
prototypes into my implementation.

I believe the copying conditions in RFC 2026 give me these rights, but
I have not yet seen anything similar in RFC 3667.  I am still looking,
though.

If I'm wrong, and not even RFC 2026 gave me these rights, the
situation is even worse than I would have thought.

Thanks,
Simon

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2004 11:31:43 +0200

=> I can't understand why the copyright about a text is a problem
for software when the documentation is explicitely "without
restriction of any kind". Perhaps we don't share the meaning
of "derivative works" (for me, this can't be code itself)?

Regards

[email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Oct 2004 11:42:01 +0200

Francis Dupont <[email-masked]> writes:

> restriction of any kind".

Where does it say this?  Note that the quote I sent earlier was the
old RFC 2026 copying condition, which I agree with you is OK.  The new
text is in RFC 3667, which seem murkier to me.  I cannot find "without
restriction" in it, for example.

However, Scott Bradner suggested that the old RFC 2026 text may not be
permissive enough to allow for derivative works.  I have asked lawyers
to look at this now, to be certain.

> Perhaps we don't share the meaning of "derivative works" (for me,
> this can't be code itself)?

If you extract, say, a C header file, or an ASN.1 schema, from an RFC
into an application, I believe that may be regard as a "derivative
work".

Thanks,
Simon

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2004 12:30:47 +0200

Eliot,
   
   a few examples:

   

   
=> I understand better your concern: the problem is about pieces of
code which can be extracted from an RFC, the cannonical example is
a MIB. This is covered in RFC 3667 by 5.2, 5.6 and 7.1e which I
give here:

   e. the right to let third parties extract some logical parts, for
      example MIB modules

So at least your concern was not forgotten...

Regards

PS: as a researcher and an old BSD fan I have no concern at all with
the "please reproduce the copyright for authors' recognition" style (:-).

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Oct 2004 13:05:11 +0200

> So at least your concern was not forgotten...

I am sorry to continue this, but I think it is valuable to have a
complete discussion in public on record of this.  Especially since
Harald imply IETF hasn't been aware of this before.

I still see two issues:

1) The above does not grant me the right to incorporate text into,
   e.g., my manual.  It seems to me that this should be encouraged and
   promoted.

2) I cannot find anything about "third parties" in the actual license
   text, in section 3.3.  The (E) clause grant the ISOC/IETF the right
   to extract, etc code fragments, but doesn't say anything about
   third parties.  Your quote suggest the intention was to address my
   concern, but to my reading, the intention isn't addressed in the
   more legally phrased rights grant.  Naturally, I may have
   completely missed it, though.

I don't believe this issue is off topic.  I agree with Eric Raymond
that IETF must make an effort to ensure that the standards can be
openly implemented without risking legal consequences.  Copying
conditions is a minor tangent to those larger IPR issues, but if it
cannot be resolved, I see little hope in resolving larger problems.  I
do agree that fleshing out any details should be moved to the IPR WG.

Thanks.

---

From: [email-masked] (scott bradner)
Date: Thu, 7 Oct 2004 07:08:23 -0400 (EDT)

> into an application, I believe that may be regard as a "derivative

see RFC 3667 Section 3.3 (a) (E)

      (E)  to extract, copy, publish, display, distribute, modify and
           incorporate into other works, for any purpose (and not 
           limited to use within the IETF Standards Process) any
           executable code or code fragments that are included in any
           IETF Document (such as MIB and PIB modules), subject to the
           requirements of Section 5 (it also being understood that the
           licenses granted under this paragraph (E) shall not be deemed
           to grant any right under any patent, patent application or
           other similar intellectual property right disclosed by the
           Contributor under [IETF IPR]).

Scott

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 07 Oct 2004 13:12:33 +0200

> see RFC 3667 Section 3.3 (a) (E)

   a. To the extent that a Contribution or any portion thereof is
      protected by copyright and other rights of authorship, the
      Contributor, and each named co-Contributor, and the organization
      he or she represents or is sponsored by (if any) grant a
      perpetual, irrevocable, non-exclusive, royalty-free, world-wide
      right and license to the ISOC and the IETF under all intellectual

>            Contributor under [IETF IPR]).

As far as I can tell, those rights are only granted to the ISOC and
the IETF, not "third parties".

Thanks.

---

From: [email-masked] (scott bradner)
Date: Thu, 7 Oct 2004 07:30:24 -0400 (EDT)

there seems to be an assertion of evil intent here that is not the case

1/ the IETF requests the mininum rights from an author that it can get
   away with so that the author can have maximun flexability with
   the author's own text - see section 7.1

   The non-exclusive rights that the IETF needs are:

   a. the right to publish the document
   b. the right to let the document be freely reproduced in the formats
      that the IETF publishes it in
   c. the right to let third parties translate it into languages other
      than English
   d. except where explicitly excluded (see Section 5.2), the right to
      make derivative works within the IETF process.
   e. the right to let third parties extract some logical parts, for
      example MIB modules

   The authors retain all other rights, but cannot withdraw the above
   rights from the IETF/ISOC.

2/ part of what the IETF asks for is for the ability to create revised
   versions of the document (e.g. to create new versions of a standard)
   within the IETF process - the IETF is not interested in helping 3rd
   parties create new versions of IETF standards without the IETF's
  involvement (we do not think its a good thing for someone else to 
  create a revised version of TCP and then claim its the only truse
  version) - the author can authrize such a new version if the author
  wants to but there has to be a specific OK

3/ the IETF is quite interested in letting people create manuals
   etc - there is no intent to limit the ability for a 3rd party
   to reproduce RFCs or parts of RFCs in manuals 

I do not see any problem for the open source community unless that
community wants to create a new version of TCP and take parts of
existing IETF RFCs to include in its description of their revised TCP

Scott

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 07 Oct 2004 13:59:04 +0200

hmmmm.....

> the IETF, not "third parties".

Solely for the purpose of using the term in RFC 3667, the IETF is defined 
as:

   a. "IETF":  In the context of this document, the IETF includes all
      individuals who participate in meetings, working groups, mailing
      lists, functions and other activities which are organized or
      initiated by ISOC, the IESG or the IAB under the general
      designation of the Internet Engineering Task Force or IETF, but
      solely to the extent of such participation.

So this means that Simon Josefsson is allowed to exercise the rights Scott 
quoted and incorporate the executable pieces into running code, but the guy 
on the next desk, who isn't on any IETF mailing list, is not, even though 
they work on the same project, for the same employer, under the same laws.
If he joins an IETF list (any IETF list), he's allowed to.

I think we made things complex for the people who implement standards.

Sigh.

                        Harald

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 07 Oct 2004 16:12:13 +0200

At 13:59 07/10/2004, Harald Tveit Alvestrand wrote:
>quoted and incorporate the executable pieces into running code, but the 
>guy on the next desk, who isn't on any IETF mailing list, is not, even 
>though they work on the same project, for the same employer, under the 
>same laws. If he joins an IETF list (any IETF list), he's allowed to.

I wish we could read this this way. But I am embarassed by the "but 
_solely_ to the _extent_ of such _participation_". May not that mean that 
the third party must be on one of the IETF mailing list of the area of the 
matter he wants to quote, or that it must interact reasonably about it? Is 
a lurker having the same rights as a de facto co-author acting in a WG? 
Also, drafts are presented by WGs. Are the true authors the quoted authors 
or are the WG retaining parts of the rights? When a new concept is 
suggested by a WG member and aggregated to  someone's draft who is to give 
the authorization to quote it? This would also mean that subscribing to an 
open mailing list would modify legal rights, this registration should then 
be notarized in a way. Since many mail names can be used, there should be a 
IANA IETF Members list (there is a IANA Corporate list). When is a 
subscription ended - when I remove myself from the list or when I cease 
reading my mails?

In most of the cases there will not be any issue. But if someone starts 
objecting and suing someone else it will mean the case is worth it and 
lawyers will certainly discuss these points and many others. This would 
then have a brutal impact on the whole Internet standard process because 
unprepared.

For example, there is no IETF definition I am aware of for the term "domain 
name". There are many quotes of it in documents, contracts, legislations. 
Is someone claiming paternity of it, so I can ask him/her the permission to 
quote his description? I chose the term "domain name" on purpose because 
most of its use today in the world is now in relation to DNS. And many 
processes are carried which use the term in a different meaning than the 
RFCs. Would not the IETF's attitude about this key and core term make 
jurisprudence in case someone object for a less important term?

jfc

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2004 19:21:29 +0200

=> RFC 3667 style for copyright statements says nearly nothing about
the rights the ISOC grants to us... IMHO you're right and there is a real
issue even any restriction has to be written down to exist (the only
condition is to keep the original copyright).

   
=> RFC 3667 7.1e seems the right answer.

Thanks

---

From: [email-masked]
Date: Thu, 07 Oct 2004 14:00:49 -0400

> there seems to be an assertion of evil intent here that is not the case

The problem isn't one of current evil intent, the problem is that there's
a hole in the tent that an evilly-intented camel could get far more than just
its nose through.  And implementors are much happier when they live in
camel-proof tents....

> existing IETF RFCs to include in its description of their revised TCP

The threat model that is causing the issue is if $BIG_EVIL_CORP creates a
document that becomes an RFC, the open-source community implement it, and then
$BIG_EVIL_CORP sues them for copyright infringement.  And even if the open-source
side is in the right, the intimidation of the legal fees needed to mount a
defense is formidable.  Unless you can easily point and say "section 3.7(b)
obviously allows this usage of the text", you're in a grey area that's not a
good place to be in a litigious society...

Given the current sorry state of intellectual property in the US legal system,
I don't blame implementors who ask their lawyers to find which particular lines
in the boilerplate give *THEM* (as opposed to the IETF itself) a clear right to
use the text in the manner they need to.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2004 20:58:33 +0200

=> I support you:
 - as an employee of a school who could incorporate or paraphrase texts
   from IETF documents;
 - as a co-author of an RFC using the new copyright statement who could
   exercise my rights against a third party.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Oct 2004 21:15:26 +0200

=> the issue is this right is granted to the ISOC and the IETF, not
to third parties. In fact the whole RFC 3667 is about rights granted
by authors to the ISOC and the IETF *only*...
At the limit one can say that 7.1c and 7.1e are not provided by RFC 3667!

Thanks

---

From: [email-masked] (Kai Henningsen)
Date: 10 Oct 2004 10:54:00 +0200

> Nor need there be.  If the leadership is down to these two choices and

Huh?! Whatever choices "the leadership" is down to is utterly irrelevant.  
It's not up to them to decide. It's up to all of us.

> which one is best, there is still no need to have to state "I don't like

How else can you possibly use that poll to determine consensus, and not by  
deceiving yourself?

> Everyone has had plenty of airtime on this issue.

You're being very silly.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 10 Oct 2004 11:32:00 +0200

> prior art is readily establishable.

Strangely enough, those exact same events gave me hope that the IETF is  
not yet hopeless.

I count this one as a win.

Because the evil patent side (i.e., MS) *failed* to get their patented  
baby (which it turns out now probably isn't even theirs in the first  
place) made into an Internet standard.

Before this had been played out, I had been rather afraid that they'd win  
this round.

Instead, they lost, and we won.

Why is that bad?

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 10 Oct 2004 11:16:00 +0200

> proposal.  At best, they both just miss the point.

You write as if there was only one point or problem.

That is clearly utter nonsense.

Of course these proposals do not address Eric's point. They weren't meant  
to. They address a different point, and one that actually has zero overlap  
with Erics point.

Really, it's a completely different debate, and joining the two, as Eric  
has done, does not help either one.

Please stop it.

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 10 Oct 2004 11:21:00 +0200

> 6 months for what happens if we try).

Actually, the recent such debate told me that there are no rasonable  
objections there (though several quite unreasonable ones).

MfG Kai

---

From: [email-masked] (Kai Henningsen)
Date: 10 Oct 2004 11:05:00 +0200

> they are in those seats) instead of explanation and openness

Frankly, I see a lot more of that from the community than from the  
leadership, at least in the current debate.

> (virtually) shouting "wrong" instead of engaging in discussion

This looks to me like a distinction without a difference. Or put  
differently, this "WRONG" is an invitation to explain why it isn't  
actually wrong. It's certainly not their job to explain your side of it.

Instead, you start a meta-debate.

Seems to me it's you not following through on your own principles.

MfG Kai

---

From: Florian Weimer <[email-masked]>
Date: Sun, 10 Oct 2004 19:23:09 +0200

> prior art is readily establishable.

Are you familiar with IETF IPR policies?  Microsoft's Sender ID
license was a perfectly acceptable RAND patent license.  The outcome
of the decision is quite surprising, and underlines that even though
the IETF has policies that can put free software at a disadvantage,
the IETF community makes sure that these policies are not used for
some of the most important protocols.[1]

Regarding the existence of prior art, it's almost inevitable that
Microsoft's patent claims will be narrowed significantly when the
patent is granted in a few years.  The exact scope of those claims is
very difficult to predict, though, and so are the costs of
standardizing on an infringing protocol.

Maybe I'm a bit biased because I think SPF and Sender-ID are wrong
from a strategic point of view.  IMHO, it's a very bad idea to put DNS
so close to the center of the spam wars because it's so likely that
the resulting collateral damage on DNS as a whole will destabilize the
domain name system as a whole, and a have a devastating side effect on
the Internet.

1. Some core protocols are heavily patent-encumbered, though, or have
become encumbered as implementation strategies evolved.  Efficient
packet forwarding is certainly one of the Internet fundamentals,
however it's far from obvious how to implement it without breaking a
couple of patents (similar to the situation with compression
algorithms at the beginning of the 90s).

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 10 Oct 2004 19:36:48 +0200

On 10-okt-04, at 19:23, Florian Weimer wrote:

> couple of patents

Can you elaborate?

---

From: Florian Weimer <[email-masked]>
Date: Sun, 10 Oct 2004 19:46:08 +0200

>> however it's far from obvious how to implement it without breaking a

A stateless longest-prefix matching algorithm which costs only a few
dozen cycles (or very few cache misses) per lookup (even for random
addresses), provides fast routing table inserts and reasonably
efficient deletes is not exactly trivial to come up with.  A few
people have been looking for something that is reasonably fast and not
covered by patents yet, but I'm not aware of any interesting
discoveries.

(I'm talking about software implementation here.  Network search
engines/TCAM might be too trivial to be patentable, and you probably
can punt liability to the TCAM manufacturer anyway.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 10 Oct 2004 21:42:06 +0200

> covered by patents yet, but I'm not aware of any interesting

Are you saying that the patricia tree / trie datastructures and/or 
their search methods are patented? I was under the impression that this 
stuff came from the academic world and as such would be unencumbered by 
patents.

No wonder all the kids want to be lawyers these days.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Oct 2004 15:43:12 -0400

>>>>> "scott" == scott bradner <[email-masked]> writes:

    scott> I do not see any problem for the open source community
    scott> unless that community wants to create a new version of TCP
    scott> and take parts of existing IETF RFCs to include in its
    scott> description of their revised TCP

We do generally require this freedom of things that we're going to
call open source.  There are a lot of reasons why you would want it
and a fair number of reasons why this freedom is a bad idea.

It's certainly a problem; operating systems like Debian have decided
to stop distributing the RFC collection because of the IPR issues.
(We are able to distribute them but choose not to because we cannot
give our users the rights we typically give them along with things we
distribute.)

If you understand the open source position and disagree with it, then
there's probably little more to say.  If you don't understand the open
source position, let's get together in person and discuss the issue.
I think this discussion may go much better in person than over a list.

--Sam

---

From: Florian Weimer <[email-masked]>
Date: Sun, 10 Oct 2004 21:49:13 +0200

* Iljitsch van Beijnum:

> their search methods are patented?

No, their performance is just less than stellar (at least for the trie
algorithms that have been around since the mid-80s).

> I was under the impression that this stuff came from the academic
> world and as such would be unencumbered by patents.

Other routing algorithms come indeed from the academic community, but
are covered by patents nevertheless.  I can't speak for the U.S., but
here in Germany, we are aggressively pushing for more patent output
from universities.  A few years ago, law was even changed in a way
that supervising professors no longer can decide if they want to
patent a discovery (sorry, "invention") or not, it's now up to the
university.

---

From: [email-masked] (scott bradner)
Date: Sun, 10 Oct 2004 15:53:02 -0400 (EDT)

> there's probably little more to say.  

If the position is that the open source community can take an IETF 
consensus-based standard, modify it and claim that the new version is
the "real" standard then I do disagree - I think that standards must 
be developed and modified in open consensus-based processes, not by
individuals or groups unrelated to the group that developed the
standard.

If that is not the positition the I guess I do not understand and a 
discussion would be helpful

Scott

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Oct 2004 16:02:02 -0400

>> If you understand the open source position and disagree with
    >> it, then there's probably little more to say.

    scott> If the position is that the open source community can take
    scott> an IETF consensus-based standard, modify it and claim that
    scott> the new version is the "real" standard then I do disagree -
    scott> I think that standards must be developed and modified in
    scott> open consensus-based processes, not by individuals or
    scott> groups unrelated to the group that developed the standard.

The open source community definitely wants to be able to guarantee to
its users the ability to take text or code from an IETF standard and
use that text or code in derivatives of that standard.  Parts of the
open source community want to be able to claim that that standard is
the real unmodified thing.  Other parts of the open source community
would be happy changing the name of the work and clearly indicating
what it is.

Areas where a discussion might be useful would be to explain why the
open source community wants to do this etc.

--Sam

---

From: [email-masked] (scott bradner)
Date: Sun, 10 Oct 2004 16:05:19 -0400 (EDT)

seems to be a reliable way to ensure that there are multiple understandings
of what the standard actually is - I find it hard to understand who that
is good for

Scott

-------

>From [email-masked]  Sun Oct 10 16:01:46 2004
To: [email-masked] (scott bradner)
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked]
Subject: Re: Copying conditions
From: Sam Hartman <[email-masked]>
Date: Sun, 10 Oct 2004 16:02:02 -0400

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Oct 2004 16:18:01 -0400

>>>>> "scott" == scott bradner <[email-masked]> writes:

    scott> seems to be a reliable way to ensure that there are
    scott> multiple understandings of what the standard actually is -
    scott> I find it hard to understand who that is good for

Do you think that trying to describe a modified version of TCP without
taking text from the original RFC is likely to lead to a better
situation?

Honestly I think the issue of whether derivative works can use text
from the original is distinct from whether derivative works can be
confused with the original.

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 10 Oct 2004 16:26:31 -0400

>would be happy changing the name of the work and clearly indicating

The above paragraph probably also works if you replace "The open 
source community" with the name of any large Internet-related 
software or hardware company, such as "Microsoft" of  "Cisco".  There 
is a lot to be gained by embracing and extending existing standards 
and establishing your own defacto standards that are supersets of the 
originals.  But, those defacto standards tend to be detrimental to 
one of the primary goals of the IETF:  interoperablity.

>open source community wants to do this etc.

While it might be interesting to gain this insight into the 
motivations open source community, I don't know that it would be 
pertinent to the issue at hand.

A better question to answer would be:  Why would allowing the 
publication of modified or extended IETF standards (by the open 
source community or others) be good for the Internet?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 10 Oct 2004 16:31:46 -0400

>confused with the original.

While I am most definitely not a lawyer, it is my understanding that 
it is permissible to quote from copyrighted works as long as they are 
properly referenced.  I don't think that we should stop people from 
quoting (and referencing) RFCs, but we should stop people from 
producing modified and/or extended versions of the original.

If you believe that our current copyright/IPR text somehow forbids 
quoting and referencing RFCs in other works, could you explain why 
you think that?

Margaret

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Oct 2004 16:37:54 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    >> Areas where a discussion might be useful would be to explain
    >> why the open source community wants to do this etc.

    Margaret> While it might be interesting to gain this insight into
    Margaret> the motivations open source community, I don't know that
    Margaret> it would be pertinent to the issue at hand.

I've always found that understanding someone's position is an
important and necessary step to determining if it is a good idea.  I
don't think a discussion of whether this is a good idea for the
Internet would be useful without first understanding the positions of
the people who think it is a good idea.  But if you have a different
way of building consensus feel free to pursue that way.

Some questions I'd suggest you consider:

* Have the IETF's current IPR practices actually limited any company's
  ability to embrace and extend Internet standards?

* Have the current IETF's IPR practices limited the ability of any
  company  to explain how it has extended Internet standards  when it chooses to do so?

* What problems are created if the IETF fails as an organization?
  Would a successor be able to take existing standards and produce
  standards based on them?  How do the IETF's IPR processes  make this easier or harder?

--Sam

---

From: [email-masked] (scott bradner)
Date: Sun, 10 Oct 2004 16:38:34 -0400 (EDT)

small quotes are fine (under fair use) but significant excerpts are not
(under normal copyright law and under the copyright notices on IETF RFCs)

Scott

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Oct 2004 17:24:54 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:
    Sam> Some questions I'd suggest you consider:

    Sam> * Have the IETF's current IPR practices actually limited any
    Sam> company's ability to embrace and extend Internet standards?

  That's a biased question.
  You use the word "company"

  As such, you imply a whole set of things that do not work out
correctly in the open source world.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Oct 2004 00:43:52 +0200

> small quotes are fine (under fair use) but significant excerpts are not

Indeed. I'm not a lawyer either, but it seems to me many people are 
attributing much more power to copyright law than it actually has. If 
some evil (open|closed) source movement wants to grab IETF standards 
and build "improved" versions, the question whether they can copy parts 
of the original IETF standards documents really isn't all that 
relevant. If they can't, all they have to do is restate everything they 
want to copy in their own words. Remember, ideas can't be copyrighted, 
only their expression (in this case the actual verbatim text) can.

However, this is not to say that having anyone who feels like it modify 
RFCs and republish them is a good idea. Treating natural language text 
as source code is a spectacularly bad idea. But then, anyone who has 
ever tried submitting changes to the collected works of Shakespeare 
already knew that.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Oct 2004 01:29:42 +0200

> there seems to be an assertion of evil intent here that is not the case

What gave you that idea?  IMHO, let's leave intent for some other
discussion, and focus on the license.

After having read the discussion for the past few days, I still see no
useful text in RFC 3667 that permit me to do the things I mentioned
earlier, if the RFC 3667 license would be used.  Repeated here for
simplicity:

The text that has been referenced is in section 7 of RFC 3667,
"Exposition of Why These Procedures Are the Way They Are":

I don't believe I can use this text in a legal argument to motivate
why I'm copying parts from a RFC.

First, the text appear to be from a discussion about the license, not
the actual license.

Secondly, the qualifier "some" in "extract some logical parts" is
worrying.  Without further details, "some" might mean anything,
including preventing exactly those parts I need.

Thirdly, if you read the license, it seem (to me) clear that it
doesn't imply the right granted in (e).

>    to reproduce RFCs or parts of RFCs in manuals

What I'm arguing for, then, is that the license should reflect the
intent.

> existing IETF RFCs to include in its description of their revised TCP

I don't speak for the open source community, but I believe it should
be possible to do exactly that.  Naturally, I would have no right to
claim that my version would be IETF's TCP, or that my version is the
"real" version.  However, I need to have the right to create
derivative work from RFCs.

To perhaps give a better example of why I need this right, let's take
the first item above: IDN.  After the IDN specification has been
published, some problems in Unicode NFKC has been discovered that may
have security consequences.  If someone wanted to offer their users an
improved IDN library, they could take my library and modify it.
However, they could not describe how the new product work, by taking
the existing RFC and add a few paragraphs that solve the problem.
Instead, the RFC license, from my current understand at least, would
force them to write a complete new specification.  I don't believe
that is acceptable.  Fortunately, in this case, IDN was published
under the old RFC 2026 license, which I maintain would permit this
use.

Finally, derivative works need not only be about revised
specifications.  It may simply be copying tables from a specification
into an implementation.

Thanks,
Simon

---

From: Anthony DeRobertis <[email-masked]>
Date: Sun, 10 Oct 2004 19:26:02 -0400

> ever tried submitting changes to the collected works of Shakespeare 

Many people have taken the works of Shakespeare and modified them. 
Several successful movies, musicals, etc. come to mind. Treating natural 
language text as source code is only a bad idea in that the compiler 
won't like it.

What the free software community would like is a license that would 
allow it to take the text an RFC and use that text for writing software, 
other standards (or non-standards), etc. We don't have any need --- or I 
hope want --- to mis-represent the modified versions as standards of the 
IETF.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Oct 2004 01:39:05 +0200

> If he joins an IETF list (any IETF list), he's allowed to.

I don't believe I, nor "he", would be able to represent the IETF in a
court, as the legal owner for a work, merely because I ("he")
participate in some mailing list.  As far as I can tell, that would
ultimately be required if you were to defend the rights to your work.

If, instead, "third parties" where granted rights to create a
derivative work from RFCs, both I and "he" could represent such a
"third party".

Btw, I don't believe I'm a member of any IETF mailing list, although I
do participate in them.  Hint: gmane.org.

Thanks,
Simon

---

From: [email-masked] (scott bradner)
Date: Sun, 10 Oct 2004 20:06:53 -0400 (EDT)

Simon sez:

just so there is no misunderstanding - the intent of RFC 3668 was to
permit such extractions and there was (and is) no desire to restrict 
such extractions

I, as editor, state publicly that I think that RFC 3667 permits such 
extractions, we (or maybe I) may have not made that clear enough in
RFC 3667, but I think that RFC 3667 supports these uses - some people
on this list appear to disagree but I don't see much reason to continue
to argue about it because I see little reason for someone to think that
they would be attacked for making such extractions.

I can not conceive of a situation where the IETF (or ISOC) would ever
attempt to say that someone cannot do such extractions.  I suppose if
someone really pissed off a document author that author might try
to pull such a ploy - if that were to happen I expect that the 
question of extractions would be very much of a sideshow in the legal 
battle - for what it's worth I hereby offer to testify pro bono (but
expenses would need to be covered :-) ) to say that we intended that 
such extractions were permitted.

Note that this question is different from the other one in this thread
about someone taking text from an IETF RFC with the intent to created a
modified version of the RFC.

Scott

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Oct 2004 22:53:10 -0400

>>>>> "Eric" == Eric S Raymond <[email-masked]> writes:
    Eric> You've had two direct warnings about this -- the ASF and
    Eric> Debian open letters.  They interpreted IETF's passivity on
    Eric> the Sender-ID patent issue as damage and routed around it.
    Eric> If the IETF doesn't get its act together, that *will* happen
    Eric> again.  The open-source community and its allies will have
    Eric> no choice but to increasingly route around IETF, and IETF
    Eric> will become increasingly irrelevant.

I'm a bit confused here.  As I understand things, Debian and ASF
provided input to an IETF consensus call.  They asked us not to
approve a standard that depended on certain IPR.

Based on that input and other input received by the working group, the
chairs decided that they did not have consensus to advance a standard
based on this IPR.  I.E.  The IETF did exactly what Debian and ASF
asked us to do.

That seems like a reasonable outcome under our process.  It also seems
directly consistent with what Debian and ASF asked the IETF to do.  

Could you help me understand your concern?

--Sam

---

From: Dean Anderson <[email-masked]>
Date: Mon, 11 Oct 2004 03:50:01 -0400 (EDT)

> problem, and that the IETF needs to deal with these issues in a rational 

<LPF President hat on>

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.

> 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

<LPF President hat off>

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

---

From: Dean Anderson <[email-masked]>
Date: Mon, 11 Oct 2004 03:50:24 -0400 (EDT)

> 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.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 Oct 2004 10:39:41 +0200

> producing modified and/or extended versions of the original.

In some standardization efforts, it's customary to update standards by
issuing a diff to that standards: "in section 5.2, after the word
"interoperability", insert the words 'and efficiency'".

This is worst possible case: We have a technical description that is
very hard to understand, and the ISOC copyright failed to prevent the
creation of a competing standard.

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Mon, 11 Oct 2004 09:45:34 +0100

> scott bradner wrote: 10 October 2004 21:39

Well I've just reached to the shelf behind me for a book that some well
meaning (but possibly misguided) soul gave me called "The Big Book of IPSEC
RFC's" compiled by Pete Loshin and published in 2000, by Morgan Kaufman
www.academicpress.com

This contains full text of RFC's 1320, 1321, 1828, 1829, 2040, 2085, 2104,
2144, 2202, 2268, 2401, 2402, 2403,2404, 2405, 2406, 2407, 2408, 2409,
2410,2411, 2412,2451, and 2631. It also contains some commentary.

On its notices page is the following statement.

"Compiliation copyright @ 2000 by Academic Press"

and

"The RFC's compiled in this volume are copyright @Internet Society. All
rights reserved. The Internet Society requires the following notice:

The RFC's in this compilation and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, the RFC's
themselves may not be modified in any way, such as by removing the copyright
notice to The Internet Society or other Internet organisations, except as
needed for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process must be
followed, or as required to translate into languages other than English.
The limited permissions granted above are perpetual and will not be revoked
by The Internet Society of its successors or assigns.
The RFC's are provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. "

Does this qualify as a small quote?

Christian

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 Oct 2004 10:43:21 +0200

> one of the primary goals of the IETF:  interoperablity.

If you prepare a derivative work under copyright, it doesn't
automatically become an alternative to or replacement of the original
standard.  Further steps are necessary, and these steps don't really
depend on the existence of a modified standard (or any documentation
whatsoever).

---

From: Dean Anderson <[email-masked]>
Date: Mon, 11 Oct 2004 04:51:08 -0400 (EDT)

> 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.

> 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.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 11 Oct 2004 11:37:42 +0200

>impossible to overlap and cross-license.

This is why the only solution is UN e-human rights to be inforced by WIPO 
saying that every man is entitled to a free access to the common online 
relations logics, like every man is entitled to free speech. This is what 
we need the WSIS to declare in November. Then we need that a forum is 
acknowledged as responsible to declare what is "common technology", 
validate free to all access code, and organize/negotiate compensations to 
concerned IPRs (like for TV technology, like for TLDs). We do not need to 
reinvent the wheel. But we need the wheel to be the same type as others.

jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Oct 2004 13:24:28 +0200

Dave,

> experience in that work and that work requires skill and 

ISOC, like IETF, is largely a volunteer organization as far as
this sort of work is concerned.  If the community wants
ISOC to take such a role, the community will also have to provide
the volunteers.
> ISOC does not regularly testify in Congress.

ISOC is international and is currently active in WSIS, the international
debate including Internet policy issues. If you want ISOC to take part
in national policy-setting in your country, it's in your hands. That's
one of the things ISOC chapters can do.

> That includes minor items like operational administration of a 

Well, nobody has demonstrated that skill as far as the IETF is
concerned, because we've never put *all* the administration into
one place. (Disclaimer: this isn't intended as a comment on
the separate administrations of the secretariat, IANA, and RFC
Editor.) But ISOC has administered itself for the last ten years,
through good times and bad.

    Brian

---

From: [email-masked] (scott bradner)
Date: Mon, 11 Oct 2004 07:40:49 -0400 (EDT)

> Does this qualify as a small quote?

sigh

reprinting full RFCs has been permitted & encouraged ever since RFCs
were first published - the copyright on the RFCs makes that clear 

Scott

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Oct 2004 13:56:40 +0200

On 11-okt-04, at 1:26, Anthony DeRobertis wrote:

>> However, this is not to say that having anyone who feels like it 
>> modify RFCs and republish them is a good idea. Treating natural 
>> language text as source code is a spectacularly bad idea. But then, 
>> anyone who has ever tried submitting changes to the collected works 
>> of Shakespeare already knew that.

> Several successful movies, musicals, etc. come to mind.

I'd be interested to see how many lines of West Side Story actually 
match Romeo and Julia... Deriving something new from natural language 
generally doesn't entail significant verbatim copying. Improving on 
software on the other hand is much easier if existing code can be 
reused.

(There are numerous other differences as well. For instance, while it's 
common for software writers to write software they want to run 
themselves, text writers generally don't write in order to be able to 
read what they've written.)

> allow it to take the text an RFC and use that text for writing 
> software, other standards (or non-standards), etc. We don't have any 
> need --- or I hope want --- to mis-represent the modified versions as 
> standards of the IETF.

Have you tried asking RFC authors for the additional rights you require?

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Oct 2004 18:53:17 +0200

=> no more since RFC 3667 which has made nothing clear for third
parties.

Thanks

PS: only 7.1b suggests something about reprinting by a third party.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Oct 2004 10:00:18 -0700

Brian,

> > >  ISOC.  Because ISOC's role in the standards process is at
> > >  one remove, it can work to educate legislatures and
> > >  administrations without appearing to favor one
> > >  participant over the other.

>  ISOC, like IETF, is largely a volunteer organization as far
>  as this sort of work is concerned.  If the community wants
>  ISOC to take such a role, the community will also have to
>  provide the volunteers.

I do not understand your point.  We are going to hand over all 
administrative responsibilities for the IETF to a volunteer 
effort?

My guess is that the difference in our views is the difference 
between theory and practice.  I am making an assertion about 
ISOC's actual skills, based on its history of performance.  You 
appear to be making assessment based on the theory of its 
framework, or potential, or somesuch.

ISOC "can work" to do all sorts of things.  The question is what 
has it demonstrated skills in?  If the IETF is going to increase 
its dependence on ISOC, then the IETF needs assurances that ISOC 
can perform the tasks that the IETF needs.

When we step away from theory and rhetoric, I believe we find 
that ISOC has literally none of the necessary skills.  To the 
extent that it has attempted relevant activities, I believe its 
track record is poor, at best.  

In general what I have noted about the discussion of 
organizational structure/home for the IETF is that it pretty 
complete lacks clear, precise, stable specification of the job we 
want done.  So when I talk with individual about it, the details 
of their response float all over the map.

My experience with this sort of variability in responses is that 
there is some sort of mystical hope that making some sort of 
change will have major benefit.  However no one is able to state 
any of this concretely.  And the outcome of such a process is 
pretty much certain to be disappointing, at best.

We want to delegate all sorts of responsibilities to ISOC; or 
maybe we want ISOC to delegate them to 'experts'.  We want ISOC 
to handle the IETF budget, but we do not believe we are handing 
ISOC any additional power over the IETF. And so on.

I have tried to list specific problems with the IETF and note 
that none of them will be improved by the current structural 
work.  Most will not be affected at all.  What I have noted is 
the lack of specificity in any responses about this.  It is 
significant that this line of enquiry is not pursued further.

As nearly as I can tell, the IETF leadership's current concern is 
that CNRI/Foretec have too much power and too little 
accountability.  What is being proposed is, frankly, hand over 
exactly that same role to ISOC.  CNRI would be replaced by ISOC.

Now the obvious and vigorous responses to this assessment is that 
there will be vastly greater accountability, that there will be 
an MOU, that ISOC are good people with good intentions, and so 
on.

All of that might well be true, but it ignores that 
organizational behavior reality that different organizations 
always have different goals, at some point.  A relationship needs 
to be developed with very precise and appropriate specification 
of the details to that relationship.  

To that end, I suspect the single most important piece of work is 
the MOU.  Rather than discussing high-level structural 
abstractions, we should be discussing the precise contents of a 
specification for the job we want done.  

When we have agreed on those details, we can present them to all 
sorts of people and organizations, including ISOC (and, by the 
way, CNRI).  What should ensue, then, is a negotiation for 
performance of those tasks.

Where is the public discussion and refinement of that work?

> >  As has been commented to me repeatedly in recent months,
> >  when someone in government wants to obtain advice about
> >  the Internet and about Internet policy, they do not
> >  regularly consult ISOC. ISOC does not regularly testify in
> >  Congress.
>  ISOC is international and is currently active in WSIS, the
>  international debate including Internet policy issues. If you
>  want ISOC to take part in national policy-setting in your
>  country, it's in your hands. That's one of the things ISOC
>  chapters can do.

The reference to the US Congress was an exemplar.  And 
"participation" in WSIS could mean lots of things.  I have gone 
to some ITU meetings, but that does not place me in the role of 
providing policy leadership to the ITU.

If someone is going to claim that ISOC is in a leadership 
position for Internet policy-setting groups, then it would be 
helpful to see description of its activities in the regard that 
show actual leadership.  Going to meetings is not enough. Running 
a workship is not enough.  Policy-setting is an ongoing political 
dialogue.  Where are ISOC's political skills?

> >  More generally, as folks postulate spiffy functions for
> >  ISOC, it might be worth asking where ISOC's expertise for
> >  that function has been demonstrated.
> >  That includes minor items like operational administration
> >  of a standards body.
>
>  Well, nobody has demonstrated that skill as far as the IETF
>  is concerned, because we've never put *all* the
>  administration into one place. 

I am afraid that this is another example of how muddied 
discussion of this topic is.  (And that's not a criticism of you 
in particular.  I think the issue is the entire tone and content 
of the community discussion and, apparently, the leadership's 
internal discussions.)

I did not say we do not need to rationalize things.  I think the 
portion of the Advisory Committee's report that did problem 
analysis was excellent.  We need to rationalize accounting, 
accountability and authority.

My point is that there seems to be a mystical belief that we can 
hand everything over to ISOC and it will solve everything.  In 
fact it will solve nothing.  

The solution(s) lie in the details that can only be accomplished 
by the IETF, itself, unless we simply want to make the IETF a 
wholly-owned subsidiary of the organization we hand ourselves 
over to.

Obviously, lots of folks do not agree with my assessment.  What 
is lacking is anything concrete and detailed to explain why.

>  But ISOC has administered
>  itself for the last ten years, through good times and bad.

Frankly, Brian, this statement is rather scary.  

First of all, the ability for an organization to administer 
itself has nothing at all to do with its ability to perform the 
job the IETF is considering giving to ISOC.  

Second of all, ISOC's extremely problematic history is not likely 
to serve as a recommendation for its ability to perform whatever 
the heck it is we are currently asking of it.

d/

d/
dcrocker  a t ...
www.brandenburg.com

---

From: Florian Weimer <[email-masked]>
Date: Mon, 11 Oct 2004 19:03:35 +0200

* Eric S. Raymond:

> Florian Weimer <[email-masked]>:
>> license was a perfectly acceptable RAND patent license.
>
> Yes, I am familiar with those policies.  Sender-ID is a perfect
> illustration of why they no longer suffice.  

If the failure of the MADRID WG was a "perfect illustration", there
wouldn't be so much disagreement about what it actually means.

> RAND is not good enough, not for open-source projects

This is certainly not news.  Where have you been since mid-2001?  At
least since the discussion about the W3C patent policy, it's widely
known that RAND terms discriminate against Free Software.

Similar attempts at reforming IETF's patent policy within the IPR
working group were shot down on formal grounds at that time, though.
(I haven't followed IETF IPR activities since then, and might have
missed a later attempt at a reform.)

> and certainly not when IETF policy allows Microsoft to burden
> developers with a sublicensing requirement that gives them effective
> control of who can write implementations.

Guess what?  Fees per copy distributed are perfectly valid RAND terms.
The "ND" in "RAND" does not extend to business models.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 11 Oct 2004 12:09:59 -0700

Dave,

You are correct we need a detailed documentation of the interface before we
deal with any corporate entity. As I see it the differences between your
opinion and others has more to do with your focus on the interface than the
organizational structure others are commenting on. My initial reaction to
your concern about ISOCs track record was that the IETF itself has even less
of a track record, and a poor one at that. Despite the legal difference
between the Administrative office being a separate corporation vs.
incorporating the IETF itself, the backers of both of those choices appear
to assume the IETF will directly deal with the financial issues because
their arguments against outsourcing all say 'they have a different focus'.
As several people have stated, the IETF participants have a technical skill
set and no demonstrable skills at financial administration. Why then are
people so quick to point out that outside organizations have a different
focus when our internal skill sets don't match the need?

Yes before we go off and sign agreements we need to know what the details of
those agreements will be. We do not however need to know all the details
before we set a general direction. This discussion has pointed out several
characteristics about the IETF as a collective:
We need an accountable entity that is responsive to the financial needs of
administering the IETF. We should be simplifying the funding profile for
supporting both the standards development activities and document
publication. We want sufficient autonomy to act as if we independent and all
powerful, yet we are quick to dismiss political & legal issues as
irrelevant. 

Others may add to the list, but taken collectively it should be clear that
scenario C is fundamentally the end of the IETF since it only addresses the
first item. Alternative contractors might cover the last item as well, but
ISOC provides the path that covers all three. Yes we still need details, but
that should be easier to do if we know where we are heading.

Tony 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dave Crocker
> Sent: Monday, October 11, 2004 10:00 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: isoc's skills
> 
> Brian,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Oct 2004 09:35:21 +0200

Dave,

> administrative responsibilities for the IETF to a volunteer 

No. Of course, as I said in my message, the ISOC has ten years'
experience of administering itself with professional, paid
staff on two continents, and experience of subcontracting
activities. That is where the IETF administration fits in.

But for activities such as advising national legislatures,
ISOC has always relied on high level volunteers (people like
Vint Cerf for example).

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Oct 2004 22:22:15 -0400

>>>>> "Florian" == Florian Weimer <[email-masked]> writes:

    Florian> * Eric S. Raymond:
    >>> Are you familiar with IETF IPR policies?  Microsoft's Sender
    >>> ID license was a perfectly acceptable RAND patent license.
    >>  Yes, I am familiar with those policies.  Sender-ID is a
    >> perfect illustration of why they no longer suffice.

    Florian> If the failure of the MADRID WG was a "perfect
    Florian> illustration", there wouldn't be so much disagreement
    Florian> about what it actually means.

    >> RAND is not good enough, not for open-source projects

    Florian> This is certainly not news.  Where have you been since
    Florian> mid-2001?  At least since the discussion about the W3C
    Florian> patent policy, it's widely known that RAND terms
    Florian> discriminate against Free Software.

What was interesting to come out of this particular incident is thtat
*royalty free RAND* is not good enough for open-source.  I knew that
already; I suspect a lot of open-source people would know that if they
though about it.

I have no idea whether Microsoft intended to discriminate against free
software or simply didn't understand the free software constraints.
What I do know and find unfortunate is that a vendor wanting to
license a technology for use in an IETF standard in a manner that is
acceptable to the free software community might easily make a mistake.
The IETF documentation could easily lead one to believe that all
royalty free licenses are the same in the eyes of the IETF.

I think it would be wonderful if the free software community could
come to a consensus about what their requirements are.  It would be
great if this were somehow communicated to the IETF.  I also think it
would be valuable if the IETF made this information easily available
to IPR holders wanting to create licenses for their technology.  I
hope we can all agree regardless of our position on whether the ietf
should use patented technology that the IETF should make it easy for
people who want to license their technolog in a free-software
compatible manner to do so.

--Sam

---

From: "Eric S. Raymond" <[email-masked]>
Date: Wed, 13 Oct 2004 22:55:54 -0400

Sam Hartman <[email-masked]>:
> come to a consensus about what their requirements are. 

That's not hard.  We need licensing conditions that don't require us
to either pay royalties or sign legal papers, and which don't inhibit
re-use of the code by restricting the area of application.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 15 Oct 2004 08:31:00 -0400

This strikes me as oversimplistic.  What if a commercial enterprise 
wanted to license its IPR in such a way that it put no constraints on 
open source, but retained constraints on commercial competitors?  I'm 
not sure you can get around a technical mandate for some kind of 
license and still retain those options.  -- Nathaniel

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 15 Oct 2004 14:52:38 +0200

There seem to be some misunderstanding here, free software is not
"non-commercial".  If someone wants to put restrictions of their ideas
on commercial competitors, that prevent the idea from being used in
free software as well.  The rights associated with "free software" are
granted to commercial entities as well.

Thanks.

---

From: shogunx <[email-masked]>
Date: Fri, 15 Oct 2004 03:52:38 -0400 (EDT)

> license and still retain those options.  -- Nathaniel

I can cite an example of a commercial enterprise with copyrighted GPL'd
products who has some emasures to prevent this.  They sell clusters, and
distribute the source code directly only to customers.  If you are an
open source programmer, get to know them, and ask nicely, they will give
you a copy for your purposes... i.e. if you want to "roll your own"
cluster.  One could also probably acquire a copy from one of their
customers, but a vast majority of their solution is hardware also, in the
form of master node and diskless processing nodes.

> > re-use of the code by restricting the area of application.

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 15 Oct 2004 09:46:17 -0400

Hi Eric,

I am afraid that your choice below won't mesh very well with why 
companies have software patents in the first place.  Software patents 
aren't free, and companies are fairly careful about maintaining their 
value.

So, I am wondering if there is a middle ground here somewhere...

Let's take an example:

Mighty Mouse, Inc. (MMI) is introducing an innovative new product 
called the CheeseGrater2000 (CG2K).  MMI engineers came up with a 
uniquely efficient way to use XML messages to control the real-time 
operation of the CG2K that allows the CG2K to be faster and more 
accurate than other cheese graters.  MMI has applied for a patent -- 
not just for using their special XML messaging technique for 
real-time control of cheese graters, but for using it to control any 
real-time device that contains a general CPU and a DSP (don't ask how 
a cheese grater uses a DSP... that's confidential! :-)).

Let's assume, for purposes of this exercise, that MMI's patent is 
legally valid and would stand up in court.  Let's also assume that 
there is no prior art.

MMI's primary intention is to protect the research investment that 
has allowed them to build faster and more accurate cheese graters 
than the competition.  Secondary goals are to use this patent for 
defensive value, and to see if the technology covered by this patent 
can be applied to differentiate other MMI products.

A bit later, the IETF forms a WG that comes up with a new XML-based 
management protocol for managing Wireless Access Points called 
WiReless Access Point Control (WRAPCTL).  Although the WG is unaware 
of this fact, the messages used in that protocol are in violation of 
MMI's patent(s).

Meanwhile, MMI has realized that their patented technique may allow 
for product differentiation in their IP Phone division 
(diversification is good!) and they have started talking to their IP 
Phone division about that possibility.

One of their IP phone engineers is active in the Transport area of 
the IETF, and has heard about the Cheese Grater Division's patent 
during internal meetings at MMI.  During a plenary presentation on 
the success of the WRAPCTL WG, the MMI engineer realizes that the 
Cheese Grater Division's patent might apply to the messages described 
in the WRAPCTL protocol if (and only if) that protocol were 
implemented on a real-time system containing a CPU and DSP (like a 
Wireless Access Point).  Being a conscientious IETF member and 
all-around good guy, the MMI engineer starts working with his legal 
department to draft an IPR disclosure including licensing terms.

MMI was entirely uninvolved in the creation of the WRAPCTL protocol, 
so they did not cause this conflict themselves.  They don't make (or 
plan to make) Wireless Access Points, and the success of the WRAPCTL 
protocol has no strategic value whatsoever for them.  However, being 
a nice company that doesn't want to damage the IETF, they would like 
to provide IPR terms that will allow people to implement the WRAPCTL 
protocol without paying any money to MMI.

However, in doing this, MMI wants to ensure two things:

(1) That they continue to protect their patent rights regarding the 
use of this technique for other purposes (such as cheese graters and 
IP phones).  So, they want to limit the royalty-free terms to 
implementation of the IETF's WRAPCTL protocol and/or to use on 
Wireless Access Points.  (I think that this would run amok of your 
proscription against "restricting the area of application", right?)

(2) That they maintain and enhance the defensive value of their 
patent, by making it clear that the royalty-free terms do not apply 
to anyone who sues them for violation of a different patent.  (If I 
understand correctly, the OSS community doesn't have a problem with 
this concept, as long as no paperwork is required?).

Are there any IPR terms that MMI could offer that would meet these 
goals while also allowing the WRAPCTL protocol to be implemented in 
OSS implementations?  If we could find that middle ground, I think it 
would be very valuable to the IETF and to the OSS community.

The sad truth, of course, is that (in the example above) it is far 
more likely that MMI would not determine that the WRAPCTL protocol 
violated their patents until longer after it had been standardized by 
the IETF and implemented in many commercial and OSS implementations. 
So, what would be do then?

Margaret

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 15 Oct 2004 10:37:37 -0400

> license and still retain those options.  -- Nathaniel

Your suspicion is correct.  The problem -- which I and others looked for
a way around for years, to no avail -- is that there is no bright-line
way to separate "commercial" from "noncommercial" activity.  All attempts
trip over edge cases like this:

* A distributor aggregating software to be sold as a CD-ROM anthology
  for a modest fee.

* An engineer using software for development on a project which is not
  yet software for sale, but intended to be in the future.

* Development activity taking place at a for-profit subsidiary of a
  non-profit association.

The open-source community figured out by about 1997-1998 that there is
no way to discriminate between "commercial" and "noncommercial" activity
that does not create fatal uncertainties about who has what rights at
what times.  When you add the problems of mixing software with licenses having
*different versions* of such a distinction the downside gets even worse.

Thus, the licensing guidelines of both the OSI and FSF forbid attempts at this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 15 Oct 2004 10:40:06 -0400

> granted to commercial entities as well.

That's an ideological answer, and therefore useless to anyone who does
not already buy the ideology.  Please see my last post for a less 
value-laden explanation.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 15 Oct 2004 11:07:50 -0400

Margaret Wasserman <[email-masked]>:
> companies have software patents in the first place.

You're right, it doesn't.  Unfortunately, we really cannot live with
anything less than I have described.  My personal wish that this
reality were different is as fruitless as yours.

> proscription against "restricting the area of application", right?)

Right.

Area-of-application rules mean that code reuse can be fraught with
dangerous legal problems because of someone's well-meaning judgment
call about what's in-area and what is out-of-area.  Such legal
exposure is death to us -- our project groups can't afford lawyers to
fight those battles -- so our licensing requirements have to foreclose
that entire category of causes of action.  Otherwise our development
and distribution methods, which depend on code reuse and redistribution
being safe and friction-free, would seize up and croak.

Myself, I'll cheerfully recognize that MMI's interest is legitimate in
some sense -- I wish I knew of a way to solve this problem that doesn't
have deadly poison side-effects, and have devoted a lot of think time
to trying to invent one.  No joy.
 
> this concept, as long as no paperwork is required?).

That's correct.

> would be very valuable to the IETF and to the OSS community.

I don't believe any such middle ground exists.  I and others have tried
to imagine it into existence and failed.  We regret this, but it seems
to be reality.
 
> So, what would be do then?

Suffer a lot.

What your scenario demonstrates is that there is a fundamental and 
nigh-unbridgeable conflict between open-source development and the
patent system.  The open-source community is already well aware of
this, thank you.  We don't know what to do about it either.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Oct 2004 11:35:14 -0400

You guys don't have a problem with the "defensive suspension"/"no first use"
clauses, do you?

Is there a "preferred" wording for it?

Brian

> Eric S. Raymond
> Sent: Wednesday, October 13, 2004 10:56 PM
> To: Sam Hartman
> Cc: Florian Weimer; [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: 15 Oct 2004 15:46:00 +0000

[email-masked] ("Eric S. Raymond") writes:

> ...
> The open-source community figured out by about 1997-1998 that there is no
> way to discriminate between "commercial" and "noncommercial" activity
> what times.  When you add the problems of mixing software with licenses
> having *different versions* of such a distinction the downside gets even
> worse.
> 

This only matters if you intend to limit redistribution.  The older BSD
licenseware limits only liability, not redistribution, and thus doesn't
care about details like commerce.  This could be a lesson for IETF if we
really are going to address IPR issues in the boilerplate by adopting any
kind of "open source" attitude.
-- 
Paul Vixie

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Oct 2004 19:06:22 +0300 (EEST)

> > come to a consensus about what their requirements are. 

FWIW, I tried to initiate this dialogue a couple of times, the latest 
on Feb/Mar 2004, but as I received no response from FSF/OSS community, 
I gave up.

> to either pay royalties or sign legal papers, and which don't
> inhibit re-use of the code by restricting the area of application.

Hmm.. Being an OSS/FSF enthusiast myself, I'm not sure if the last
requirement, about code re-use, is a strict requirement.  Sure, it
would be nice if there wasn't such a thing, but it would seem to be
better to get the first two points and fail at the third than get
nothing at all.

I mean, if I was writing code that would be under a patent, and free
usage rights were granted for interoperability with a standard only,
I'd just write a big fat warning in the code segment and the README
file warning that don't copy my code to some completely unrelated
project unless you know what you're doing.

Which clauses of OSS/FSF licenses does "no re-use" infringe?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Fri, 15 Oct 2004 10:28:22 -0700 (PDT)

> Is there a "preferred" wording for it?

I think you'll find virtually identical wording on this topic in several 
well-known licenses:

   http://www.apache.org/licenses/LICENSE-2.0

   http://www.mozilla.org/MPL/MPL-1.1.html

   http://www.eclipse.org/legal/cpl-v10.html

   http://www.opensource.org/licenses/afl-2.1.php

  - RL "Bob"

---

From: shogunx <[email-masked]>
Date: Fri, 15 Oct 2004 08:44:47 -0400 (EDT)

How can we not adopt some manner of "open source" attitude, Paul?  That
has been the basic methodology of the IETF for some time.  Otherwise, we
would be paying for every DNS lookup.

Scott

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Oct 2004 13:49:08 -0400

This text does not seem to cover what we usually encounter in protocol
development.  What happens is that you claim a patent that would be
infringed by implementing the protocol.  Another company has its own patent
that it also claims would be infringed by implementing the protocol.  You
are willing to grant a worldwide, royalty free license to the patent to
anyone, including the other company, so long as the other company doesn't
try to force you to pay a royalty or take out a more restrictive license to
his patent.

Take a look at:
http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIMPLE.txt

for an example.

Brian

> From: RL 'Bob' Morgan [mailto:[email-masked]]
> Sent: Friday, October 15, 2004 1:28 PM
> To: Brian Rosen
> Cc: IETF
> Subject: RE: Shuffle those deck chairs!
> 
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Oct 2004 17:58:15 +0000

> would be paying for every DNS lookup.

well, i am not the expert on this, but the discussion has to do with IPR
and change control being transferred to IETF as a side effect of the
publication of drafts and rfc's.  historically there have been at least
two approaches: (1) demand IPR surrender; (2) require IPR disclosure.  in
the second (and i believe, current) situation, draft authors are required
to state their IPR terms, and RFC readers can infer whatever they like from
the absence of surrender.  margaret is saying that sometimes the IPR can
be contested by someone other than the author, and later than RFC publication,
through no fault of anybody's.  eric is saying that the previous situation
whereby a draft author surrendered the IPR before RFC publication was better.
various others have said "but what if the IPR terms try to distinguish
between commercial and noncommercial?"  my observations are (1) there are
ways to do "open source" without this distinction, and (2) authors cannot
be expected warrant their IPR surrender in any case.

it's a lot more complicated than whether you have to pay for DNS lookups.

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 15 Oct 2004 15:00:33 -0400

> better to get the first two points and fail at the third than get

Think harder.  The problem with area-of-application rules is isomorphic
to the "commercial/noncommercial" problem.  The really nasty cases are
near service libraries.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: shogunx <[email-masked]>
Date: Fri, 15 Oct 2004 10:01:47 -0400 (EDT)

> > would be paying for every DNS lookup.

as with this rediculous sender-id issue, which is a blatant attempt by a
proven illegally operating monopoly to seize yet another part of the
worlds infrastructure with their "i stole it, but its mine, not yours,
pay me" mentality.  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.

> through no fault of anybody's.

people can say whatever they choose.  if someone wants to write
proprietary protcols, go ahead.  thats fine.  just not as part of the
IETF, with the intent to inject corporate control into the open standards
of the internet.  in order to maintain global interoperability, and prevent
the potential for abuse of monopoly position inherent in proprietary
software, patent encumerments and other such mechanisms must not be allow
to encumber the codebase at any level.

> eric is saying that the previous situation

the authors must know that the work they indulge in contributes to the
global commons that makes up the structure of the internet.  IMHO any
attempt to limit or restrict the process and methodology that the IETF has
created through hard experience of a great many years should fall upon very
deaf ears, and be passed off in a "no thank you, we would not like to purchase
your software" attitude.

> it's a lot more complicated than whether you have to pay for DNS lookups.

right, but if a similar mechanism as in question here were part of the
dns, then we would be paying for every lookup, and all of redmond would be
laughing.

Scott

---

From: [email-masked] (scott bradner)
Date: Fri, 15 Oct 2004 15:18:27 -0400 (EDT)

> whereby a draft author surrendered the IPR before RFC publication was better.

that has never been a requirement

Scott

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Oct 2004 22:27:43 +0300 (EEST)

> to the "commercial/noncommercial" problem.  The really nasty cases are

Maybe you should spell this out.

For example, service libraries need not be a problem.  Consider a
service library which infringes a patent on SIP, which is to be
restricted to interoperability with the SIP protocol.  There is no
issue if the service library is only useful with SIP, because all the
use cases of the service library (excluding looking at the code and
taking away the code) would be OK by the policy.

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.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Oct 2004 21:33:57 +0200

On 15-okt-04, at 15:46, Margaret Wasserman wrote:

> MMI's primary intention is to protect the research investment that has 
> allowed them to build faster and more accurate cheese graters than the 
> competition.

[...]

> would be very valuable to the IETF and to the OSS community.

Maybe I'm being naive here, but wouldn't it be possible for NMI to give 
away a free license to use their patent in the WRAPCTL protocol only? 
In copyright this is done all the time (although seldom for free): when 
I buy a DVD, I get to watch its contents at home, but the license 
doesn't allow me to show the movie in a theater or broadcast it over 
the air.

In cases where the patent has a broader use than as part of a network 
protocol this is actually good for the patent holder as now many 
companies will be implementing it, which can easily lead to reuse of 
said implementation for another purpose in which case a paid license 
would be required.

This doesn't solve all open source issues, but it should make the 
problem more manageable as the code that implements this protocol in 
question can be reused by anyone, just as long as it's only used for 
this specific protocol.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Oct 2004 21:34:05 +0000

> ...  notwithstanding, how can a specification be considered a standard
> if over half of the operators on the planet refuse to deploy it

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).

since the majority of those within the sound of my voice were not party to
the RSA-vs-DSA wars which characterized the early years of DNSSEC, i've
made a small archive available on the web.  you should really look at it,
especially the note from steve kent (then Security AD).  it's in "digest"
format rather than "mime" format at <http://sa.vix.com/~vixie/rsa-wars.txt>.

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 15 Oct 2004 16:21:19 -0400

> be expected warrant their IPR surrender in any case.

In fact, the *only* way to do open source is without this distinction.

I actually wish it were otherwise, but my wishes have no effect on the
logic of the situation.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 15 Oct 2004 15:20:29 -0400

RL 'Bob' Morgan <[email-masked]>:
> >You guys don't have a problem with the "defensive suspension"/"no first 
> >use" clauses, do you?
> >

Indeed.  The language in these licenses represents the community consensus
about patent termination.  Yes, there really is one; the official line of the
Debian project is an outlier, in dispute within Debian itself.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: shogunx <[email-masked]>
Date: Fri, 15 Oct 2004 14:28:52 -0400 (EDT)

On Fri, 15 Oct 2004, Paul Vixie wrote:

> i can't understand why this matters.

this matters as concerns the defacto sphere of influence and acceptance of
the ietf as the authoritative body regarding how the internet works.  both
groups, the ietf and the open-source/free software community, are working
towards the same goal, with similar methodologies.  from experience, it
seems this simple:  if you want widespread use of a technology, you give
it away, and tell people how it works.  this is essentially what has
happened with everything the ietf has ever produced, and hence the
exponential growth rate of said technology.  you will see a similar trend
with the growth of open source.  and don't forget that both groups arose
from similar sets of people, who were, in effect, doing everything they
could to figure out how to make things work.  if what is created in such
openness of process is spoiled by one guy saying to the rest of us "i know
how it works, cause i made it, and you must pay, and you still cannot know
how it works" then the whole process has failed.

> if ietf were to change its policies
> so that only "open technology" was allowed in the standards,

could you cite some examples of closed technology in the standards having
success in the real world?

> there would

that sounds like a poem.

> format rather than "mime" format at <http://sa.vix.com/~vixie/rsa-wars.txt>.

it seems to me steve was trying to move around patent/royalty encumerances
by using other technologies.

---

From: shogunx <[email-masked]>
Date: Fri, 15 Oct 2004 14:43:55 -0400 (EDT)

> I actually wish it were otherwise, but my wishes have no effect on the

Why do you say that?

The mail system could fork.  Then it would become social darwinism of the
emails.  Someone may even reimplement uucp.  It would be email chaos for a
bit.

---

From: James M Galvin <[email-masked]>
Date: Fri, 15 Oct 2004 20:27:06 -0400 (Eastern Daylight Time)

especially the note from steve kent (then Security AD).

Steve Crocker was a Security AD (and the first one for that matter).
Steve Kent was never a Security AD.  Steve Kent served on the IAB for a
very long time, preceding all Security ADs, although I don't believe he
was still on the IAB in 1994.

Jeff Schiller was the second Security AD, who started around 1994 or so.
I forget exactly when.

Jim

---

From: [email-masked] (scott bradner)
Date: Fri, 15 Oct 2004 20:35:28 -0400 (EDT)

> Jeff Schiller was the second Security AD, who started around 1994 or so.

see http://www.ietf.org/iesg_mem.html

Scott

---

From: "Eric S. Raymond" <[email-masked]>
Date: Sat, 16 Oct 2004 02:10:52 -0400

> > I actually wish it were otherwise, but my wishes have no effect on the

Because trying to make a distinction between "commercial" and "noncommercial"
activity is a road down which lies a toxic swamp of inadequate variant 
definitions and license conflicts.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Oct 2004 20:37:30 -0400 (EDT)

> 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.

---

From: "Eric S. Raymond" <[email-masked]>
Date: Sat, 16 Oct 2004 02:14:39 -0400

> IETF standards or a specific standard.  But I'm not sure if I recall

What happens when I want to re-use (say) a hash function from a library with
patent coverage and an area-of-application rule on the patent license?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Oct 2004 21:54:18 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> isomorphic > to the "commercial/noncommercial" problem.  The
    >> really nasty cases are > near service libraries.
    >> 
    >> restricted to interoperability with the SIP protocol.  There is
    >> no issue if the service library is only useful with SIP, because
    >> all the use cases of the service library (excluding looking at
    >> the code and taking away the code) would be OK by the policy.
    >> 
    >> 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.

    Eric> What happens when I want to re-use (say) a hash function from
    Eric> a library with patent coverage and an area-of-application rule
    Eric> on the patent license?  -- <a
  
  To add more meat to the example.

  Assume that the service library is in fact for HTTP, and it the patent
related to use of MD5 in basic-authentication. 

  Assume that Eric now wishes to *reuse* this library to implement
something similar as SIP.

- --

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Oct 2004 11:36:18 +0200

Dean Anderson wrote:
...
> is why alterations must be careful.

s/When/If/ if you want this statement to be read without laughter.

But you're right, of course. If *you* held all the software patents,
*you* could decide who got to use them.

Meanwhile, the IETF process deals with the real world, not with
hypotheticals.

    Brian

---

From: shogunx <[email-masked]>
Date: Tue, 19 Oct 2004 05:40:16 -0400 (EDT)

> is why alterations must be careful.

This is already the situation in many parts of the world, with the
developers left little recourse.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 19 Oct 2004 16:12:21 -0400 (EDT)

> 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.

> *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

If you think these are hypotheticals, then you are seriously uninformed.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 19 Oct 2004 16:21:51 -0400 (EDT)

>     >> 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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 20 Oct 2004 07:59:32 +0300 (EEST)

I'll try to refrain from further replies, as the sergeant-at-arms 
already declared this a bit out of scope..

> something similar as SIP.

There would seem to be two ways to tackle this kind of issue properly:

1) create a separate spec about MD5 in basic-authentication, and make 
it standards track.  Then it could be reused in every context if free 
use is granted for standards compliance, or

2) have the service library export only such interfaces that reusing 
them would not be possible without code modifications and seeing the 
licensing warning.

---

From: shogunx <[email-masked]>
Date: Wed, 20 Oct 2004 05:27:01 -0400 (EDT)

> restrictive licenses leave loopholes. Sometimes not.  That's why we have

Yes, lawyers who generally get rich doing little more than arguing.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 21 Oct 2004 01:08:38 -0400 (EDT)

> developers left little recourse.

Things are in a very sorry state.

---

From: [email-masked] (Kai Henningsen)
Date: 22 Oct 2004 21:27:00 +0200

[email-masked] (Eric S. Raymond)  wrote on 11.10.04 in <[email-masked]>:

> Kai Henningsen <[email-masked]>:
> > Why is that bad?
>
> There were, actually, two bad parts:
>
> 1. Two major open-source development groups felt it was both necessary
> and appropriate to state that they would not implement SenderID
> regardless of IETF's decision.  This is specifically what I meant
> by routing around the IETF.

You are confusing "will not" with "cannot" here. It's not "we don't want  
SenderID", it's "we cannot use SenderID even if we want to".

Thus, it is about (legal) facts, not about refusing cooperation.

> 2. IETF failed to take any position opposing the patent in spite of
> both prior art and the belief of key participants that Microsoft
> deliberately lied about its position and intentions.  By doing so, IETF
> signaled that there will be no downside to even the most blatant
> patent raid on a development standard, and invited future raids by
> Microsoft and others.

Given that the WG was shutdown with no ratified standard, this also seems  
like a serious misrepresentation.

The raid *failed* - thanks to the IETF doing the right thing.

MfG Kai

---

From: "Eric S. Raymond" <[email-masked]>
Date: Fri, 22 Oct 2004 16:20:42 -0400

> Thus, it is about (legal) facts, not about refusing cooperation.

That is not how I read their letters.
 
> like a serious misrepresentation.

In what way?  Microsoft now knows that with the mere threat of a patent
it either can shut down IETF standards work it dislikes or seize control 
of the results through the patent system.  The IETF has dignaled that it
will do nothing to oppose or prevent these outcomes.

> The raid *failed* - thanks to the IETF doing the right thing.

It looks like success to me.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: shogunx <[email-masked]>
Date: Fri, 22 Oct 2004 18:15:41 -0400 (EDT)

> will do nothing to oppose or prevent these outcomes.

How so Eric?  Could you give an example of potential weakness in the
IETF process that could be exploited?  So perhaps we could start
patching?  How would such a patent based denial of service attack scenario
play out?

> It looks like success to me.

Not really.  We still have email.

---

From: "Eric S. Raymond" <[email-masked]>
Date: Sat, 23 Oct 2004 00:07:13 -0400

> patching?  How would such a patent based denial of service attack scenario

Watch what happens with anti-spam "standards" in the next nine months.
I fear it's not going to be pretty.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

---

From: shogunx <[email-masked]>
Date: Fri, 22 Oct 2004 19:29:54 -0400 (EDT)

> I fear it's not going to be pretty.

We could out-code them.  PKI in the email;)

---

From: Eliot Lear <[email-masked]>
Date: Sat, 23 Oct 2004 17:51:08 +0200

On my way to the dust bin of history, I happened to notice this posting 
from Eric S. Raymond:

> of the results through the patent system.  The IETF has dignaled [sic] that it

If you want an SDO to not allow use of work based on asserted or claimed 
patent rights, then you have to accept that a company such as Microsoft 
will always be able to intervene and shut down a group or attempt to 
force decisions for its strategic benefit.  This is actually a strong 
argument for a compromise position, such as RAND.

In short, we've come full circle.  Can you take this conversation to the 
IPR group?

Thank you,

Eliot

---

From: [email-masked] (Kai Henningsen)
Date: 29 Oct 2004 21:42:00 +0200

> I fear it's not going to be pretty.

So ... do we actually need one in the first place? I'm certainly  
unconvinced of that. And from all I heard, SPF is certainly *not*  
something I like; the basic idea seems fundamentally flawed to me, and  
AFAICT that is the same idea as is behind SenderID.

MfG Kai