Consensus Call for draft-housley-tls-authz and
maturity of FOSS (e.g., Stallman ... participating
in ietf mailing lists) has brought up again a
process problem that I have been pointing to over
the past 10 years.
IETF functions need to be broken into independent
separate entities with checks and balances.
I mean truely separate entities.
The solution is to revisit the process in favor of
distributing responsibility for the various
aspects of protocol development, rather than
consolidating all these aspects under the umbrella
of a single organization, such as the IETF.
I wrote it all up and posted it right here about
10 years ago. Here we go again.
------
The Free Protocols Foundation
Policies and Procedures
www.FreeProtocols.org
http://www.freeprotocols.org/PLPC/100201
Version 0.5
March 29, 2000
Copyright 2000 Free Protocols Foundation.
Published by:
Free Protocols Foundation
3610 164th place SE
Bellevue, WA 98008 USA
Permission is granted to make and distribute verbatim
copies of this document provided the copyright notice and
this permission notice are preserved on all copies.
Contents
========
1 Introduction
1.1 The Patent Debate
1.2 How Patents Affect Protocols
1.3 Difficulties Relating to Software and
Protocol Patents
1.4 Terminology
1.4.1 Definitions
1.5 About the Free Protocol Processes and
Procedures
1.6 About this Document
2 The Protocol Development Process
2.1 Phases of Development
2.1.1 Initial Protocol Development
2.1.2 Global Parameter Assignment
2.1.3 Protocol Publication
2.1.4 Patent-Free Declarations
2.1.5 Industry Usage
2.1.6 Maintenance and Enhancement
2.1.7 Endorsement by a Standards Body
2.2 Role of the Free Protocols Foundation
2.3 Coordination of Activities
3 The Free Protocols Foundation
3.1 General Philosophy
3.2 Purpose, Activities and Scope
3.3 Other Activities
4 Free Protocol Development Working Groups
5 Patent-Free Declarations
5.1 Author's Declaration
5.2 Working Group Declaration
6 Patents, Copyright and Confidentiality - Policy
Statement
6.1 Policy Statement Principles
6.2 General Policy
6.3 Confidentiality Obligations
6.4 Rights and Permissions of All Contributions
6.5 FPF Role Regarding Free Protocol Specifications
1 Introduction
================
1.1 The Patent Debate
-----------------------
At the time of writing, there is an on-going
debate within the software industry regarding
software patents. Like many others within the
industry, at the Free Protocols Foundation we
regard the historical tradition of patents as
being entirely inappropriate for software.
We consider software patents to have the effect of
inhibiting free and open competition within the
software industry, and to be extremely detrimental
to the industry and the consumer. A complete
discussion of the software patent issue is outside
the scope of this document. For more information
on this subject can be found at various sources,
see [1] or [2].
1.2 How Patents Affect Protocols
----------------------------------
Patents are applied to software, not to protocols.
It is not possible to patent a protocol; in
general only a process or an algorithm can be
patented. However, a protocol may include a
patented algorithm as an integral part of its
specification. In this case, any software
implementation of the protocol requires the use of
patented software. That is, a patented process is
an inherent part of the protocol.
Even if a protocol does not explicitly decree the
use of a specific patented software process, it
may still be the case that any practical
implementation of the protocol requires the use of
patented software components. The protocol could
in principle be implemented in a way which avoids
the use of patented software; in practice,
however, the result would be a significantly
inferior implementation, for example in terms of
efficiency.
In either case, the protocol effectively implies
the use of patented software. We will refer to
any such protocol as a patented protocol. That
is, a patented protocol is any protocol whose
practical implementation requires the use of
patented software components.
We will use the term patent-free protocol, or just
free protocol, to refer to a protocol which is
functionally free from software patents. By
``functionally free from software patents,'' we
mean either that the protocol is truly free from
patents, or if the protocol does imply the use of
patented software, that the patent-holder has
granted non-restrictive rights to include the
patented software components in implementations of
the protocol.
In either case, the result is that the protocol
can be freely implemented and used by anyone,
without encountering significant restrictions.
1.3 Difficulties Relating to Software and
Protocol Patents
-------------------------------------------
Because of the current state of affairs regarding
software patents, it is no longer possible to be
absolutely certain that any particular protocol is
patent-free. Whether or not a new invention or
technology violates any existing patents has
traditionally been determined by means of a
patent-search -- a direct search and examination
of all relevant pre-existing patents. In the case
of a physical technology, this yields a more or
less definitive answer as to whether or not the
technology violates any existing patents.
In the case of software, however, it is not
possible to answer this question with the same
degree of certainty. The basic reason for this
lies in the very high degree of subtlety and
complexity of modern software systems. A software
system may contain hundreds or thousands of
individual software constructs, any one of which
may potentially violate an existing patent.
Furthermore, it is very difficult to establish a
taxonomy of existing software patents. A taxonomy
is required to guide the patent-search process --
the taxonomy defines which patents are ``related''
to the technology under search. Without a
well-defined and meaningful taxonomy, it is not
possible to define an appropriate scope of search.
In other words, a software system may contain a
small universe of software constructs. Meanwhile,
the Patent and Trademark Office has established a
small universe of software patents.
Unfortunately, there is no way to establish with
certainty, that none of the elements of one
universe also reside in the other universe.
To make matters worse, there can be room for
dispute regarding whether or not a particular
software construct violates a particular patent.
The patent-holder may claim that it does, while
the software developer claims that it does not.
If the two parties are unable to come to
agreement, the issue can only be resolved in the
courts.
Finally, because of the delay between a company
filing a patent application and the granting of
the patent by the PTO, it is entirely possible for
a company to conduct a software patent-search with
negative results, only to discover subsequently
that a patent has been granted after-the-fact,
which now places its software in violation.
For all these reasons, it has now become
essentially impossible to establish with certainty
that a particular piece of software is, and will
remain, truly patent-free. Likewise, it has
become impossible to establish with certainty that
a particular protocol is, and will remain,
patent-free.
1.4 Terminology
-----------------
Legal rights such as patents and copyright are
sometimes referred to collectively as
``Intellectual Property Rights.'' Although this
is a very commonly used term, we will avoid using
it in this document.
Along with other authors, we object to the use of
this term on the grounds that it blurs the
distinction between intellectual items and
material ones. The law allows ownership rights to
be asserted with regard to both types of item, and
therefore both may be considered in some sense to
be ``property.'' However, we regard intellectual
entities such as software and protocols to be
fundamentally different in nature to material
items, and worthy of entirely different legal
treatment relating to questions of ownership. For
more discussion about this point, see [3].
Where necessary, we will use explicit terms such
as ``patent,'' or ``copyright,'' to refer to legal
rights relating to intellectual constructs.
1.4.1 Definitions
-------------------
Throughout this document, we will use the
following terms with the meanings indicated:
o Truly Patent-Free Protocol. A protocol that
can be implemented in the form of entirely
patent-free software. A Truly Patent-Free
Protocol contains no limitations whatsoever on
its dissemination and use, and may be freely
implemented by anyone, without restriction.
o Functionally Patent-Free Protocol. A protocol
for which there are either no known software
patent restrictions, or where software patent
restrictions are known to exist,
non-restrictive usage rights have been
obtained from the patent-holder.
o Free Protocol Specification. A protocol that
conforms to the policies and procedures of the
Free Protocols Foundation relating to patents,
copyright, and confidentiality. These
procedures are set forth in Section 6.
o Declared Patent-Free Protocol. A protocol for
which a declaration has been made, to the Free
Protocols Foundation, that it conforms to the
procedures of Section 6.
o Author of a Protocol. The individual, company
or organization, or the set of individuals,
companies or organizations, who are
responsible for the creation, development,
maintenance, or enhancement of the protocol
specification.
o Working Group. An open-ended set of
individuals or organizations who collectively
work towards the creation, development,
maintenance, or enhancement of the protocol
specification.
o Free Protocol Development Working Group. A
Working Group which has voluntarily elected to
adhere to, and be bound by, the policies and
procedures of the Free Protocols Foundation
regarding patent-freedom.
o Free Protocol Developer. A contributor to a
Free Protocol Development Working Group.
1.5 About the Free Protocol Processes and
Procedures
--------------------------------------------
This document establishes a set of policies and
procedures for protocol development that is
designed to ensure, as far as this is possible,
that the resulting protocol is functionally
patent-free. The purpose of these procedures is
to create a resulting protocol that is either free
from patent restrictions, or for which
non-restrictive usage rights have been obtained
from the patent-holder. These procedures are set
forth in Section 6.
The procedures of Section 6 are based on a similar
set of procedures defined by the IESG (Internet
Engineering Steering Group). Specifically, the
FPF procedures are an extension of Section 10,
Intellectual Property Rights, of RFC 2026, The
Internet Standards Process -- Revision 3 [4].
That section defines the procedures to be followed
by the IETF (Internet Engineering Task Force)
relating to patent-freedom. However, the scope of
RFC 2026 is largely limited to the needs of the
IESG itself; in particular, the patent-related
procedures of Section 10 of RFC 2026 are limited
to standards-track documents and other
IETF-specific purposes. Thus, while these patent
procedures may be entirely adequate for the needs
of the IETF, they are not adequate to dealing with
patent-freedom in a more general setting.
The processes and procedures in Section 6 of this
document are therefore an extension of the RFC
2026 procedures, designed to address the need for
patent-freedom procedures in general. They are
intended to be a set of general-purpose processes
which can be adopted by any protocol development
organization.
1.6 About this Document
-------------------------
This document is available in several alternative
formats ...
2 The Protocol Development Process
====================================
Protocols come in all shapes and sizes, and from a
variety of sources. Some are proprietary,
intended for use exclusively by their developer.
Others may be ``open'' in some sense, indicating
that they are intended for more general, public
usage. In this context, the word ``open'' can
mean any one of several different things. It may
mean nothing more than that the protocol has been
published by its developer. The protocol may
still be very tightly controlled: revision of the
protocol may remain the exclusive right of the
developer; the protocol may be protected by patent
or copyright restrictions; and use of the protocol
may require a licensing agreement. This is a very
narrow, and to our mind misleading, use of the
word ``open.''
At the other extreme, the protocol may be open to
a very high degree of public accessibility: it
can be published by an open mechanism such as RFC
publication; undergo revision by means of public
working groups; and be entirely free of usage
restrictions. A protocol satisfying all these
criteria can be said to be ``open'' in the
broadest sense. Protocols are often referred to
as ``open'' to imply that they are open in a broad
sense, whereas in fact they are open only in the
narrowest sense.
Also, protocols can have widely differing periods
of industry tenure. Some protocols never achieve
widespread acceptance and usage, or else have very
short lifetimes before becoming obsolete or being
eclipsed by competing protocols. Other protocols
become highly successful, and persist as long-term
industry standards.
2.1 Phases of Development
---------------------------
Over its lifetime, a protocol typically goes
through a number of developmental phases. In
general, from conception to decease, a protocol
may go through some or all of the following
phases:
1. Initial development.
2. Global parameter assignment.
3. Publication.
4. Patent-free declarations.
5. Industry usage.
6. Maintenance and enhancement.
7. Endorsement by a standards body.
Depending on its purpose, nature, and history, a
protocol may undergo some, all, or none of these
phases. Also, a protocol may iterate through
phases 3 - 7 multiple times, as it undergoes
maturation via repeated revision and
re-publication. As described later, the Free
Protocols Foundation plays a role in only two of
these phases. For completeness, however, in the
following sections we provide a brief description
of each phase, along with commentary on the FPF's
philosophy regarding the protocol development
process.
2.1.1 Initial Protocol Development
------------------------------------
The conception and early development of a protocol
can take place in a variety of ways. A
traditional source of Internet protocols is the
IETF/IESG. Other sources of protocols are private
businesses, the academic community, or even a
single individual.
We believe that there is a tendency among
established standards bodies to regard their own,
officially sanctioned protocols as authoritative,
while any other protocol is of questionable worth
or validity. However, the history of protocol
development does not support this view. Small
groups of individuals have created protocols with
far-reaching consequences (e.g. the World Wide
Web), just as established standards bodies have
created protocols which failed to achieved
industry acceptance.
At the Free Protocols Foundation, we do not regard
any one source of protocols as necessarily
superior to any other. We believe that any
coordination of activities can generate useful
protocols, and we are ready to provide the same
support for patent-freedom regardless of the
initial source of the protocol.
2.1.2 Global Parameter Assignment
-----------------------------------
If necessary, global parameters must be assigned
to the protocol, e.g. by the IANA. The Free
Protocols Foundation plays no role in this
process.
2.1.3 Protocol Publication
----------------------------
If the protocol is intended to be an open
protocol, as opposed to an exclusively proprietary
one, then it must be made publicly available.
This can be accomplished in various ways; the
protocol can be self-published by the developer,
or it can be published through an independent
agency such as the Internet RFC Editor.
Ideally, the protocol should be published in a way
which allows permanent and unrestricted access to
the protocol by anyone wishing to implement it.
In the case of Internet protocols, this is usually
accomplished by RFC publication.
2.1.4 Patent-Free Declarations
--------------------------------
Depending on their intentions, the developers of a
protocol may take steps to work towards a
patent-free result, and they may wish to make
certain declarations to that effect.
In general, there may be both an Author and a
Working Group involved in the development of a
protocol. The Author is the person, company, or
other entity that has primary responsibility for
the protocol. In some cases, the protocol may
also undergo development at the hands of a Working
Group -- a set of independent individuals or
companies who work cooperatively on the protocol,
usually via public mailing lists.
Both the Author and the Working Group may wish to
make declarations regarding the patent-freedom of
the protocol. The Author may wish to make an
initial declaration that the protocol is intended
to be patent-free. As described later in this
document, it is not possible to make an absolute
guarantee that a protocol is, and will remain,
completely patent-free. The best an Author can do
is make a good-faith declaration that:
o To the best of his knowledge the protocol is
not subject to any patent restrictions.
o It is the Author's intention to maintain the
protocol patent-free.
o If any patent restrictions relating to the
protocol become known to the Author, he will
make prompt disclosure of this.
Similarly, the Working Group may wish to make a
declaration that:
o The protocol has been developed in such a way
as to ensure that no patented components have
been intentionally introduced into the
protocol.
o If any patent restrictions relating to the
protocol become known to the Working Group, it
will make prompt disclosure of this.
One of the roles of the Free Protocols Foundation
is to provide a public forum in which such
declarations can be made. Any such declaration
which is submitted to the FPF will be published on
our website at http://www.FreeProtocols.org.
Examples of previously submitted declarations may
be seen at that location.
2.1.5 Industry Usage
----------------------
The ultimate test of a protocol is whether or not
it becomes widely accepted and implemented in the
industry. If a protocol is largely unused, or
eclipsed by a competing protocol, then it is
largely irrelevant.
2.1.6 Maintenance and Enhancement
-----------------------------------
Protocols are usually not static, but instead
typically undergo revision and enhancement in
response to experience and/or changing industry
requirements. Depending on the intentions of the
Authors, this may take place by closed and
proprietary processes, or by open and public ones.
In the case of a truly open protocol, the
development process should allow commentary and
participation by all the constituencies that are
affected by the protocol.
In some cases, continued development and
enhancement of the protocol is accomplished by
means of a public Working Group. Also depending
on the Authors' intentions, the Working Group may
function in a way which preserves the
patent-freedom of the protocol, and the Working
Group may wish to make a declaration to this
effect.
Two things are required in order to achieve these
goals. First, the developers must establish and
follow a set of Working Group operating procedures
that will have the effect of preserving the
patent-freedom of the protocol. Second, the
developers must make a public declaration that the
Working Group follows these procedures.
A developer can achieve both of these things
without the assistance of the Free Protocols
Foundation. The development organization can
establish its own set of Working Group operating
procedures, and can independently announce that
the Working Group follows them.
However, the Free Protocols Foundation provides a
means of accomplishing these things which is
external to, and independent of, the development
organization itself. It is for this purpose that
the FPF primarily exists. First, the FPF defines
a clear and unambiguous set of Working Group
processes and procedures which ensure, as far as
possible, that the resulting protocol will remain
functionally patent-free. Any development
organization is free to adopt these procedures
with regard to its own protocol. Second, the FPF
provides an external forum in which the developer
may declare publicly that its Working Group
follows these procedures.
The FPF Working Group procedures are designed to:
o Ensure that no patented components can be
intentionally introduced into the protocol as
a result of the Working Group activities.
o Provide remedies in the case of unintentional
introduction of patented components into the
protocol. These remedies consist of prompt
publication of the fact of the patented
component, and an attempt to secure
non-restrictive usage rights from the patent
holder.
2.1.7 Endorsement by a Standards Body
---------------------------------------
The ultimate arbiter of protocols is the industry
itself, in which a multitude of individual
decisions leads to the acceptance or rejection of
any particular protocol. The acceptance of a
protocol as a standard is therefore something that
occurs independently of formal endorsement by a
standards body.
Nevertheless, once a protocol has become accepted
as an industry standard, it is often the case that
it receives the formal sanction of a standards
body.
2.2 Role of the Free Protocols Foundation
-------------------------------------------
It is sometimes the case that many of the above
phases of development take place under the
direction of a single institution, or a group of
tightly coupled institutions. For example, when
developing protocols the IETF/IESG/IAB
traditionally claims authority for all aspects of
development except for (5), over which, of course,
it has no direct control.
At the Free Protocols Foundation, we consider it
undesirable to place control of multiple aspects
of the development process in the hands of any
single institution. First, this can include
built-in conflicts of interest. For example, if a
standards body is responsible both for developing
protocols and publishing industry protocols, the
body may be inclined to favor publication of its
own protocols in preference to competing protocols
from other sources, or it may be inclined to place
inappropriate commentary within competing
protocols. The IETF/IESG has a history of doing
both of these things.
As another example, if the Maintenance and
Enhancement responsibility is closely-held by a
developing company or group of companies, this
process may be biased in favor of the companys'
interests, rather than those of the industry at
large.
Furthermore, a large spread of responsibility
within a single institution can lead to
bureaucratization of its activities; the energy of
the organization can become directed towards
maintaining its internal bureaucracy, rather than
serving the needs of its consumers. In other
words, the institution can become authority
oriented, as opposed to responsibility oriented.
The historical evolution of the IETF/IESG/IAB is a
classic example of this.
For these reasons, the Free Protocols Foundation
is in favor of decoupling, as much as possible,
the responsibility for the various aspects of
development. A separation of powers greatly
lessens the potential for conflicts of interest.
Furthermore, an organization with limited
responsibility can be discarded, reformed, or
replaced more easily than one with very broad
responsibility. Separation of powers thus
provides a greater degree of choice, and therefore
competition, within the protocol development
process.
The Free Protocols Foundation is therefore in
favor of placing responsibility for the various
phases and aspects of development in the hands of
independent organizations with limited agendas.
We favor delegating the Protocol Publication phase
to a truly independent third-party entity, such as
the Internet RFC Editor. We favor handling the
Maintenance and Enhancement phase by means of a
variety of truly open public working groups, not
just the IETF. Both of these steps ensure unbiased
processing of the protocol.
In the same spirit, we favor placing
responsibility for working towards patent-freedom
in the hands of an independent organization. It
is primarily for this reason that the Free
Protocols Foundation exists. The role of the Free
Protocols Foundation is to place those aspects of
the protocol development process which relate to
patent-freedom in a common, central, public
location. The various other aspects of the
development process have been described only to
place the role of the FPF in its proper context;
the FPF plays no role in those aspects.
In our model of the protocol development process,
the scope of FPF activities is limited to two
items exclusively:
o (4) Patent-free declarations, and
o (6) Maintenance and enhancement,
and the Free Protocols Foundation has no agenda
other than this.
Note that the role played by the FPF regarding
protocol patents is somewhat analogous to the role
played by the RFC Editor regarding protocol
publication. RFC publication provides a means of
publishing, via an independent agency, Internet
protocols which have been produced by a variety of
sources.
Similarly, the FPF represents a means of dealing
with patent issues by an independent agency.
Hitherto, this responsibility has been taken by
multiple standards bodies, each of which has been
obliged to define its own processes and procedures
relating to patents. By adopting the FPF
procedures, a standards body or development
organization can make use of a set of general
services established by an external agency.
2.3 Coordination of Activities
--------------------------------
As noted in the previous section, the FPF is in
favor of distributing responsibility for the
various aspects of protocol development, rather
than consolidating all these aspects under the
umbrella of a single organization, such as the
IETF.
The objection may be made, that this distribution
of responsibility creates coordination
difficulties. It can be argued that
vertically-integrated organizations like the IETF
play a valuable role in terms of coordination of
activities, and that it is more difficult to
coordinate the activities of multiple independent
organizations. In particular, it can be said that
the IETF assists in the logical and orderly
development of multiple protocols, by establishing
a common architecture and structure for sets of
related protocols.
However, we believe that this objection is
unfounded. It has been well demonstrated, for
example by the development of Linux, that multiple
independent entities can coordinate their
development efforts extremely effectively. In any
event, the advantages to be gained from a
separation of powers certainly exceed the
drawbacks.
3 The Free Protocols Foundation
=================================
3.1 General Philosophy
------------------------
At the Free Protocols Foundation, we consider that
patented protocols are very undesirable. A
protocol is a general agreement within an industry
that things will be done in a certain way. It
represents an agreed-upon expected behavior,
providing common ground for cooperation among a
variety of disparate entities: private
businesses, academic institutions, government, and
individuals. The protocol allows any of these
entities to create products, services,
applications, etc., and provides the necessary
assurances that these offerings will function and
interoperate in a well-defined way. The protocol
is a positive, enabling force for the entire
industry.
In order for the protocol to play this role,
anyone who wishes to implement and use it must be
able to do so freely, and without restrictions.
The presence of patented components within the
protocol places restrictions on its usage, and
therefore serves only to undermine this purpose.
Furthermore, the presence of the patent brings an
enormously unfair market advantage to the patent
holder. By exercising his patent rights, the
patent holder can gain financial benefit from
competing companies who wish to use the protocol,
or can stifle competition altogether by denying
the competing company the right to use the
protocol at all.
We have no objection to companies seeking market
advantage by means which benefit the consumer and
the industry. Such means include the creation of
superior products and services, or the exercising
of legitimate patents on physical processes. But
we strenuously object to the seeking of market
advantage by attempting to lay claim to the
protocol itself.
The presence of a patent within a protocol is at
best absurd, pointless, and self-defeating. And
at worst, it represents an attempt by corrupt
business interests to gain market advantage at the
expense of the industry and the consumer.
3.2 Purpose, Activities and Scope
-----------------------------------
The Free Protocols Foundation is a nonprofit
corporation, incorporated in the State of
Washington.
The principal purpose of the Free Protocols
Foundation is to act as an independent public
forum for the support of patent-free protocols.
We do this by means of the following major
activities:
o By providing an independent, external forum in
which an Author may make an initial
declaration that a protocol is intended to be
patent-free.
o By defining a set of patent-related Working
Group procedures which, if followed, ensure
that the resulting protocol will remain
functionally patent-free. Any development
organization is free to adopt these procedures
with regard to its own protocols.
o By providing an independent, external forum in
which a Working Group may make a public
declaration that it follows these procedures.
o Whenever patent rights are asserted with
respect to any protocol which has been
declared patent-free to the FPF, by publishing
a statement of the patent right assertion.
o Whenever patent rights are known to exist with
respect to a protocol which has been declared
patent-free to the FPF, by assisting in
obtaining from the patent-holder a
non-restrictive license to implement the
patented process as part of the protocol.
The scope of activities of the Free Protocols
Foundation is limited to those activities which
provide support for free protocols, and which
oppose the mis-use of patented protocols.
In particular, the Free Protocols Foundation does
not develop protocols itself, nor does it
participate in the development of the protocols of
other organizations. The FPF does not evaluate or
provide any commentary on the technical merits of
protocols.
Also, the FPF does not make any independent
verification of whether or not a developer
actually adheres to the processes and procedures
of Section 6. The FPF does no more than record
the fact that the development organization has
made the declaration that it conforms to those
procedures.
3.3 Other Activities
----------------------
In addition to its activities undertaken to
support the development of patent-free protocols,
the FPF may also take actions to oppose the
creation and promotion of patented protocols.
These actions may consist of any of the following:
o Acting as a clearing house for information and
articles relating to protocol patent-freedom.
o Supporting the creation and development of
patent-free alternative protocols to existing
patented protocols.
o Alerting legislators of the harmful effects of
software and protocol patents, and lobbying
for changes in the way software patents are
granted.
o Alerting the United States Patent and
Trademark Office (PTO) of the harmful effects
of software and protocol patents, and lobbying
for changes in the way sofware patents are
granted.
o Supporting fights against invalid software
patents in the courts.
o Boycotting companies which misuse software and
protocol patents.
We encourage others to join us in resisting the
granting and abuse of software and protocol
patents.
....
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf