Subject: RE: FW: IETF copying conditions

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 14:43:52 -0700

I'm moving this to [email-masked]. There are important policy implications
here that the entire community should understand before we let the IPR WG
decide for us on a policy so opposite to open source and open standards!

I am also copying this separately to the Open Web Foundation (OWF) list,
which I believe may have some interest in ensuring that it can copy and
modify IETF specifications for its own standards any time it damn well
pleases.

/Larry

> > At 11:18 AM -0700 9/17/08, Lawrence Rosen wrote:
> >> Suppose you were to specifically ask whether IETF wants to prevent
> other
> >> SDOs from re-publishing (modified) IETF text within their own specs? Do
> you
> >> expect that the community here really wants to limit the use of IETF
> specs
> >> in that way?
> 
> Yes, undoubtedly that was the WG consensus. We don't want to see other
> SDOs
> publishing incompatible versions of our protocols, period. And this is
> not paranoia; it's evidence-based, although I don't want to point the
> finger
> at specific SDOs, since such matters are usually handled by courteous
> bilateral discussions. Using copyright protection is clearly a last
> resort.
> 
> >> Why on earth would a volunteer, cooperative standards
> >> organization like IETF want to do that to other volunteer, cooperative
> SDOs?
> 
> Becaus our primary mission is to make the Internet work better, which
> requires interoperable protocols, which precludes incompatible versions.
> 
>    Brian

*********************

Please note: There is an earlier set of emails on this thread in the
archives of the IPR WG.

/Larry

*********************

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, September 17, 2008 2:15 PM
> To: [email-masked]
> Subject: Re: FW: IETF copying conditions

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Sep 2008 15:18:45 -0700

>decide for us on a policy so opposite to open source and open standards!

Larry, I'm confused. What about the statement that "We don't want to 
see other SDOs publishing *incompatible* versions of our protocols, 
period" is the opposite of the policy of open standards (emphasis 
added)?

Which SDOs that you participate in want to see other SDOs publishing 
*incompatible* versions of their protocols?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Lawrence Rosen" <[email-masked]>
Date: Wed, 17 Sep 2008 15:42:32 -0700

> *incompatible* versions of their protocols?

Hi Paul, 

Of course none of the SDOs that I work with want to see incompatible
versions. But this turns the issue on its head. Open source and open
standards deal with the freedom to do things, even though we might
discourage people to take us up on that offer of freedom.

So with respect to IETF specifications, the open source and open standards
objective is that the world is *free* to make compatible or incompatible
versions of our specifications. (This is the philosophy that neither IETF
nor Microsoft nor IBM, nor anyone else, is going to be the absolute God of
acceptable software.) I'm sure that good people everywhere will cooperate to
ensure that all good versions of our specifications are compatible, and
cooperative people will be encouraged to remain compatible by virtue of the
quality of our work.

But if anyone, anywhere, for any reason, wants to take an IETF specification
and modify it, open source requires that he be free to do so.

The current proposed IPR policy seems to allow that for "code" but not for
"text" in our specifications. What a burden that imposes to protect people
from freedom!

/Larry  

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2008 3:19 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: FW: IETF copying conditions
>

---

From: Joe Abley <[email-masked]>
Date: Wed, 17 Sep 2008 22:35:20 -0400

> discourage people to take us up on that offer of freedom.

I have not followed this thread wherever it originated, and I have  
never been so much as tempted to read the IPR wg archives. But I'm  
going to reply anyway, in the grand tradition of this list.

