It is not a major change in principle. But it does have some practical changes.
When we chartered KEYPROV I was told that the IPR regime should not be in the
charter, this was not a concern to me there because all the proposals were OK
IPR wise. But I do want to have the option of the forcing function in the
charter as explained. This is standard in OASIS and in W3C there is only one
regime that the WGs can chose.
I do not expect there to be very many charter changes of that type if any. And
if it was going to happen I would expect that it would have already soaked up a
large amount of IESG time.
The point about making the statement in the charter is that if people are going
to commit time and resources they have a right to understand upfront what the
IPR is going to be and for this to only change if there are exceptional
circumstances. When we were doing S/MIME and SSL we all knew about the RSA
patent going in. There were no suprises.
A WG has to recharter to add stuff to the charter, changing the IPR regime is a
much more serious change in my view.
In MARID it was obvious from the start that there was no prospect of an
encumbered technology being adopted. Everyone recognized the fact. The WG came
off the rails because there was not agreement on what the criteria for being
unencumbered were.
Another change I am looking for is for the default assumption going forward to
be that the IETF will manage all the mailing lists for WGs and BOFs and that
these will be automatically archived and contain prominent NOTE WELL
notification in their subscription process.
A final change I would like to see is less scope for thrashing on this topic on
this list :-)
-----Original Message-----
From: Spencer Dawkins [mailto:spencer(_at_)mcsr-labs(_dot_)org]
Sent: Friday, October 26, 2007 12:12 PM
To: ietf(_at_)ietf(_dot_)org
Subject: Re: A priori IPR choices
Hi, Phil,
I'm not seeing anything in your proposal that requires
changes to the IPR procedures in IETF - are you?
I AM seeing something in your proposal that could reasonably
be adopted by specific working groups, and I AM seeing
something that might reasonably be developed into an
Informational RFC(*) (heck, maybe even an ION) saying "some
IETF participants worry about X, so we're explicitly pointing
out that IETF working groups can do Y to reduce the chances
of X happening, and here's how to do Y".
If there's any gap between the tools we have and what you're
suggesting, it's your wish to have this constraint IN THE
WORKING GROUP CHARTER. Is that critical? and if so, is there
any OTHER way to obtain WG consensus and document it, so the
WG doesn't have to keep defending the choice?
I AM thinking that including IPR constraints in the charter
would set off IESG review for charter changes if the WG
changes its mind - I'm not sure that's helpful, and it's
certainly not required today.
Thanks,
Spencer
(*) The IPR working group has developed Informational RFCs
offered as guidance in the past - I'm sure Phil knows about
http://www.ietf.org/rfc/rfc3669.txt, but others may not have
noticed it.
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "Theodore Tso" <tytso(_at_)mit(_dot_)edu>; "Norbert Bollow"
<nb(_at_)bollow(_dot_)ch>
Cc: <ietf(_at_)ietf(_dot_)org>
Sent: Friday, October 26, 2007 9:51 AM
Subject: RE: A priori IPR choices
The reason I would like to be able to put a RANDZ requirement
in a WG charter is that there are certain areas where I would
like to see a working group form, where there is a set of
clearly unencumbered technology that can be used and
alternative technology that is owned by a proprietary concern.
I want a WG to be able to make it clear to such rights
holders from the outset that their technology is going to be
stripped from the documents if they fail to deliver
acceptable access terms before the start of last call.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf