Subject: Discussion of Separation of parts

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Dec 2005 20:00:17 -0500

I have looked over Simon's latest proposal for wording for a license.
I have read the reasons proposed for requiring the right to modify the RFC 
Text.

I find them much less than persuasive.
To paraphrase John's point, it is not the job of the IETF to write man 
pages, source code comments, or teaching materials.  There are lots of 
people who do that.  It is not necessary, in order to ensure that 
implementations of the standard are interoperable, that we provide such 
text for arbitrary modification.  It is not even clear to me whether such 
permission would be  more helpful or more harmful on balance.

I believe that the wording is such that teachers can use the RFC in whole 
as a teaching tool.  And if we separate the code components, they can use 
those code components in class assignments, experiments, or anything else.

I am not all that happy with allowing arbitrary modification to the code 
components.  But I have become convinced (largely by Sam's patient 
explaining) that we need to allow that.
I hope we can come up with some sort of warning that not only makes clear 
that such modifications are not the RFC, but that making such modifications 
is a risky thing to do and should only be undertaken with good 
reason.  (That is not a matter of legalities.  The legalities need to 
permit the changes.)

But that does not lead me to concluding the text change permission is 
necessary.

Yours,
Joel M. Halpern

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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Dec 2005 10:58:28 +0100

"Joel M. Halpern" <[email-masked]> writes:

> I have read the reasons proposed for requiring the right to modify the
> RFC Text.
>

We haven't discussed this approach publicly for more than a few days.

I agree that it may be that the reasons presented so far are less
persuasive.

Even so, I believe making the text compatible with other licenses is
as important as making the license on the code compatible.  Making the
license compatible with the licenses used in Debian or FreeBSD lead to
greater re-use of the text, and ultimately faster and wider adoption
of IETF standards.

> implementations of the standard are interoperable, that we provide
> such text for arbitrary modification.  It is not even clear to me
> whether such permission would be  more helpful or more harmful on
> balance.

I believe this argument is flawed.  Searching only for what is
"necessary" will lead you in the wrong direction.  There is nothing
that is strictly "necessary" at all.  There are other people and
organization that will standardize things if the IETF doesn't.  The
IETF isn't "required" to do anything, and opening up the license on
code is as much "required" as opening up the license on "text".

My argument is that if the IETF provide RFCs under a license that is
compatible with free software, it will further the goals of the IETF,
as it would allow RFCs to be more widely adapted and used.

If the RFCs cannot be adapted by implementers, adoption of IETF
standards will be slower because someone else will have to write text
that goes with the implementation.  I don't see how this would be in
the interests of the IETF.

The only fear with my approached that has been expressed seem to be
the fear of fake RFCs.  I agree we must solve it.  We have been
discussing several ways to handle that concern.  I think we should
concentrate on solving the problem with fake RFCs so that most people
are satisfied.

> I believe that the wording is such that teachers can use the RFC in
> whole as a teaching tool.  And if we separate the code components,
> they can use those code components in class assignments, experiments,
> or anything else.

The example I got was that the teacher would modify the RFC and
include it in a exercise for students.  It could to implement it, or
to identify what problem the modification leads to, or to study if the
protocol would become better with the modification.  It sounds
conceivable that some protocol improvement have started out as
"what-if" experiments.  Being able to redistribute that course
material is important.  I don't see how the current wording permit
anything like this.

> I am not all that happy with allowing arbitrary modification to the
> code components.  But I have become convinced (largely by Sam's
> patient explaining) that we need to allow that.

Good.

> I hope we can come up with some sort of warning that not only makes
> clear that such modifications are not the RFC, but that making such
> modifications is a risky thing to do and should only be undertaken
> with good reason.  (That is not a matter of legalities.  The
> legalities need to permit the changes.)

Agreed.

Thanks,
Simon

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Dec 2005 07:39:38 -0600

I would like to take the "teachers can use the RFC in whole as a teaching 
tool" completely off the table. This is not the problem that people are 
worried about.

Can we at least think about text that would say that use of modified RFC 
text at an educational institution for teaching purposes would be OK, while 
use of modified RFC text by others is not?