I think the *whole point* of a standard is to restrict how things are  
done, in order to promote interoperability. Complaining about such  
restrictions makes no sense to me if interop is a desired goal (and if  
it's not, surely we can all go home).

It's no use to me if someone sells a product that claims to support  
"SMTP" if it turns out that the SMTP in question has been modified,  
replacing HELO with GDAY or some other nonsense that stops "SMTP"  
talking to "SMTP".

The point you made about code is surely related to *implementation*,  
not *specification*.

Joe

---

From: Tony Finch <[email-masked]>
Date: Thu, 18 Sep 2008 14:10:08 +0100

On Wed, 17 Sep 2008, Joe Abley wrote:
> done, in order to promote interoperability.

Standards are recommendations not restrictions.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
NORTHWEST SHANNON: SOUTHWESTERLY 5 TO 7, BECOMING VARIABLE 4 LATER. ROUGH OR
VERY ROUGH. RAIN, BECOMING FAIR LATER. MODERATE OR POOR BECOMING GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Thu, 18 Sep 2008 14:57:32 +0100

> Standards are recommendations not restrictions.

Let's say that the restrictions viewpoint wins out in the
IETF and all RFCs are copyrighted in such a way that I
am not free to publish a revised version.

What law would prevent me from publishing the following
GW-SMTP document?

----snip-----
Gee-Whizz SMTP is a derivative of IETF.

In RFC 2821 replace all occurences of HELO with GDAY.
----snip-----

This is clearly an incompatible derivative of SMTP but I 
don't even need to quote the document, even though "fair use"
laws would allow me to do that.

--Michael Dillon

P.S. it seems to me that the best way to ensure that incompatible
derivatives do not flourish is to make sure that the work of the
IETF remains relevant to the current situation, and not mired in
the past. That way, the IETF will maintain a position of respect 
and people will not want to create incompatible derivative works.

Openness is required in order for advancement to occur.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "James Seng" <[email-masked]>
Date: Thu, 18 Sep 2008 22:00:22 +0800

+1

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 18 Sep 2008 16:28:56 +0200

> laws would allow me to do that.

Indeed, and that is why the argument that specifications need to be
copy+modify protected in order to prevent incompatible derivatives is
silly.

Further, re-writing RFC 2821 using other words is a feasible task for
any significant SDO that really wishes to standardize a modified variant
of SMTP.

> Openness is required in order for advancement to occur.

+1.

/Simon

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 19 Sep 2008 13:52:38 +0200

On Wed, Sep 17, 2008 at 10:35:20PM -0400,
 Joe Abley <[email-masked]> wrote 
 a message of 31 lines which said:

> I think the *whole point* of a standard is to restrict how things
> are done, in order to promote interoperability. Complaining about
> such restrictions makes no sense to me if interop is a desired goal

The IETF has no such power: no one is forced to follow the RFC and no
one is forced to follow them correctly. This limit of the IETF process
is well-known and that's why I simply do not understand the IPR WG
frenzy to add new unenforceable rules.

> "SMTP"

That's trademark protection and it was never considered seriously by
the IPR WG. This WG, instead, tried to prevent people from reusing RFC
but did absolutely nothing to guard against an attack such as the one
you describe. (To create a rogue "SMTP" protocol, you do not need to
modify a RFC.)

> The point you made about code is surely related to *implementation*,  

No, no, Lawrence was talking about the new rules that treat separately
code and text in a RFC. (Many RFC have code and, under the current
rule, you cannot, in theory, extract it and reuse it in free software.)
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 19 Sep 2008 13:53:42 +0200

On Thu, Sep 18, 2008 at 02:57:32PM +0100,
 [email-masked] <[email-masked]> wrote 

> In RFC 2821 replace all occurences of HELO with GDAY.

Very good demonstration. That's precisely while the whole 3978bis
effort is flawed.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 Sep 2008 08:35:12 -0400

> frenzy to add new unenforceable rules.

I hear what you (and others) are saying, and I think I have just  
reminded myself why I have always studiously avoided conversations  
involving acronyms such as "IPR". To paraphrase Microsoft Exchange,  
"Joe Abley would like to withdraw his message".

Joe

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Sep 2008 11:50:56 -0700

>rule, you cannot, in theory, extract it and reuse it in free software.)

I think I understand what you meant here, but since "under the
current rule" is a fast moving target this week, I hope you
won't mind my expanding it.  Prior to the current update, it was
theoretically not possible to extract, re-use, *and modify* the code;
the current update fixes this.

The current update still allows extraction, copying, translation,
etc. of the text.  It does not automatically grant the right to modify
the text--but sufficient incoming rights have been solicited that
the ability to grant that right is now within the IETF (where before
it took individual grants from the authors).

I'd also encourage the folks who are reading this conversation without
the context of the IPR working group (you lucky, lucky dogs) to
read the draft.  It is notoriously difficult to get the facts from a
clarion call.
			thanks,
				Ted
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Sep 2008 12:24:41 -0700

