[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A simpler idea (was: Re: Fair use and case analysis)
I disagree that Fake RFC's are an issue to the extent that Ted is painting
them as, my feeling is that this community is way to small and well
connected for a fake RFC to exist for long and too vitriolic to allow anyone
to get away with that type of offense against the IETF.
And my feeling is that if there was a real issue with Forking as Ted raised,
it would be easy to stop that by just going back to the ideas of the early
IETF... You simply dont allow people the license to produce things that by
their very nature do not interoperate with IETF standards... and for RFC's
you do this by making it a no-no to use a RFC as anything other than a
"Request For Comments". To do this the license would specify the specific
uses that the document in question could be used for rather than the way it
is today.
This limiting of use is easily done with a simple use license that says
that the only allowable use for a RFC is for the solicitation of comments in
an IETF Standards Initiative and that any deriviatives must either insure
interoperability as part of advancing the standard or that a waiver is
issued for the interoperaability requirement by the WG doing the vetting of
the IP, and that as part of that if any protocol is implemented as part of
qualifying this IETF Initiative that it MUST meet the interoperability
standards that are the foundation of the IETF's processes.
Likewise my feeling is that the same is true for Don's response as well, if
the license on the RFC is restricted to being used specifically in the
advancement of the IETF's Standards Process rather than "anything and
everything anyone wants" then this will become a non-issue.
---
However... there is also another concern in the breadth of the license
statements, and it is particular to what rights the IETF is giving away to
people that allow them to build IP of their own based on IETF publications.
Remember that the previous convo's were all about "republishing to foster or
advance a standards initiative", and outside of that there is/are no
right(s) on the table that allow derivative implementation of the physical
IP as a stack or protocol per se.
Todd Glassey
----- Original Message -----
From: "Ted Hardie" <hardie at qualcomm.com>
To: "Simon Josefsson" <jas at extundo.com>; "John C Klensin"
<john-ietf at jck.com>
Cc: "Brian E Carpenter" <brc at zurich.ibm.com>; <ipr-wg at ietf.org>; "Spencer
Dawkins" <spencer at mcsr-labs.org>
Sent: Friday, April 28, 2006 12:34 PM
Subject: Re: A simpler idea (was: Re: Fair use and case analysis)
> 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.
>
> 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.
>
> 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.
> 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. I wish I was certain it still had it.
>
> regards,
> Ted Hardie
>
>
> PS. I am not speaking for anyone else in the text above, including but
not limited to
> other owners of dachshunds, the IESG, the State of California or its
residents,
> or my employer.
>
>
> _______________________________________________
> Ipr-wg mailing list
> Ipr-wg at ietf.org
> https://www1.ietf.org/mailman/listinfo/ipr-wg
_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg