Ian Peter advised:
..."
I suggest the appropriate role for IETF is to examine the
technical standards issues, and make a call on that, if necessary
with a "subject to clarification of licensing" condition.
...
I'd suggest get the technical
call right,and then look to an alliance of some sort to clarify
the issues that are outside of IETF's scope and expertise.
Yes and/but part of the technical task is to architect the drafts in this space.
It is a right-and-proper part of architecture to take account of all relevant
factors which could impact the deployment and use of the technology - including
legal and change management factors.
I believe that Meng et.al. are working on candidate-drafts which are 'modular',
in that, to a certain extent, implementers can select one or two 'core'
components, and then a number of optional extras, providing discretionary
functionality.
I also understand that the algorithms subject to the legal claims appear,
architecturally, to be capable of being placed in one of these optional
'modules'.
If there is no satisfactory resolution to all the legal questions in the next
few days (hours?) then I, for one, would recommend proceeding in this modular
way, so that those who wish to start implementations without legal uncertainties
can do so - omitting that part of the technical functionality supplied by that
module.
Then the ongoing legal/PR/emotional debates can take place around that module
alone, leaving the rest of this urgently-needed functionality free (in all
senses of the word) to be implemented.
In the long term, either a royalty-free arrangement is agreed for that module,
or people can decide whether or not they want to pay for that functionality.
But the key objective now must surely be to decouple the engineering and legal
proceses so that legally-unencumbered technical implementation can start.
This decoupling is not done by ignoring or delegating the legal uncertainties,
but by embracing them and treating them as part of the technical 'problem
space'.
The aim of the technical architecture should be to ensure that:
a) Only one module (i.e. only one Internet-Draft) is subject to the legal
claims,
b) That module should not contain any claim-free functionality which could be
placed elsewhere,
b) Use of that module for the purposes addressed by MARID is 'OPTIONAL' (c.f.
RFC2119) and
c) No other modules are functionally-dependent upon that module.
I think it would be appropriate to design other modules (including the 'core'
ones) so that they provide features required by that optional module (e.g. the
'core' module defining the DNS-hosted SPF/MARID Record semantics), so long as
there is <em>absolutely no question</em> of these other modules thereby becoming
subject to the legal claims.
The above would be, IMHO, an acceptable, technically-valid (albeit
legally-influenced) meeting of the objectives of "Unified" SPF.
Were I managing the legal interaction this week, I would be concentrating on
getting clear statements from the lawyers on the 'scope and extent' of the claim
(i.e. on the _boundaries_ of the claimed functionalities).
I would then attempt to define a technically/architecturally valid way of
ring-fencing this contaminated space - as per the criteria listed above.
If there is no architectural way of preventing the legal contamination of other
modules, or if the technology subject to the legal claims should be found to be
_essential_ to the purposes of MARID, then IETF/MARID has a very simple, very
'interesting', very visible decision to make this week.
HTH
Chris Haynes