Although it was no model of simplicity, I note that early Unix licenses were 
not the same for UCB as they were for (to name one, that I was familiar 
with) Northern Telecom, because Bell Labs assumed that what UCB was going to 
do with the license was different than what Northern Telecom was going to do 
with the license.

If a modified RFC, distributed only as class material to other educational 
institutions for use as class material, becomes a significant source of 
broken interoperability in the Internet, we have a lot more problems than 
open-source compatibility to worry about.

And, if this is a bad idea for the usual IPR reasons that I don't know 
about, I'll let you guys continue to have fun.

Thanks,

Spencer

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 14 Dec 2005 09:59:24 -0500

> as it would allow RFCs to be more widely adapted and used. 

I agree that making our license compatible with free software licenses
might encourage wide-spread use of the contents of RFCs, and that may
be a useful goal for the IETF.

However, the primary goal of the IETF is to enable and promote the
standardization of technologies used in the Internet. 

Giving up change control of the specifications of the standards to
gain compatibility with free software licenses, is inconsistent with
the primary goal of the IETF.

David Harrington
[email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Dec 2005 16:27:22 +0100

Agreed.

> standardization of technologies used in the Internet. 

By RFC 3935, the mission is:

   The mission of the IETF is to produce high quality, relevant
   technical and engineering documents that influence the way people
   design, use, and manage the Internet in such a way as to make the
   Internet work better.  These documents include protocol standards,
   best current practices, and informational documents of various kinds.

> the primary goal of the IETF.

I think that is inaccurate, for several reasons.

First, I'm not arguing for giving up change control.  Perhaps we have
different interpretations of what "change control" means.  With my
license, the IETF can still change their specifications, and it
control its own version of it.

Secondly, the IETF's achievements are not belittled by giving people
the right to adapt RFCs in their implementation.  You seem to imply
that.

People have been doing what would be permitted by my license earlier,
look at the getaddrinfo (etc) man pages in FreeBSD or Solaris, or RFC
text excerpts in source code in many successful implementations.  I
believe this helped the IETF effort.

By releasing material that is easy to incorporate in free
implementation, you do "influence the way people design, use, and
manage the Internet" in a way that I believe make the Internet better.

Finally, I don't see what is inconsistent between the goal of making a
better Internet and gaining compatibility with free software.  Large
parts of the Internet has always been run by free software.  I believe
the efforts are linked.

Thanks,
Simon

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Dec 2005 10:44:02 -0600

Warning. Not only is this my second posting on IPR today ("signs of the
approaching apocalypse"), it's a step on the road to an "is not/is too"
thread (<evil grin> and these are only on-topic on [email-masked] </evil
grin>).

> control its own version of it.

I am almost sure that people on this list have different interpretations of
what "change control" means.

The best argument I've seen presented for allowing *changed* RFC text to be
generally distributed without restriction is "when an error in an RFC is
discovered, and someone has to distributed documentation with the correction
before official errata/revised version of text is available".

Given that we have an entire working group (TCPM) chartered with a primary
focus of figuring out what TCP even *IS* (see end-to-end list archives for
pointers), I am not excited by the possibility of having additional
nearly-the-same versions of the specifications floating around various
communities. IMO, we are not very far from this situation with SIP.

The way to solve this problem is not by allowing changed RFC text to be
generally distributed without restriction. It might be lovely to recommend a
way of identifying *suspected* that *have been identified to the IETF for
correction*, but the way to solve the problem is by figuring out a way to
update official specifications in less than eons of time.

... which probably should be a followup on Techspec ...

Spencer

---

From: Ted Hardie <[email-masked]>
Date: Wed, 14 Dec 2005 10:58:57 -0800

>as it would allow RFCs to be more widely adapted and used.

Simon,
	What people are saying, fairly strongly, is that the
goal of the IETF is to enhance interoperability.  We do that by
creating specifications that are written so that anyone implementing
the spec knows that other implementations of the spec will interoperate.
We want to be able to distribute our specifications widely, as that
fosters interoperability.
	But that distribution needs to retain the characteristic
that what is distributed still results in an interoperable implementation.
In the past we've said that you can change the human language (translation)
and form (convert to pdf, print, etc.), since the result is still an interoperable
spec.  I agree with you that an excerpt either was or should be included in
the set of distributions, since that can be valuable in explicating an
implementation or creating a manual for implementors.
	But changing the text so that the specification of what to do
changes is not acceptable.  That does not guarantee interoperability of the
resulting implementations or even necessarily aim for it. 
	One of the issues your facing is that many free software licenses
presume forking is an acceptable and appropriate use of the software; and
for many, many cases it is.  But achieving that through forking a standard
isn't an appropriate use of the specification even in the case where forking
the software built on the standard would be.  It goes against the
aim of the standard, to create a pool of interoperable implementations. 
Forking the software aware from the standard merely results in an
implementation that does not choose to follow the spec.  Forking the
spec results in confusion in how to achive the goal of interoperability.
That's contrary to the IETF's goals and methods.
	Yes, the IETF could change into an organization that used other
means to achieve interoperability or into one where forking of the specifications
was a goal.  But I do not believe that it is in the charter of this working group
to take on that change, and I oppose putting it into the charter of this working
group.  That would be a massive change to the fundamental character of
the IETF, and agreement to take it on should go through the full process
of IETF review.  I would agree to your taking that question to the full
community, but, in the spirit of full disclosure, I will tell you that I would
almost certainly oppose it there.
	For those unsure of this point, I am speaking personally and not for
Qualcomm, the IESG, or any other organization.
				regards,
					Ted Hardie

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 14 Dec 2005 14:31:04 -0500

Ted,

Thank you for spelling out these concerns in a clearer and more
detailed manner than I was able to do.

David Harrington
[email-masked]  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ted Hardie
> Sent: Wednesday, December 14, 2005 1:59 PM
> To: Simon Josefsson; Joel M. Halpern
> Cc: [email-masked]
> Subject: Re: Discussion of Separation of parts
>

---

From: "todd glassey" <[email-masked]>
Date: Thu, 15 Dec 2005 08:36:55 -0800

Guys - Ted's commentary crystallizes the issue here - the IETF is about
standardization for interoperability and it has a formal process and set of
methods to achieve that.  Thus, there seems to be a misconception at play
here and that is that there is any reason to hand over to the IETF the
"rights to provide value for others" outside of what is needed to advance
standards and interoperability of protocols. By this I mean  people,
entities, submit IP to the IETF for the purpose of creating standardization
and for no other reason.

The intent in the original IETF was to address those and only those needs.
Now that vision seems to have expanded in an effort to market the IETF's
brand. The problem is that then the IETF has to protect its brand or it will
lose it and it will have to deal with compensatory value and on-going
valuations of IP and that is something so far beyond this IETF its not
funny... In fact to date the IETF has not stopped anyone who republished its
works in any form that I am aware of and this is a key failing of the IETF
in its contractual relationship with those who it partnered with in creating
the world's wealth of Internet IP's...

In fact it seems that now its even sheik to publish the IETF works as part
of one's own commercial support documents, and a number of vendors have
found that they gain value in their documentation kits by filling them with
the wealth of knowledge that is available  from the IETF as a SDO. The issue
is simply what that has to do with the standardization process - other than
brand-marketing value for the IETF brand?

My feeling is that since those individuals efforts are 100% self serving,
and that since that same actual media is often available at the submitter's
own website or any number of the official and unofficial mirrors of the IETF
around the web, the focal point of this question as to why any Commercial
Vendor needs to publish anything of the IETF's in its document kit becomes
one of compensatory value and the basis of the IETF's incentive for
submission.

Personally I feel that there is no way around that any commercial entity's
use of the IETF publishing outside of specific initiatives that are current
and they (those entities) are formally and actively involved in, because any
other use becomes commercial  since it is not a part of the IETF's
standardization process itself.

As noted above, unfortunately this same realization of misstated or ongoing
value also brings up the unique question of an ongoing IP's ownership, its
actual $$$ worth and any potential tax credits that the conveyance of this
thing of amazing value (the protocol) may have too... Buts those are other
issues yet to be discovered by this community.

More inline below

Todd

----- Original Message ----- 
From: "Ted Hardie" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>; "Joel M. Halpern"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 14, 2005 10:58 AM
Subject: Re: Discussion of Separation of parts

> goal of the IETF is to enhance interoperability.

100%

> We do that by

This I disagree with,  my feeling is that we do that in a vetting process
inside of the WG or as an ancillary unit to a WG itself. Those people 'vet'
the proposed protocol which was published for their reference as an RFC.

> fosters interoperability.

I disagree. My feeling is that what it fosters is commercial worth for the
ability to republish those documents if you are not actively involved in the
IETF's processes or standardization process and nothing else.

> that what is distributed still results in an interoperable implementation.

I.e. there is a compliance requirement for anyone building a protocol
version of something. But those people would be working with the IETF and
would have access to its official sites so why do they need yet another
uncertified copy of something?

[Note: By the way - if your looking for value and a way to fund the IETF -
Why not just have the IETF run a "Registered Protocol Interoperability
Service" for IETF protocol developers. This would be an online website
attesting to those interoperability tests and what they were for any given
protocol effort. The IETF could even charge for this as a commercial
service...]

> and form (convert to PDF, print, etc.), since the result is still an
interoperable
> implementation or creating a manual for implementers.

But this is specific to derivative or excerpt republishing rights and those
uses are commercial since neither of them consists of ongoing genesis of the
original initiate WITHIN the IETF. The use of standards materials for
standards purposes outside the IETF means that those works the IETF would
not have control over and so could not attest to any issues of
interoperability thus violating its charter and purpose yet again.

> resulting implementations or even necessarily aim for it.

Again - the value of an Official IETF interoperability test information web
site service could fund the operations of the entire IETF... and allow ISOC
to get the arms length it needs by spinning the IETF off as a corporate
entity of its own.

> presume forking is an acceptable and appropriate use of the software;

Not for the purposes of expanding interoperability though.

> and
> the software built on the standard would be.

AMEN.

> It goes against the

Which again is the only reason that anyone would submit IP to the IETF.

> spec results in confusion in how to achieve the goal of interoperability.

A use guideline requirement in the standards process workflow and milestones
eliminates this short-falling

> was a goal.

You mean that "the New IETF" that is being propsoed here could change. by
the way, those agreements with those people per previous instances of the
"IETF rules of the road" are binding and continue to be no matter what
happens moving forward. This is a real issue to since it opens that the new
IETF has to be careful not to be hostile to those submitting works or the
benefits that it provides to those individuals relative to what it did in
the past with many of the same players i.e. the IETF needs to be consistent
with those benefits previously give out.

> But I do not believe that it is in the charter of this working group
> group.

Then I fear that this Working Group's work is broken. You cannot change the
licensing models that the IP is forced to be submitted under without
addressing what you are giving back to the people that submit it. The issues
of ongoing value and understanding the value of a 'donation to the IETF' is
going to become very important since it likely has tax implications and has
to be reported as such. This would change how organizations deal with 41(d)
of the IRC and how they write down their development costs of their
standards initiatives I bet, and I would also venture to bet that no one
considered that before this effort to give the IETF commercial clout was
undertaken.

> That would be a massive change to the fundamental character of
> of IETF review.

I agree with that, and further that want to point out that this may not go
far enough and that ANYTHING that happens in IPR-WG is only a recommendation
until formally adopted by the IETF membership as a whole. My point is that
just publishing a RFC  or getting this WG Chair to approve your document for
publication doesn't make it IETF law - that's ridiculous.

> I would agree to your taking that question to the full

I dont think so - in fact I would propose that the IETF itself is in need of
an overhaul and that the standards practice itself is what needs to be
revisited.

Look - no one submits ANYTHING to give it away to the IETF. What people do
here is contract with the IETF to allow them access to a pool of Vetter's
who are technically astute and who have the ability to review and provide
guidance or partnering in the advancement and clarifying of those design
initiatives. They (those submitting IP) are not promised that the vetting
pool will want to spend time on their project, but that is something that
the pool has to decide on its own. Further as part of that decision process,
the pool may create a 'core team' of parties either as part of the WG or
adjacent to it.  But whether the project is vetted by 3 people or 30 people,
if it makes the milestones it should achieve the status of Internet
Standard.

So look - How about this - how about we rewrite the standards process
workflow to a new a simple, no stress, no fuss or muss standards process
that uses a set of milestone templates that are predefined. These would
define the types of vetting required, the documents required, and the
interoperability milestones or achievements that any initiative needs to
attain prior to being awarded the status as an IETF Internet Standard.