Re: A simpler idea

[Simon Josefsson <jas at extundo.com>]

Ted Hardie <hardie at qualcomm.com> 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
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg