In
<C6DDA43B91BFDA49AA2F1E473732113E010BE92F(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
4) Proposals must have IP licensing terms that allow for use in both
commercial and GPLed MTAs.
Again, the PRA RFC has IPR claims. [...]
If, indeed, the PRA license is incompatible, I do not think we should
advance it as an RFC.
I can't find any statement in draft-ietf-marid-submitter-01.txt that
would support this claim.
Indeed, the submitter draft has nothing to support the claim that the
PRA has a license. It is the marid-core document, where the PRA
algorithm is described, that supports that claim.
Note that to go forward the only requirement is code, and that is strictly
speaking only required to go to draft.
*sigh*
Let me quote RFC2026 yet again:
4.1.1 Proposed Standard
[snip]
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation.
The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.
Now, whether the IESG considers the SenderID to "have significant
operational impact on the Internet" or not, I can't say. What I can
say is what I think, and I think it does. (Note where I said "I
think" in the stuff you quoted above.)
In fact, I will go so far as to say that if there is no working code
and no testing by several independant organizations, I will argue
against advancing the SenderID proposal both during the WG last call
and during the IETF last call.
I realize that this would create a risk that the SenderID proposal
will not advance. However I consider that slightly more acceptable
than the risks associated with advancing a completely untested
proposal that has such a huge impact on such an important part of the
internet.
Mind you, I would *much* prefer to simply have a well tested RFC. I
would *much* prefer not having a messy "discussion" during the last
call periods.
There has never been a requirement
for open source code, let alone open source code that is compatible with
any given license.
Nice red herring there.
I have never said that the code must be open source.
However RFC3668 says that a working group can consider the IPR issues
and that we should prefer technologies that do not have IPR problems.
RFC3668 is a good document, I recommend people read it.
Again, I think that any proposals that will prevent any significant
MTAs/spam filters from implementing this technology, whether the are
GPLed, commercial, or because the developer wears blue shoes, is
simply not acceptable.
The fact that the SenderID proposal has been allowed by the co-chairs
to advance this far without making the required RFC3668 disclosures is
troublesome. I really don't want to see the "discussions" during the
IETF last call that will happen if MARID advances a proposal that is
incompatible with the GPL.
If these IPR issues can't be resolved soon, I suggest that this
working group start considering other technologies that do not have
such problems.
It should be possible to write code to the spec and release it as public
domain (which is in my view the only real open source license). If you
can do that you can meet any other license term.
I agree, it *should* possible, but the SenderID requires a license
from MicroSoft.
We have already had enough messy "discussions" here. Let's not repeat
the fun that was had with RSA. For people who like the SenderID
proposal, I highly recommend taking the time to address these
concerns.
-wayne