At 11:00 AM -0700 9/18/08, Ian Jackson wrote:
>
>That a different system might do things differently would not be good
>for Debian so we don't encourage it.  We would prefer to keep Debian
>and its derivatives as close as possible so that we can share
>development work (particularly, so that we can all benefit from each
>others' improvements).

Thanks for your considered reply to the issues.  In the section above,
you hit on one of the crucial issues:  what's the cost of a fork? 

It's actually highly variable.  In many instances, a fork doesn't
actually create interoperability problems at all, but instead carries
two different code bases forward in different directions, while
still allowing bits and pieces from the two code bases to be passed
back and forth at will.  The cost there is low.  In other instances, it
does create two new systems, each of which continues to evolve
separately but without the ability to freely move code from one to
another.  Both instances may limit the benefit each group may have from
the other's efforts, but it is clearly the latter case which is the
most troubling.  

In the IETF, the lack of interoperability is
not simply expressed in the re-use of code, but in the compatibility
of the wire formats and thus the ability to pass messages among
the actors who share the net.  In the IETF, interoperability is one the
key measurements of  success; without it, no protocol is a success
in our terms.  There are things which must also happen, but it
is the foundation of all the protocol work that happens here. 
The contortions we engage to maximize that often look
strange, but they fall out of a very basic principle:

The Internet must not fork.

To remain "the Internet" and not simply an internet, we
must do everything we can to prevent it.  There are a host
of local optimizations which could be made in specific environments,
and there are extraordinary temptations at times to make
them and gateway at the border of those regions.  It's almost
always a mistake.  Every time we have broken the core
interoperablity of the network in order to achieve some
local optimization, the system as a whole has been hurt.
Sometimes so severely that we are still recovering. 

No one objects to the code implementing a protocol from being
changed, modified, or, yes, forked.  Maintaining a frankly
ugly distinction between "code" and "text" is an
expression of our willingness to see those modifications.
But our willingness to see the protocols drift into
a non-interoperable mess should approach zero.  It hurts
the net too much, by isolating those whom the net should
connect.

Speaking only for myself,
			regards,
				Ted Hardie

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Sep 2008 16:55:41 -0400

--On Friday, 19 September, 2008 13:52 +0200 Stephane Bortzmeyer
<[email-masked]> wrote:

>> It's no use to me if someone sells a product that claims to
>> support "SMTP"
> 
> That's trademark protection and it was never considered
> seriously by the IPR WG. This WG, instead, tried to prevent
> people from reusing RFC but did absolutely nothing to guard
> against an attack such as the one you describe. (To create a
> rogue "SMTP" protocol, you do not need to modify a RFC.)

Actually, it isn't trademark protection, at least in any of the
usual senses.

But it may be fraud, or at least misrepresentation of the
product.  And that is actually part of the point.  Independent
of any forks in code, etc., (and I completely agree with Ted
Hardie's comments on that subject earlier today), if it is well
understood that "SMTP" is a designator for a specific IETF
protocol, then it is desirable for that specification to be
sufficiently stable that those who buy can react if the
assertion is not true.   Of course, selling a product that
claims to conform to RFC 2821 is a somewhat stronger statement
than "claims to conform to SMTP" is "supports SMTP", but the
issues are very much the same.

Standards, as distinct from particular implementations and their
variations, actually serve two purposes.  We have been
discussing one, which, in the IETF case, is having
specifications that are sufficiently precise and stable that
interoperability among independent implementations is possible
and, indeed, likely.  Ted's summary of that situation is as
good, or better, than anything I could say.   But the other is
precisely to permit people to make "supports A" or "conforms to
B" claims in a reasonable way and to make those claims testable
(not by the IETF; we have chosen, I think wisely, to avoid the
certification business) and those tests to be enforceable by
contracts, public ridicule for deviations, etc.

Forks in documents, or other sorts of local variations, create
confusion in the marketplace and uncertainties about what claims
are being made.  They are, if anything, even more problematic
than the issues that Ted cites.

Of course, if someone wanted to say "this supports much of SMTP,
but reflects the author's own theories about some of the
protocol", there would be, I hope, no attempt by the IETF to
prevent that.  The marketplace would do whatever it chose to do
with such a package.

Finally, please remember that there is nothing about copyright
protection on the text of the specification that prevents an
implementation of that specification.  There might be exceptions
if our specifications were formal and systematic enough to
permit automatic translation of the specifications into code,
but, fortunately or unfortunately, that is not an issue.  The
other exception, of course, occurs when the specification
contains code, pseudo-code, or tables that have to be copied
literally... and that was exactly why the IPR WG decided to
separate those cases from the text.   But, as to the notion that
one can't realistically implement IETF specifications without
being able to change them and claim that one's changed version
is just an improved, equally-valid, version of the same thing, I
don't see how we can encourage that and still claim to be in the
business of making standards.

      john

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 21 Sep 2008 14:56:53 +0300

> Actually, it isn't trademark protection, at least in any of the usual senses.

> But it may be fraud, or at least misrepresentation of the product.

Well, actually that is almost the same thing.

A (common law) trademark is defined as a distinctive sign used by a legal entity
to uniquely identify the source of its product to consumers,
in order to distinguish them from products of others.
(Note that it need not be registered in common law jurisdictions, although registration has advantages.)
>From the beginning trademark infringement has been associated with the
common law tort of "passing off".

In the US the Lanham Act was enacted specifically to deter false or misleading statements
in advertising or promotion that may harm the holder of a mark.

In economic theories of law such marks are justified by the lowering of informational costs
for the consumer, who can be sure that once it is ascertained that a product fulfils a need,
a subsequent product bearing the mark is essentially the same as that originally tested.

This maps rather directly to the issue at hand.
The IETF as a legal entity used the term SMTP to designate a particular protocol.
Although the IETF is not technically the source of all implementations,
the RFC (and especially one with reference code) can be considered the source
which was being protected.
If one were to apply "SMTP" to a protocol not conforming to RFC 2821,
that would be passing off that protocol to consumers
by making misleading statements.
Furthermore, as it would not interoperate with RFC 2821 conformant implementations,
the information costs would be increased
as each time the term was used one would have to test interoperability.

Y(J)S

---

From: Ian Jackson <[email-masked]>
Date: Thu, 18 Sep 2008 19:00:35 +0100

> *incompatible* versions of their protocols?

The Debian project has published a small (by IETF standards) but
significant body of work specifying the interoperation and behaviour
of the various parts of what they regard as a modern Unix system,
particularly as regards the behaviour of package management systems
and the interoperation between separately-maintained packages.

The Debian standards documents (the core of which I originally wrote
but which have been greatly expanded and enhanced and are now
maintained by others) are released under a licences which permit
modified redistribution with a definite expectation that derivative
systems might want to do things differently.

However, the whole point of Free Software (and thus the point of
Debian) is that people are free to modify it.  If that means that they
are free to cause it to run to incompatible standards, so be it.  And
that freedom needs to be practically exerciseable collectively as well
as individually, so must include the freedom to properly communicate
within their own project what they are doing.  So we do not use the
law to prevent our derivatives from using modified versions of our
standards documents if they regard it as necessary.

Debian is a not insignificant organisation.  There are around 1000
members with voting rights.  Many of Debian's choices both at a
technical and political level have been influential in the relevant
fields.

Ian.

---

From: [email-masked]
Date: Thu, 18 Sep 2008 16:23:00 -0400

Larry,

> and modify it, open source requires that he be free to do so.

I think "requires" is a stretch.  There are a large number of non-IETF
standards implemented in open source for which copyright does not permit
arbitrary modifications, so I think "requires" is incorrect.  Copyright
provisions that do not grant derivative works rights and have
distribution
terms far less permissive than IETF's are common in other standards
bodies,
some of whom rely on charging money for copies of standards to fund
their
budgets. IETF has chosen not to charge for standards for many good
reasons.

Encouraging people who want to modify standards to talk to the people
who
developed the standards is a "good idea", and to the extent that
copyright
terms encourage people to do so, that's beneficial.  An example of the
benefits of this sort of discussion is RFC 4595 "Use of IKEv2 in the
Fibre
Channel Security Association Management Protocol" (I'm an author).  When
I started working on this, my initial belief was that an IETF RFC and
use
of IANA-allocated values was highly unlikely (e.g., IKEv2 for FC does
not
run over IP) and I was pleasantly surprised that the IETF Security Area
wanted to see the FC values and usage documented in an RFC.

OTOH, of the various arguments made for use of RFC text, the one I'm
most
sympathetic to is documentation - code comments, manuals, online help,
etc.,
where the ability to selectively quote from the RFC that is implemented
can be very useful.  This would need to be controlled, as blanket
permission for arbitrary selective quoting can be dangerous - it's
fairly easy to change a standard to be non-interoperable via selective
quoting.  For an (amusing) extreme example from another domain, see:

http://www.legis.state.wi.us/senate/sen10/news/FrankensteinVeto.pdf

While I doubt that anyone would ever resort to something that bizarre in
quoting from an RFC, I hope the underlying concern is clear.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Lawrence Rosen" <[email-masked]>
Date: Thu, 25 Sep 2008 10:13:55 -0700

Harald Alvestrand wrote;
> - The discussion of permitting change to text was extensive and repeated.
> - The consensus of the working group was the compromise position now
> documented.
> 
> I assert that if you want to claim that either of these two statements
> are false, YOU back it up with evidence. As it stands, you are making
> statements that I personally, as the WG chair who's tried to shepherd
> this process for the last 3 years, find to be crossing the border
> between uninformed speculation and assertions that I would have to take
> personal affront at.

Harald,

I certainly meant no insult to your efforts to shepherd an IPR group with a
*flawed charter* [1] to a conclusion with which I disagree. You and I
discussed this many times in-channel and back-channel, and you remember my
frustrations and my sympathy for your position then and now. 

Indeed, we just wasted another thread arguing about the nonsensical
distinction between code and text and again heard some people assert it is
somehow relevant to the goal of pushing the IETF brand and seeking
consistency on standards. 

The proposed IETF IPR policy allows the public to modify the code present in
IETF specifications but not to use that same specification to create
modified text to document that modified code! Does anyone here honestly
believe this is justified?

You admit: The working group took no vote. Nobody ever does in IETF. It is
thus possible for a small group of people who have the stomach to attend to
boring IPR discussions to come to an irrational conclusion. 

Since there was never a vote, I retain the right to repeat my concerns.
You'll notice I've not tried to dominate this thread, but I was invited to
comment once again--and I did.

-1.

/Larry

[1] Failure to address patents; failure to identify the goals for IETF of a
revised copyright policy; failure to weigh benefits and costs to the public
of various alternatives.

P.S. I moved this back to [email-masked]. Even though some people there find
these battles over legal issues boring and distracting, this policy is the
guts of why we're here. It should be the entire organization that debates
the charter and results of a policy working group, not the working group
itself.

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Wednesday, September 24, 2008 10:22 PM
> To: [email-masked]
> Cc: [email-masked]
> Lawrence Rosen wrote:
> > Ted Hardie wrote:
> >> Just to forestall Jorge spending some of his valuable time on this,
> >> I note that I'm not confused about this point--I was talking about
> cases
> >> where SDOs wished to re-publish (modified) IETF text within their own
> >> specs.
> >> This does not mean that they that they write it down and say
> >> "here is the text from RFC NNNN"; it means that they want to take
> >> the text, change it, and re-publish it.
> >>
> >> Allowing someone to say no to that is something the working group has
> >> said it wants to retain.
> >>
> >
> > I don't believe you can point to a vote anywhere in the IPR WG on that
> exact
> > point. Instead, you and others on the committee moved the discussion
> into
> > the misleading topic of code vs. text, and pretended that there was some
> > difference important to you.
> Larry, that is your claim.
> I don't dispute the claim that we haven't taken a vote, because the IETF
> does not vote.
> But I will assert two things:
> 
> - The discussion of permitting change to text was extensive and repeated.
> - The consensus of the working group was the compromise position now
> documented.
> 
> I assert that if you want to claim that either of these two statements
> are false, YOU back it up with evidence. As it stands, you are making
> statements that I personally, as the WG chair who's tried to shepherd
> this process for the last 3 years, find to be crossing the border
> between uninformed speculation and assertions that I would have to take
> personal affront at.
> 
> Some breadcrumbs from the archives - both the meeting minutes, the
> ticket server and the email archives are online, and you should be able
> to find them easily to verify:
> 
> The issue tracker shows #1169: "Modified excerpts", with the first text
> "Should modified versions of excerpts from non-code text be permitted?".
> 
> https://rt.psg.com/Ticket/Display.html?id=1169
> 
> The resolution, as of November 13, 2007 (I was lame in my tracker
> updates), says "Resolved as of Chicago (not)".
> 
> The July 2007 minutes of the physical meeting in Chicago show:
> 
> Consensus in room that the other issues have been resolved: #1166,
> 1167, 1168, 1169, 1175, 1199, 1237, 1246, 1337, 1400
> 
> http://www.ietf.org/proceedings/07jul/minutes/ipr.txt
> 
> My archive search shows that this occurs in multiple messages to the list:
> June 27, 2006, "Ticket status, June 27, 2006":
> 
> 
> #1169 Modified excerpts
>    Consensus that modifications to make use of code in implementations
> are OK.
>    No consensus on modifications to non-code.
>    Not clear if consensus exists on reuse of code for other purposes
> than standards implementation
> 
> March 27, 2007, "DRAFT minutes from Prague IPR meeting":
> 
> III - matching issues to resolutions
>   Harald reviewed issues from issues list and the resolutions
> .......
>     1169 Modified excerpts
>         Resolution: Permitted for code, not permitted for non-code

---

From: "Powers Chuck-RXCP20" <[email-masked]>
Date: Thu, 25 Sep 2008 13:21:57 -0400

My answer to Larry's question - Yes.

Regards, 
Chuck 
------------- 
Chuck Powers, 
Motorola, Inc 
phone: 512-427-7261
mobile: 512-576-0008

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lawrence Rosen
> Sent: Thursday, September 25, 2008 12:14 PM
> To: 'Harald Alvestrand'; [email-masked]
> Cc: [email-masked]
> > between uninformed speculation and assertions that I would have to 
> > take personal affront at.
> 
> 
> Harald,
> 
> I certainly meant no insult to your efforts to shepherd an 
> IPR group with a *flawed charter* [1] to a conclusion with 
> which I disagree. You and I discussed this many times 
> in-channel and back-channel, and you remember my frustrations 
> and my sympathy for your position then and now. 
> 
> Indeed, we just wasted another thread arguing about the 
> nonsensical distinction between code and text and again heard 
> some people assert it is somehow relevant to the goal of 
> pushing the IETF brand and seeking consistency on standards. 
> 
> The proposed IETF IPR policy allows the public to modify the 
> code present in IETF specifications but not to use that same 
> specification to create modified text to document that 
> modified code! Does anyone here honestly believe this is justified?
> 
> You admit: The working group took no vote. Nobody ever does 
> in IETF. It is thus possible for a small group of people who 
> have the stomach to attend to boring IPR discussions to come 
> to an irrational conclusion. 
> 
> You'll notice I've not tried to dominate this thread, but I 
> was invited to comment once again--and I did.
> 
> -1.
> 
> /Larry
> 
> [1] Failure to address patents; failure to identify the goals 
> for IETF of a revised copyright policy; failure to weigh 
> benefits and costs to the public of various alternatives.
> 
> P.S. I moved this back to [email-masked]. Even though some 
> people there find these battles over legal issues boring and 
> distracting, this policy is the guts of why we're here. It 
> should be the entire organization that debates the charter 
> and results of a policy working group, not the working group itself.
> 
> 
> 
> 
> > >> where SDOs wished to re-publish (modified) IETF text 
> within their 
> > >> own specs.
> > >> This does not mean that they that they write it down and 
> say "here 
> > >> is the text from RFC NNNN"; it means that they want to take the 
> > >> text, change it, and re-publish it.
> > >>
> > >> Allowing someone to say no to that is something the 
> working group 
> > >> has said it wants to retain.
> > >>
> > >
> > > the misleading topic of code vs. text, and pretended that 
> there was 
> > > some difference important to you.
> > I don't dispute the claim that we haven't taken a vote, because the 
> > IETF does not vote.
> > between uninformed speculation and assertions that I would have to 
> > take personal affront at.
> > 
> > ticket server and the email archives are online, and you should be 
> > able to find them easily to verify:
> > 
> > The issue tracker shows #1169: "Modified excerpts", with the first 
> > text "Should modified versions of excerpts from non-code 
> text be permitted?".
> > 
> >   Harald reviewed issues from issues list and the 
> resolutions .......
> >     1169 Modified excerpts
> Ipr-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipr-wg
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Sep 2008 10:40:24 -0700

At 10:13 AM -0700 9/25/08, Lawrence Rosen wrote:
><snip>

>believe this is justified?

I'll be the existence proof on this one:  I believe it is justified.  The
reasons for it have been discussed at length and a conclusion based
on rough consensus has been reached. 

>boring IPR discussions to come to an irrational conclusion.

That conclusion seems at this point to have been supported by the
rough consensus judged of the IETF Last Call and the deliberations of the
IESG. I agree that many folks run pounding from the room when these
discussions occur, but the rough consensus of those who care
seems to be how we do things in general around here.  I also
agree that the discussions are often boring, often frustrating,
and I believe everyone involved will be happier when the WG closes
down.

Rough consensus is not voting, and the ways it works are often
troublesome on matters of principle, because they don't admit
of the same kinds of compromise that engineering trade-offs
do.  But voting in an organization with no defined membership
would be far worse here, as the ballot-stuffing campaigns would
be damaging on even more levels.

			regards,
				Ted

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 25 Sep 2008 12:02:11 -0600

> on rough consensus has been reached. 

Ted explained to me off-list why he believes this policy is justified,
and I now understand why he believes that. I still think that the attack
(other SDOs palming off modified IETF specifications as canonical) is
not as threatening as others think it is (and in general I would prefer
to use less heavy-handed methods), but they have more experience than I
do with this particular attack, so for what it's worth I have decided to
defer to them on this matter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/