On Sat, 20 Oct 2007, Lawrence Rosen wrote:
> Brian Carpenter wrote:
> > ... so that the
> > goal of 100% unencumbered standards is unrealistic.
>...
> But we're talking here about IETF standards, specifications that are
> prepared cooperatively and for free by talented individuals, companies and
For 'free' ??? I expect you'll find that that for the majority of IETF
partcipants, participation is part of what they do for their employers.
Meeting fees and expenses are re-imbursed, etc.
That is merely informed self interest.
> countries around the world. These specifications are intended for
> implementation everywhere to facilitate communications among us all. None of
> us want patent surprises when we implement IETF specifications. Everyone
> expects IETF to take reasonable steps, consistent with its fundamental
> technical mission, to de-mine the patent landscape so that anyone can
> implement our worldwide specifications in products of all types.
Actually, there is GREAT value in having a widely used protocol well
documented, even if it is encumbered by IPR restrictions. I personally
have no objection to having the IETF publish RFCs which depend in whole or
part on encumbered technologies as long as those restrictions are
documented in the RFC.
As a matter of courtesy, the existance of such encumberances should be
revealed when known to an individual associated with the process of
submitting the information to any group associated with the IETF. We need
to be careful however to make any IPR decisions based the merits of the
technical issues and NOT based on our frustration that notification wasn't
timely.
I consider it a given that the best the IETF can achieve is to recognize
IPR known to participants in the IETF process. Given the nature of patent
and copyright processes, there is no way to insure that a seemingly new
idea conceived by an IETF working group isn't already encumbered.
It is my observation that the IETF tends to operate in two modes:
a. Documenting or revising the documentation of existing protocols
b. Designing protocols (or improvements) to solve previously unresolved
problems
In mode 'a', documenation may be independant submissions as well as
organized activities of the IETF community. To publish an independant
submission requires some attention from the community, the RFC editor,
etc. The question is whether publication will contribute to the community.
Knowning how a totally encumbered protocol works, may facilitate the
design of related protocols or simply help network engineers keep their
portion of the Internet operational. If so, the publication effort is
probably justified.
The remaining mode 'a' activity, as the organized work product of the
IETF, likely a WG, should have IPR handled as in mode 'b'. The addition of
IPR encumbered technology to a protocol should be a decision based on
technical merits. It makes no sense to determine before specific
technology has been identified for consideration that encumbered
technology can't be considered. I have seen enough disagreements within
the IETF as to what is the best technology that I know that comparison of
techologies won't be easy when there is no known encumberance. But I would
hope that a good technical design will prevale. In the end, the
Internet wide operating cost associated with using less than optimal
technology shouldn't exceed the expected costs associated with use of
encumbered technology.
It should be clear that all known encumberances MUST be documented in an
RFC which utilizes the technology. A participant in the IETF process
should never bring technology to the IETF they know or believe to be
encumbered without revealing those encumberances. Furthermore, they
should never advocate adoption of technology from which they will directly
or indirectly benefit in come tangible way. If an individual is aware
of technology encumberances which they can't reveal, they should drop out
of the related working groups or other IETF organized discussions.
It really isn't socially acceptable to entrap IETF participants with
enticing techology whose encumberances aren't revealed.
David Morris
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf