Subject: Re: A simpler idea

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 May 2006 11:38:36 +0200

Ted Hardie <[email-masked]> writes:

> At 10:54 AM +0200 4/28/06, Simon Josefsson wrote:
>>
>>Con:
>>
>>* Some people are afraid of fake RFCs.  I don't think this is a good
>>  enough argument, the costs of copyright transfers or regular updates
>>  of the IETF license are, I believe, larger than the risk of fake
>>  RFCs.
>
> This is only part of the risk.  If we release specs into the wild
> with this license, there is not just risk that someone fakes RFC
> XXXX, there is a much larger risk that someone takes the text and
> uses it as the basis for a specification that does not interoperate
> with the IETF spec.  It moves us to a model, in other words, where
> forking is a generally permitted result.  Getting to consensus is
> hard work, and forking is relatively easy (especially if you start
> from a finished work).  I believe that this will result in a
> situation in which forking is a common result.

I'm less sure of that.  Forking is permitted by free software
licenses, yet the large free software projects are rarely successfully
forked, and when they are forked it often leads to something that is
useful.  Unsuccessful forks may occur, but the confusion from those
are, in my experience, limited (since few know about the fork) and
temporary (when interested people learn about the facts).

Also, I argue that having the ability to fork specifications improve
experimentation with protocols.  Eventually, experiments typically end
up as the next version of a particular protocol, and having the
experiments benefit from better documentation simplifies that process.

> We have seen this happen in many ways over the past five years,
> especially in cases in which other SDOs wish to take IETF protocols
> and tweak them slightly to fit architectures which preserve
> specific business models.  After those tweaks, traffic flows commonly
> have to go into back-to-back user agents to transition between
> the Internet protocol and the tweaked protocol.  This introduces
> fragility, delay, and points of control.  Avoiding those situations by
> focusing on interoperability has taken hard work, but there have been
> some successes.  I fear that this license would make it harder to
> succeed at those same efforts in the future.

That situation sounds bad, but I don't think restrictive copying
conditions is the solution to it.  It sounds as if someone should hit
those SDOs with a clue-stick instead.

> If you want a simpler idea, it is this:  The IETF should not be working on
> *anything* for which Internet-scale interoperability is not a key goal.

I've thought about this for a few days, and it is interesting idea.  I
like the idea, but I see one problem, and I'm not sure if it can be
resolved easily:

Many things that are brought to the IETF are candidates for protocols
that will be used on Internet-scale and where interoperability is a
key goal.  But many of them will not succeed, and won't get deployed
for various reasons.  Typically it is not clear WHY a protocol hasn't
been deployed.

There are many minor things that contribute to the fact, and sometimes
the things are minor for one set of people but major for another set
of people.  I think that this applies to more or less all protocols,
just in different proportions.  E.g., there is a reason people haven't
deployed DNSSEC, or TLS or whatever.

In this situation, there will be many people working on DNSSEC or TLS
or whatever to improve so it can solve more people's problems.
Interoperability is not a key goal here, the key goal is to solve more
people's problems, and to get a better protocol.  Many people will
work on this in parallel.  Typically only a few will succeed, and
hopefully will bring back the new updated to the IETF for
standardization, and then it becomes a key goal to have
interoperability.

Some of these participants may be other large SDOs.  They may be doing
technically stupid thing, but they are trying.  Most will fail.
Harming these attempts at producing a protocol to solve more people's
problem appear to harm the process of getting a better updated
protocol back to the IETF.  After all, the IETF is made up of all
these people trying to solve problems, and harming them will harm the
IETF.

I'd like to see IETF be the clue-stick here, and pick the good
protocols out of the pool of attempted protocols, and ideally also
explain why the other solutions are sub-optimal.

> For those for which that is a goal, real standards (and avoidance of
> forking) is key.  Anything which can survive the kind of forking I
> predicted above probably shouldn't be done here anyway.  Put the
> spec on a web page, or code on sourceforge, or take it to any number
> of other fora; the IETF does not have or need any monopoly on good
> code or specs. But it does need a clear focus on interoperability.

It may be too narrow to only apply that as the criteria.  I think you
should consider, and promote, the process that have made existing
interoperable protocols happen, and it include incompatible changes at
some steps.  Compare IPv4 to IPv6, the several iterations of mutually
incompatible DNSSEC, etc.  Perhaps, to promote interoperability, you
may have to sacrifice a little to make the process that produce
interoperability work.

Regards,
Simon

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 02 May 2006 11:57:00 +0200

"David B Harrington" <[email-masked]> writes:

> Hi,
>
> While I believe it is important to try to constrain the use of RFCs
> for activities that are supportive of interoperability and standard,
> we need to make sure we don't make it illegal to create running code
> that is a variation of an existing standard; that's how standards get
> improved.
>
> The IETF depends on running code, but the IETF does not develop
> running code, so we need to be sure other people can develop running
> code that can later be brought to the IETF as a contributions to the
> standards process. And it is an economic reality that most running
> code gets developed as a proprietary product feature that vendors can
> sell to recoup their research and development costs. I don't want to
> see us write text here that discourages vendors from doing this.

I agree fully!

> I think the existing approach seems to work fine, and has worked fine
> for years, and wonder why is this WG trying to change this? Is there a
> known problem we are trying to solve?

There are several known problems, see
<http://josefsson.org/bcp78broken/>.

I believe a good-faith company that tweaks an IETF standard to make
the protocol becomes better should be permitted (and encouraged) to
document it in a format that makes it easy to pursue the protocol
within the IETF.  That format is to make as few changes to the
original specification as possible, to simplify review of the
extension.

> I am aware that some free software licenses don't like our license; I
> think thos licenses should be changed to permit official industry
> standards, but that's just my perspective.

You are missing that running code is often released under free
licenses, and that free licenses cannot be made compatible with the
current IETF licensed while preserving the intentions of the free
license.  The current IETF license is incompatible with free software
licenses in many ways.

However, I believe the principles behind the IETF copying conditions
are NOT incompatible with the principles behind free software
licenses.  In fact, I believe they are quite similar.  After all, much
of the code that runs the Internet is (or, for derivatives from
BSD-like software, at some point was) free software.

That's why I argue that we should change the IETF copying conditions
so they better match our principles, and to spend some time to make
sure there aren't legal compatibility issues with free software
licenses.

Regards,
Simon