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@xxxxxxxxxxxxx] > Sent: Friday, October 26, 2007 12:12 PM > To: ietf@xxxxxxxx > 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@xxxxxxxxxxxx> > To: "Theodore Tso" <tytso@xxxxxxx>; "Norbert Bollow" <nb@xxxxxxxxx> > Cc: <ietf@xxxxxxxx> > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf