At 11:57 AM -0700 10/23/07, Hallam-Baker, Phillip wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C815A6.947239F7" > >The objective here is to constrain the amount of unproductive argument by limiting the number of possible end states. > >In particular I would like to tip the scales so that if we have proposals A and B where A is unemcumbered but B is not that proposal B has to demonstrate a remarkably higher value in order to be chosen over A. > I believe it is fairer to recognize that in your example proposal B is known to have been patented where A is not. There is always the chance that someone will turn out to have secured rights which they later claim read on A. In that case it may actually be better to choose B, knowing that the license offered works for the development and deployment community than to choose A. In other words, a "defensive" patent declaration by someone whose license works for the appropriate community may actually add security. It doesn't completely remove the risk that someone will turn up with other rights, but it really can help. The reason that the "wiggle room" argument is problematic is that the development and deployment communities for different areas of standards work in the IETF are different. A license offered by company C for work in routing may work well, where the exact same license by organization M for work at the apps layer may not. Allowing the folks who actually plan to write the code to indicate where there are problems and where not may be better than trying to get a few sizes to fit all. Several people have already sent pointers to Simon's draft, which describes how to get to a particular outcome; I think that is a good thrust. With that and similar documents in hand, that community can have blueprints for how to achieve particular goals. Those will get used, and that will make things easier. But that's very different from trying to set the scales for working groups in advance. That will just get into hair-splitting over whether something meets a vague test for "remarkably higher", which is even harder to get argued. "I can and will implement this, with the offered license" is a much easier statement to evaluate than "This meets the 3 tests offered in RFC XXXX for "remarkably higher" value because of N, M, and O". Speaking only for my non-lawyer self, Ted _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf