5. Working Groups
The vast majority of the IETF's work is done in many Working Groups;
at the time of this writing, there are about 115 different WGs. (The
term "Working Group" is often seen capitalized, but probably not for
any good reason.) [BCP25], "IETF Working Group Guidelines and
Procedures", is an excellent resource for anyone participating in WG
A WG is really just a mailing list with a bit of adult supervision.
You "join" the WG by subscribing to the mailing list; all mailing
lists are open to anyone. Anyone can post to a WG mailing list,
although most lists require non-subscribers to have their postings
moderated. Each Working Group has one or two chairs.
More important, each WG has a charter that the WG is supposed to
follow. The charter states the scope of discussion for the Working
Group, as well as its goals. The WG's mailing list and face-to-face
meetings are supposed to focus on just what is in the charter and not
to wander off on other "interesting" topics. Of course, looking a
bit outside the scope of the WG is occasionally useful, but the large
majority of the discussion should be on the topics listed in the
charter. In fact, some WG charters actually specify what the WG will
not do, particularly if there were some attractive but nebulous
topics brought up during the drafting of the charter. The list of
all WG charters makes interesting reading for folks who want to know
what the different Working Groups are supposed to be doing.
5.1. Working Group Chairs
The role of the WG chairs is described in both [BCP11] and [BCP25].
The IETF EDU team also offers special training for WG chairs on
Sunday afternoons preceding IETF.
As volunteer cat-herders, a chair's first job is to determine the WG
consensus goals and milestones, keeping the charter up to date.
Next, often with the help of WG secretaries or document editors, the
chair must manage WG discussion, both on the list and by scheduling
meetings when appropriate. Sometimes discussions get stuck on
contentious points and the chair may need to steer people toward
productive interaction and then declare when rough consensus has been
met and the discussion is over. Sometimes chairs also manage
interactions with non-WG participants or the IESG, especially when a
WG document approaches publication. Chairs have responsibility for
the technical and non-technical quality of WG output. As you can
imagine given the mix of secretarial, interpersonal, and technical
demands, some Working Group chairs are much better at their jobs than
When a WG has fulfilled its charter, it is supposed to cease
operations. (Most WG mailing lists continue on after a WG is closed,
still discussing the same topics as the Working Group did.) In the
IETF, it is a mark of success that the WG closes up because it
fulfilled its charter. This is one of the aspects of the IETF that
newcomers who have experience with other standards bodies have a hard
time understanding. However, some WG chairs never manage to get
their WG to finish, or keep adding new tasks to the charter so that
the Working Group drags on for many years. The output of these aging
WGs is often not nearly as useful as the earlier products, and the
messy results are sometimes attributed to what's called "degenerative
Working Group syndrome".
There is an official distinction between WG drafts and independent
drafts, but in practice, sometimes there is not much procedural
difference. For example, many WG mailing lists also discuss
independent drafts (at the discretion of the WG chair). Procedures
for Internet Drafts are covered in much more detail later in this
WG chairs are strongly advised to go to the WG leadership training
that usually happens on the Sunday preceding the IETF meeting. There
is also usually a WG chairs lunch mid-week during the meeting where
chair-specific topics are presented and discussed. If you're
interested in what they hear there, take a look at the slides at
5.2. Getting Things Done in a Working Group
One fact that confuses many novices is that the face-to-face WG
meetings are much less important in the IETF than they are in most
other organizations. Any decision made at a face-to-face meeting
must also gain consensus on the WG mailing list. There are numerous
examples of important decisions made in WG meetings that are later
overturned on the mailing list, often because someone who couldn't
attend the meeting pointed out a serious flaw in the logic used to
come to the decision. Finally, WG meetings aren't "drafting
sessions", as they are in some other standards bodies: in the IETF,
drafting is done elsewhere.
Another aspect of Working Groups that confounds many people is the
fact that there is no formal voting. The general rule on disputed
topics is that the Working Group has to come to "rough consensus",
meaning that a very large majority of those who care must agree. The
exact method of determining rough consensus varies from Working Group
to Working Group. Sometimes consensus is determined by "humming" --
if you agree with a proposal, you hum when prompted by the chair; if
you disagree, you keep your silence. Newcomers find it quite
peculiar, but it works. It is up to the chair to decide when the
Working Group has reached rough consensus.
The lack of formal voting has caused some very long delays for some
proposals, but most IETF participants who have witnessed rough
consensus after acrimonious debates feel that the delays often result
in better protocols. (And, if you think about it, how could you have
"voting" in a group that anyone can join, and when it's impossible to
count the participants?) Rough consensus has been defined in many
ways; a simple version is that it means that strongly held objections
must be debated until most people are satisfied that these objections
Some Working Groups have complex documents or a complex set of
documents (or even both). Shaking all the bugs out of one or more
complex documents is a daunting task. In order to help relieve this
problem, some Working Groups use "issue trackers", which are online
lists of the open issues with the documents, the status of the issue,
proposed fixes, and so on. Using an issue tracker not only helps the
WG not to forget to do something important, it helps when someone
asks a question later about why something was done in a particular
Another method that some Working Groups adopt is to have a Working
Group "secretary" to handle the juggling of the documents and the
changes. The secretary can run the issue tracker if there is one, or
can simply be in charge of watching that all of the decisions that
are made on the mailing list are reflected in newer versions of the
One thing you might find helpful, and possibly even entertaining,
during Working Group sessions is to follow the running commentary on
the Jabber room associated with that Working Group. The running
commentary is often used as the basis for the minutes of the meeting,
but it can also include jokes, sighs, and other extraneous chatter.
Jabber is a free, streaming XML technology mainly used for instant
messaging. You can find pointers to Jabber clients for many
platforms at http://www.jabber.org. The Jabber chatrooms have the
name of the Working Group followed by "@jabber.ietf.org". Those
rooms are, in fact, available year-round, not just during IETF
meetings, and some are used by active Working Group participants
during protocol development.
5.3. Preparing for Working Group Meetings
The most important thing that everyone (newcomers and seasoned
experts) should do before coming to a face-to-face meeting is to read
the Internet Drafts and RFCs ahead of time. WG meetings are
explicitly not for education: they are for developing the group's
documents. Even if you do not plan to say anything in the meeting,
you should read the group's documents before attending so you can
understand what is being said.
It's up to the WG chair to set the meeting agenda, usually a few
weeks in advance. If you want something discussed at the meeting, be
sure to let the chair know about it. The agendas for all the WG
meetings are available in advance (see
http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the
meeting number), but many WG chairs are lax (if not totally
negligent) about turning them in.
The Secretariat only schedules WG meetings a few weeks in advance,
and the schedule often changes as little as a week before the first
day. If you are only coming for one WG meeting, you may have a hard
time booking your flight with such little notice, particularly if the
Working Group's meeting changes schedule. Be sure to keep track of
the current agenda so you can schedule flights and hotels. But, when
it comes down to it, you probably shouldn't be coming for just one WG
meeting. It's likely that your knowledge could be valuable in a few
WGs, assuming that you've read the drafts and RFCs for those groups.
If you are on the agenda at a face-to-face meeting, you should
probably come with a few slides prepared. But don't come with a
tutorial; people are supposed to read the drafts in advance.
Projectors for laptop-based presentations are available in all the
And here's a tip for your slides in WG or plenary presentations:
don't put your company's logo on every one, even though that is a
common practice outside the IETF. The IETF frowns on this kind of
corporate advertising (except for the meeting sponsor in the plenary
presentation), and most presenters don't even put their logo on their
opening slide. The IETF is about technical content, not company
boosterism. Slides are often plain black and white for legibility,
with color used only when it really adds clarity. Again, the content
is the most important part of the slides, not how it's presented.
5.4. Working Group Mailing Lists
As we mentioned earlier, the IETF announcement and discussion mailing
lists are the central mailing lists for IETF activities. However,
there are many other mailing lists related to IETF work. For
example, every Working Group has its own discussion list. In
addition, there are some long-term technical debates that have been
moved off of the IETF list onto lists created specifically for those
topics. It is highly recommended that you follow the discussions on
the mailing lists of the Working Groups that you wish to attend. The
more work that is done on the mailing lists, the less work that will
need to be done at the meeting, leaving time for cross pollination
(i.e., attending Working Groups outside one's primary area of
interest in order to broaden one's perspective).
The mailing lists also provide a forum for those who wish to follow,
or contribute to, the Working Groups' efforts, but can't attend the
IETF meetings. That's why IETF procedures require all decisions to
be confirmed "on the list" and you will often hear a WG chair say,
"Let's take it to the list" to close a discussion.
Many IETF discussion lists use either mailman or another list
manager, Majordomo. They usually have a "-request" address that
handles the administrative details of joining and leaving the list.
(See Section 3.3 for more information on mailman.) It is generally
frowned upon when such administrivia appears on the discussion
Most IETF discussion lists are archived. That is, all of the
messages sent to the list are automatically stored on a host for
anonymous HTTP or FTP access. Many such archives are listed online
at ftp://ftp.ietf.org/ietf-mail-archive/ or they are in a web-based
archive. If you don't find the list you're looking for, send a
message to the list's "-request" address (not to the list itself!).
The Working Group charter listings at
http://www.ietf.org/html.charters/wg-dir.html are a useful source;
note that the page has links to old, concluded WGs.
Some WG lists apply size limits on messages, particularly to avoid
large documents or presentations landing in everyone's mailbox. It
is well worth remembering that participants do not all have broadband
connections (and even those with broadband connections sometimes get
their mail on slow connections when they travel), so shorter messages
are greatly appreciated. Documents can be posted as Internet Drafts;
presentation material can be posted to a web site controlled by the
sender or sent personally to people who ask for it. Some WGs set up
special sites to hold these large documents so that senders can post
there first, then just send to the list the URL of the document.
5.5. Interim Working Group Meetings
Working Groups sometimes hold interim meetings between IETFs.
Interim meetings aren't a substitute for IETF meetings, however -- a
group can't decide to skip a meeting in a location they're not fond
of and meet in Cancun (or even someplace mundane) three weeks later,
for example. Interim meetings require AD approval and need to be
announced at least one month in advance. Location and timing need to
allow fair access for all participants. Like regular IETF meetings,
someone needs to take notes and send them to
mailto:email@example.com, and the group needs to take attendance.
Decisions tentatively made during an interim WG meeting still must be
ratified on the mailing list.
In order to form a Working Group, you need a charter and someone who
is able to be chair. In order to get those things, you need to get
people interested so that they can help focus the charter and
convince an Area Director that the project is worthwhile. A face-
to-face meeting is useful for this. In fact, very few WGs get
started by an Area Director; most start after a face-to-face BOF
because attendees have expressed interest in the topic.
A Birds of a Feather (BOF) meeting has to be approved by the Area
Director in the relevant area before it can be scheduled. If you
think you really need a new WG, approach an AD informally with your
proposal and see what he or she thinks. The next step is to request
a meeting slot at the next face-to-face meeting. Of course, you
don't need to wait for that meeting to get some work done, such as
setting up a mailing list and starting to discuss a charter.
BOF meetings have a very different tone than do WG meetings. The
purpose of a BOF is to make sure that a good charter with good
milestones can be created and that there are enough people willing to
do the work needed in order to create standards. Some BOFs have
Internet Drafts already in process, whereas others start from
An advantage of having a draft before the BOF is to help focus the
discussion. On the other hand, having a draft might tend to limit
what the other folks in the BOF want to do in the charter. It's
important to remember that most BOFs are held in order to get support
for an eventual Working Group, not to get support for a particular
Many BOFs don't turn into WGs for a variety of reasons. A common
problem is that not enough people can agree on a focus for the work.
Another typical reason is that the work wouldn't end up being a
standard -- if, for example, the document authors don't really want
to relinquish change control to a WG. (We'll discuss change control
later in this document.) Only two meetings of a BOF can be scheduled
on a particular subject; either a WG has to form or the topic should
7. New to the IETF and Coming to a Meeting? STOP HERE! (Temporarily)
If you're new to the IETF and this is the only reference you plan to
read before coming to the meeting, stop here -- at least temporarily.
Then, on your flight home, read the rest of the Tao. By that time
you'll be ready to get actively involved in the Working Groups that
interested you at the meeting, and the Tao will get you started on
If you're planning to participate in the IETF remotely, through
reading email lists and the proceedings, read on!
8. RFCs and Internet Drafts
If you're a new IETF participant and are looking for a particular RFC
or Internet Draft, go to the RFC Editor's web pages, http://www.rfc-
editor.org/rfc.html. That site also has links to other RFC
collections, many with search capabilities. If you know the number
of the RFC you're looking for, go to the IETF RFC pages,
http://www.ietf.org/rfc.html. For Internet Drafts, the best resource
is the IETF web site, http://www.ietf.org/ID.html, where you can
search by title and keyword.
8.1. Getting an RFC Published
One of the most common questions seasoned IETFers hear from newcomers
is, "How do I get an IETF standard published?" A much better
question is, "Should I write an IETF standard?" since the answer is
not always "yes." If you do decide to try to write a document that
becomes an IETF standard, be warned that the overall process may be
arduous, even if the individual steps are fairly straightforward.
Lots of people get through the process unscathed, though, and there's
plenty of written guidance that helps authors emerge with their ego
more or less intact.
Every IETF standard is published as an RFC (a "Request for Comments,"
but everyone just calls them RFCs), and every RFC starts out as an
Internet Draft (often called an "I-D"). The basic steps for getting
something published as an IETF standard are as follows:
1. Publish the document as an Internet Draft.
2. Receive comments on the draft.
3. Edit your draft based on the comments.
4. Repeat steps 1 through 3 a few times.
5. Ask an Area Director to take the draft to the IESG (if it's an
individual submission). If the draft is an official Working
Group product, the WG chair asks the AD to take it to the IESG.
6. Make any changes deemed necessary by the IESG (this might include
giving up on becoming a standard).
7. Wait for the document to be published by the RFC Editor.
A much more complete explanation of these steps is contained in
[BCP9], "The Internet Standards Process". Those who write drafts
that they hope will become IETF standards must read BCP 9 so that
they can follow the path of their document through the process. BCP
9 (and various other documents that update it) goes into great detail
on a topic that is very often misunderstood, even by seasoned IETF
participants: different types of RFCs go through different processes
and have different rankings. There are six kinds of RFCs:
o Proposed standards
o Draft standards
o Internet standards (sometimes called "full standards")
o Informational documents
o Experimental protocols
o Historic documents
Only the first three (proposed, draft, and full) are standards within
the IETF. A good summary of this can be found in the aptly titled
[RFC1796], "Not All RFCs Are Standards".
There are also three sub-series of RFCs, known as FYIs, BCPs, and
STDs. The For Your Information RFC sub-series was created to
document overviews and topics that are introductory or that appeal to
a broad audience; however, that series has not been added to in a
long time. Best Current Practice documents describe the application
of various technologies in the Internet. The STD RFC sub-series was
created to identify RFCs that do in fact specify Internet standards.
Some STDs are actually sets of more than one RFC, and the "standard"
designation applies to the whole set of documents.
8.2. Letting Go Gracefully
The biggest reason some people do not want their documents put on the
IETF standards track is that they must give up change control of the
protocol. That is, as soon as you propose that your protocol become
an IETF standard, you must fully relinquish control of the protocol.
If there is general agreement, parts of the protocol can be
completely changed, whole sections can be ripped out, new things can
be added, and the name can be changed.
Some authors find it very hard to give up control of their pet
protocol. If you are one of those people, don't even think about
trying to get your protocol to become an IETF standard. On the other
hand, if your goal is the best standard possible with the widest
implementation, then you might find the IETF process to your liking.
Incidentally, the change control on Internet standards doesn't end
when the protocol is put on the standards track. The protocol itself
can be changed later for a number of reasons, the most common of
which is that implementors discover a problem as they implement the
standard. These later changes are also under the control of the
IETF, not the editors of the standards document.
IETF standards exist so that people will use them to write Internet
programs that interoperate. They don't exist to document the
(possibly wonderful) ideas of their authors, nor do they exist so
that a company can say, "We have an IETF standard". If a standards-
track RFC only has one implementation (whereas two are required for
it to advance on the standards track), it was probably a mistake to
put it on the standards track in the first place.
8.3. Internet Drafts
First things first. Every document that ends up in the RFC
repository starts life as an Internet Draft. Internet Drafts are
tentative documents -- they're meant for readers to comment on, so
authors can mull over those comments and decide which ones to
incorporate in the draft. In order to remind folks of their
tentativeness, Internet Drafts are automatically removed from the
online directories after six months. They are most definitely not
standards or even specifications. As [BCP9] says:
"An Internet Draft is NOT a means of 'publishing' a specification;
specifications are published through the RFC mechanism.... Internet
Drafts have no formal status, and are subject to change or removal at
any time. Under no circumstances should an Internet Draft be
referenced by any paper, report, or Request-for-Proposal, nor should
a vendor claim compliance with an Internet Draft".
You can always tell a person who doesn't understand the IETF (or is
intentionally trying to fool people) when he or she brags about
having published an Internet Draft; it takes no significant effort.
When you submit an Internet Draft, you give some publication rights
to the IETF. This is so that your Internet Draft is freely available
to everyone who wants to read and comment on it. The rights you do
and don't give to the IETF are described in [BCP78], "IETF Rights in
There is a very useful checking tool at
http://tools.ietf.org/tools/idnits/idnits.pyht. Using this tool
before you turn in an Internet Draft will help prevent the draft from
being rejected due to errors in form and formatting.
An I-D should have approximately the same format as an RFC. Contrary
to many people's beliefs, an I-D does not need to look exactly like
an RFC, but if you can use the same formatting procedures used by the
RFC Editor when you create your I-Ds, it will simplify the RFC
Editor's work when your draft is published as an RFC. [RFC2223],
"Instructions to RFC Authors", describes the nroff formatting used by
the RFC Editor. There is also a tool called "xml2rfc", available
from http://xml.resource.org/, that takes XML-formatted text and
turns it into a valid Internet Draft.
An Internet Draft can be either a Working Group draft or an
individual submission. Working Group drafts are usually reviewed by
the Working Group before being accepted as a WG item, although the
chairs have the final say.
If you're interested in checking the status of a particular draft, or
can't remember its exact name, or want to find out which drafts a WG
is working on, two handy tools are available. The "Internet Drafts
Database Interface", at
https://datatracker.ietf.org/public/idindex.cgi, lets you search for
a draft by author, Working Group, date, or filename. The "I-D
Tracker", at https://datatracker.ietf.org/public/pidtracker.cgi, is
especially useful for authors who want to track the progress of their
draft as it makes its way through the publication process.
There are some informal rules for Internet Draft naming that have
evolved over the years. Internet Drafts that revise existing RFCs
often have draft names with "bis" in them, meaning "again" or
"twice"; for example, a draft might be called "draft-someone-
8.3.1. Recommended Reading for Writers
Before you create the first draft of your Internet Draft, you should
read four documents:
o More important than just explaining formatting, [RFC2223] also
explains what needs to be in an Internet Draft before it can
become an RFC. This document describes all the sections and
notices that will need to be in your document, and it's good to
have them there from the beginning so that readers aren't
surprised when you put them in later versions.
o [BCP22], "Guide for Internet Standards Writers", provides tips
that will help you write a standard that leads to
interoperability. For instance, it explains how to choose the
right number of protocol options, how to respond to out-of-spec
behavior, and how to show state diagrams.
o The online "Guidelines to Authors of Internet Drafts",
http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date
information about the process for turning in Internet Drafts, as
well as the most current boilerplate information that has to be
included in each Internet Draft.
o When you think you are finished with the draft process and are
ready to request that the draft become an RFC, you should
definitely read "Checklist for Internet Drafts (I-Ds) Submitted
for RFC Publication", http://www.ietf.org/ID-Checklist.html, a
list of common issues that have been known to stop documents in
the IESG. In fact, you should probably read that document well
before you are finished, so that you don't have to make a bunch of
Also, you should visit the IETF Tools web pages,
http://tools.ietf.org, where you'll find pointers to other tools that
will automate some of your work for the IETF.
8.3.2. Filenames and Other Matters
When you're ready to turn in your Internet Draft, send it to the
Internet Drafts administrator at mailto:firstname.lastname@example.org.
There is a real person at the other end of this mail address, whose
job is to make sure you've included the minimum items you need for
the Internet Draft to be published. When you submit the first
version of the draft, you also tell the draft administrator your
proposed filename for the draft. If the draft is an official Working
Group product, the name will start with "draft-ietf-" followed by the
designation of the WG, followed by a descriptive word or two,
followed by "00.txt".
For example, a draft in the S/MIME WG about creating keys might be
named "draft-ietf-smime-keying-00.txt". If it's not the product of a
Working Group, the name will start with "draft-" and the last name of
one of the authors followed by a descriptive word or two, followed by
"00.txt". For example, a draft that someone named Smith wrote might
be named "draft-smith-keying-00.txt". If a draft is an individual
submission but relates to a particular Working Group, authors
sometimes follow their name with the name of the Working Group, such
as "draft-smith-smime-keying-00.txt". You are welcome to suggest
names; however, it is up to the Internet Drafts administrator (and,
if it is an official WG draft, the WG chair) to come up with the
filename. If you follow the naming guidelines given at
http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good
that your suggested filename will be fine.
After the first edition of a draft, the number in the filename is
incremented; for instance, the second edition of the S/MIME draft
named above would be "draft-ietf-smime-keying-01.txt". Note that
there are cases where the filename changes after one or more
versions, such as when a personal effort is pulled into a Working
Group; when a draft has its filename changed, the number reverts to
-00. Be sure to let the Internet Drafts administrator know the
previous name of the draft when such a name change occurs so that the
databases can be kept accurate.
8.4. Standards-Track RFCs
The procedure for creating and advancing a standard is described in
[BCP9]. After an Internet Draft has been sufficiently discussed and
there is rough consensus that what it says would be a useful
standard, it is presented to the IESG for consideration. If the
draft is an official WG draft, the WG chair sends it to the
appropriate Area Director after it has gone through Working Group
last call. If the draft is an individual submission, the draft's
author or editor submits it to the appropriate Area Director. BCP 9
also describes the appeals process for people who feel that a Working
Group chair, an AD, or the IESG has made the wrong decision in
considering the creation or advancement of a standard.
After the I-D is submitted to the IESG, the IESG announces an IETF-
wide last call. This helps get the attention of people who weren't
following the progress of the draft, and it can sometimes cause
further changes to the draft. It is also a time when people in the
WG who feel that they weren't heard can make their comments to
everyone. The IETF last call is two weeks for drafts coming from WGs
and four weeks for individual submissions.
If the IESG approves the draft to become an Internet standard, they
ask the RFC Editor to publish it as a Proposed standard. After it
has been a Proposed standard for at least six months, the RFC's
author (or the appropriate WG chair) can ask for it to become a Draft
standard. Before that happens, however, someone needs to convince
the appropriate Area Director that there are at least two
independent, interoperable implementations of each part of the
standard. This is a good test of the usefulness of the standard as a
whole, as well as an excellent way to check if the standard was
A few things typically happen at this point. First, it's common to
find that some of the specifications in the standard need to be
reworded because one implementor thought they meant one thing whereas
another implementor thought they meant something else. Another
common occurrence is that none of the implementations actually tried
to implement a few of the features of the standard; these features
get removed not just because no one tested them but also because they
Don't be surprised if a particular standard doesn't progress from
Proposed to Draft. In fact, most of the standards in common use are
Proposed standards and never move forward. This may be because no
one took the time to try to get them to Draft, or some of the
normative references in the standard are still at Proposed standard,
or it may be that everyone found more important things to do.
A few years after a document has been a Draft standard, it can become
an Internet standard, also known as "full standard" (it can happen in
as little as four months, but this is rare). This doesn't happen
often, and it is usually reserved for protocols that are absolutely
required for the Internet to function. The IESG goes over the
document with a fine-tooth comb and looks for evidence of widespread
deployment before making a Draft standard an Internet standard.
8.4.1. Telling It Like It Is -- Using MUST and SHOULD and MAY
Writing specifications that get implemented the way you want is a bit
of an art. You can keep the specification very short, with just a
list of requirements, but that tends to cause implementors to take
too much leeway. If you instead make the specification very wordy
with lots of suggestions, implementors tend to miss the requirements
(and often disagree with your suggestions anyway). An optimal
specification is somewhere in between.
One way to make it more likely that developers will create
interoperable implementations of standards is to be clear about
what's being mandated in a specification. Early RFCs used all kinds
of expressions to explain what was needed, so implementors didn't
always know which parts were suggestions and which were requirements.
As a result, standards writers in the IETF generally agreed to limit
their wording to a few specific words with a few specific meanings.
[STD3], "Requirements for Internet Hosts -- Application and Support",
written way back in 1989, had a short list of words that had appeared
to be useful, namely, "must", "should", and "may". These definitions
were updated and further refined in [BCP14], "Key words for use in
RFCs to Indicate Requirement Levels", which is widely referenced in
current Internet standards. BCP 14 also specifically defines "must
not" and "should not", and it lists a few synonyms for the words
In a standard, in order to make it clear that you're using the
definitions from BCP 14, you should do two things. First, refer to
BCP 14 (although most people refer to it as RFC 2119, because that's
what BCP 14 tells you to do), so that the reader knows how you're
defining your words. Second, you should point out which instances of
the words you are using come from BCP 14. The accepted practice for
this is to capitalize the words. That is why you see "MUST" and
"SHOULD" capitalized in IETF standards.
BCP 14 is a short document, and it should be read by everyone who is
reading or writing IETF standards. Although the definitions of
"must" and "must not" are fairly clear, the definitions of "should"
and "should not" cause a great deal of discussion in many WGs. When
reviewing an Internet Draft, the question is often raised, "Should
that sentence have a MUST or a SHOULD in it?" This is, indeed, a
very good question, because specifications shouldn't have gratuitous
MUSTs, but also should not have SHOULDs where a MUST is needed for
interoperability. This goes to the crux of the question of over-
specifying and under-specifying requirements in standards.
8.4.2. Normative References in Standards
One aspect of writing IETF standards that trips up many novices (and
quite a few long-time IETF folks) is the rule about how to make
"normative references" to non-IETF documents or to other RFCs in a
standard. A normative reference is a reference to a document that
must be followed in order to implement the standard. A non-normative
reference (sometimes called an "informative reference") is one that
is helpful to an implementor but is not needed.
An IETF standard may make a normative reference to any other
standards-track RFC that is at the same standards level or higher, or
to any "open standard" that has been developed outside the IETF. The
"same level or higher" rule means that before a standard can move
from Proposed to Draft, all of the RFCs for which there is a
normative reference must also be at Draft or Internet standard. This
rule gives implementors assurance that everything in a Draft standard
or Internet standard is quite stable, even the things referenced
outside the standard. This can also delay the publication of the
Draft or Internet standard by many months (sometimes even years)
while the other documents catch up.
There is no hard-and-fast rule about what is an "open standard", but
generally this means a stable standard that anyone can get a copy of
(although they might have to pay for it) and that was made by a
generally recognized standards group. If the external standard
changes, you have to reference the particular instantiation of that
standard in your specification, as with a designation of the date of
the standard. Some external standards bodies don't make old
standards available, which is a problem for IETF standards that need
to be used in the future. When in doubt, a draft author should ask
the WG chair or appropriate Area Director if a particular external
standard can be used in an IETF standard.
8.4.3. IANA Considerations
More and more IETF standards require the registration of various
protocol parameters, such as named options in the protocol. As we
noted in Section 3.2.4, the main registry for all IETF standards has
long been IANA. Because of the large and diverse kinds of registries
that standards require, IANA needs to have specific information about
how to register parameters, what not to register, who (if anyone)
will decide what is to be registered, and so on.
Anyone writing an Internet standard that may need a new IANA registry
or new values in a current IANA registry needs to read [BCP26],
"Guidelines for Writing an IANA Considerations Section in RFCs",
which describes how RFC authors should properly ask for IANA to start
or take over a registry. IANA also maintains registries that were
started long before BCP 26 was produced.
8.4.4. Security Considerations
One thing that's required in every RFC and Internet Draft is a
"Security Considerations" section. This section should describe any
known vulnerabilities of the protocol, possible threats, and
mechanisms or strategies to address them. Don't gloss over this
section -- in particular, don't say, "Here's our protocol, if you
want security, just use IPsec". This won't do at all, because it
doesn't answer the question of how IPsec interacts with your
protocol, and vice versa. Be sure to check with your Working Group
chair if you're not sure how to handle this section in your draft.
See [BCP72], "Guidelines for Writing RFC Text on Security
Considerations", for more information on writing good security
8.4.5. Patents in IETF Standards
The problems of intellectual property have cropped up more and more
often in the past few years, particularly with respect to patents.
The goal of the IETF is to have its standards widely used and
validated in the marketplace. If creating a product that uses a
standard requires getting a license for a patent, people are less
likely to implement the standard. Not surprisingly, then, the
general rule has been "use good non-patented technology where
Of course, this isn't always possible. Sometimes patents appear
after a standard has been established. Sometimes there's a patent on
something that is so valuable that there isn't a non-patented
equivalent. Sometimes the patent holder is generous and promises to
give all implementors of a standard a royalty-free license to the
patent, thereby making it almost as easy to implement as it would
have been if no patent existed.
The IETF's methods for dealing with patents in standards are a
subject of much debate. The official rules for all intellectual
property rights (IRP) in IETF documents (not just patents) are
covered in [BCP78] and [BCP79], "Intellectual Property Rights in IETF
Technology". Everyone who participates in IETF Working Groups will
probably find these documents interesting because they lay out the
rules that everyone agrees to follow.
Patent holders who freely allow their patents to be used by people
implementing IETF standards often get a great deal of goodwill from
the folks in the IETF. Such generosity is more common than you might
think. For example, RFC 1822 is a license from IBM for one of its
security patents, and the security community has responded very
favorably to IBM for this (whereas a number of other companies have
made themselves pariahs for their intractability on their security
If you are writing an Internet Draft and you know of a patent that
applies to the technology you're writing about, don't list the patent
in the document. Instead, consult the IETF IPR Disclosure Page
linked off the main IETF web site to determine how to proceed.
Intellectual property rights aren't mentioned in RFCs because RFCs
never change after they are published, but knowledge of IPR can
change at any time. Therefore, an IPR list in an RFC could be
incomplete and mislead the reader. [BCP9] provides specific text
that should be added to RFCs where the author knows of IPR issues.
8.5. Informational and Experimental RFCs
As we noted earlier, not all RFCs are standards. In fact, plenty of
important RFCs are not on the standards track at all. Currently,
there are two designations for RFCs that are not meant to be
standards: Informational, like the Tao, and Experimental. (There is
actually a third designation, Historic, but that is reserved for
documents that were on the standards track and have been removed due
to lack of current use, or that more recent thinking indicates the
technology is actually harmful to the Internet.)
The role of Informational RFCs is often debated in the IETF. Many
people like having them, particularly for specifications that were
created outside the IETF but are referenced by IETF documents. They
are also useful for specifications that are the precursors for work
being done by IETF Working Groups. On the other hand, some people
refer to Informational RFCs as "standards" even though the RFCs are
not standards, usually to fool the gullible public about something
that the person is selling or supporting. When this happens, the
debate about Informational RFCs is renewed.
Experimental RFCs are for specifications that may be interesting, but
for which it is unclear if there will be much interest in
implementing them, or whether they will work once deployed. That is,
a specification might solve a problem, but if it is not clear that
many people think that the problem is important, or think that they
will bother fixing the problem with the specification, the
specification might be labeled an Experimental RFC. If, later, the
specification becomes popular (or proves that it works well), it can
be re-issued as a standards-track RFC. Experimental RFCs are also
used to get people to experiment with a technology that looks like it
might be standards-track material, but for which there are still
The IESG has created guidelines on how it chooses between
Informational and Experimental status:
http://www.ietf.org/u/ietfchair/info-exp.html. If you are creating a
document that you think might become an Experimental RFC, knowing the
current thinking will help you justify your proposed choice.
9. How to Contribute to the IETF
9.1. What You Can Do
*Read* -- Review the Internet Drafts in your area of expertise and
comment on them in the Working Groups. Participate in the discussion
in a friendly, helpful fashion, with the goal being the best Internet
standards possible. Listen much more than you speak. If you
disagree, debate the technical issues: never attack the people.
*Implement* -- Write programs that use the current Internet
standards. The standards aren't worth much unless they are available
to Internet users. Implement even the "minor" standards, since they
will become less minor if they appear in more software. Report any
problems you find with the standards to the appropriate Working Group
so that the standard can be clarified in later revisions. One of the
oft-quoted tenets of the IETF is "running code wins", so you can help
support the standards you want to become more widespread by creating
more running code.
*Write* -- Edit or co-author Internet Drafts in your area of
expertise. Do this for the benefit of the Internet community, not to
get your name (or, even worse, your company's name) on a document.
Draft authors are subject to all kinds of technical (and sometimes
personal) criticism; receive it with equanimity and use it to improve
your draft in order to produce the best and most interoperable
9.2. What Your Company Can Do
*Share* -- Avoid proprietary standards. If you are an implementor,
exhibit a strong preference for IETF standards. If the IETF
standards aren't as good as the proprietary standards, work to make
the IETF standards better. If you're a purchaser, avoid products
that use proprietary standards that compete with the open standards
of the IETF and tell the companies you buy from that you are doing
*Open Up* -- If your company controls a patent that is used in an
IETF standard, convince the company to make the patent available at
no cost to everyone who is implementing the standard. In the past
few years, patents have caused a lot of serious problems for Internet
standards because they prevent some companies from being able to
freely implement the standards. Fortunately, many companies have
generously offered unlimited licenses for particular patents in order
to help the IETF standards flourish. These companies are usually
rewarded with positive publicity for the fact that they are not as
greedy or short-sighted as other patent-holders.
*Join* -- Become a member of ISOC. More important, urge any company
that has benefited from the Internet to become a corporate member of
ISOC, since this has the greatest financial benefit for the group.
It will, of course, also benefit the Internet as a whole.
10. IETF and the Outside World
10.1. IETF and Other Standards Groups
As much as many IETF participants would like to think otherwise, the
IETF does not exist in a standards vacuum. There are many (perhaps
too many) other standards organizations whose decisions affect the
Internet. There are also a fair number of standards bodies that
ignored the Internet for a long time and now want to get a piece of
In general, the IETF tries to have cordial relationships with other
significant standards bodies. This isn't always easy, since many
other bodies have very different structures than the IETF does, and
the IETF is mostly run by volunteers who would probably prefer to
write standards rather than meet with representatives from other
bodies. Even so, some other standards bodies make a great effort to
interact well with the IETF despite the obvious cultural differences.
At the time of this writing, the IETF has some liaisons with large
standards bodies, including the ITU (International Telecommunication
Union), the W3C, the Unicode Consortium, and ISO/IEC JTC1 (Joint
Technical Committee of the International Organization for
Standardization and International Electrotechnical Commission). As
stated in the IAB Charter [BCP39], "Liaisons are kept as informal as
possible and must be of demonstrable value in improving the quality
of IETF specifications". In practice, the IETF prefers liaisons to
take place directly at Working Group level, with formal relationships
and liaison documents in a backup role.
Some of these liaison tasks fall to the IESG, whereas others fall to
the IAB. Detail-oriented readers will learn much about the formal
methods for dealing with other standards bodies in [BCP102], "IAB
Processes for Management of IETF Liaison Relationships", and
[BCP103], "Procedures for Handling Liaison Statements to and from the
IETF". The best place to check to see whether the IETF has any
formal liaison at all is the list of IETF liaisons,
www.ietf.org/liaisonActivities.html. The list shows that there are
many different liaisons to ISO/IEC JTC1 subcommittees.
10.2. Press Coverage of the IETF
Given that the IETF is one of the best-known bodies that is helping
move the Internet forward, it's natural for the computer press (and
even the trade press) to want to cover its actions. In recent years,
a small number of magazines have assigned reporters and editors to
cover the IETF in depth over a long period of time. These reporters
have ample scars from articles that they got wrong, incorrect
statements about the status of Internet Drafts, quotes from people
who are unrelated to the IETF work, and so on.
Major press errors fall into two categories: saying that the IETF is
considering something when in fact there is just an Internet Draft in
a Working Group, and saying that the IETF approved something when all
that happened was that an Informational RFC was published. In both
cases, the press is not fully to blame for the problem, since they
are usually alerted to the story by a company trying to get publicity
for a protocol that they developed or at least support. Of course, a
bit of research by the reporters would probably get them in contact
with someone who could straighten them out, such as a WG chair or an
Area Director. The default press contact for the IETF is the IAD,
who can be reached at mailto:email@example.com.
The fact that those reporters who've gotten it wrong once still come
back to IETF meetings shows that it is possible to get it right
eventually. However, IETF meetings are definitely not for reporters
who are naive about the IETF process (although if you are a reporter
the fact that you are reading this document is a very good sign!).
Furthermore, if you think that you'll get a hot story from attending
an IETF meeting, you are likely to be disappointed.
Considering all this, it's not surprising that some IETFers would
prefer to have the press stay as far away from meetings as possible.
Having a bit of press publicity for protocols that are almost near
completion and will become significant in the industry in the next
year can be a good thing. However, it is the rare reporter who can
resist over-hyping a nascent protocol as the next savior for the
Internet. Such stories do much more harm than good, both for the
readers of the article and for the IETF.
The main reason why a reporter might want to attend an IETF meeting
is not to cover hot technologies (since that can be done in the
comfort of your office by reading the mailing lists) but to meet
people face-to-face. Unfortunately, the most interesting people are
the ones who are also the busiest during the IETF meeting, and some
folks have a tendency to run away when they see a press badge.
However, IETF meetings are excellent places to meet and speak with
document authors and Working Group chairs; this can be quite valuable
for reporters who are covering the progress of protocols.
Reporters who want to find out about "what the IETF is doing" on a
particular topic would be well-advised to talk to more than one
person who is active on that topic in the IETF, and should probably
try to talk to the WG chair in any case. It's impossible to
determine what will happen with a draft by looking at the draft or
talking to the draft's author. Fortunately, all WGs have archives
that a reporter can look through for recent indications about what
the progress of a draft is; unfortunately, few reporters have the
time or inclination to do this kind of research. Because the IETF
doesn't have a press liaison, magazines or newspapers that run a
story with errors won't hear directly from the IETF and therefore
often won't know what they did wrong, so they might easily do it
11. Security Considerations
Section 8.4.4 explains why each RFC is required to have a Security
Considerations section and gives some idea of what it should and
should not contain. Other than that information, this document does
not touch on Internet security.
Appendix A. Related Information
A.1. Why "the Tao"?
Pronounced "dow", Tao is the basic principle behind the teachings of
Lao-tse, a Chinese master. Its familiar symbol is the black-and-
white yin-yang circle. Taoism conceives the universe as a single
organism, and human beings as interdependent parts of a cosmic whole.
Tao is sometimes translated "the way", but according to Taoist
philosophy the true meaning of the word cannot be expressed in words.
A.2. Useful Email Addresses
Some useful email addresses are listed here. These addresses may
change from time to time, and it's a good idea to check the IETF web
pages for the correct address before sending your mail.
firstname.lastname@example.org Requests for agenda slots at IETF
email@example.com Requests for things to be done when you
don't know exactly where to send the
firstname.lastname@example.org General questions about the IETF
email@example.com Questions about registration, meeting
locations, and fees
firstname.lastname@example.org Requests to join/leave IETF lists
email@example.com Questions for the Secretariat
firstname.lastname@example.org Questions or comments about the IETF
email@example.com Internet Draft submissions and queries
firstname.lastname@example.org Where to send Working Group minutes and
slides for the IETF Proceedings
email@example.com Internet Assigned Numbers Authority
firstname.lastname@example.org RFC Editor
email@example.com Incoming liaison statements from other
Online upload pages are planned for the future to facilitate
submission of Internet Drafts, Proceedings, and Liaison statements.
A.3. Useful Documents and Files
The IETF web site, http://www.ietf.org, is the best source for
information about meetings, Working Groups, Internet Drafts, RFCs,
IETF email addresses, and much more. Click on "Additional
Information" to find a variety of helpful links. Internet Drafts and
other documents are also available in the "ietf" directory on
anonymous FTP sites worldwide. For a listing of these sites, see
Check the IESG web pages, http://www.ietf.org/iesg.html, to find up-
to-date information about drafts processed, RFCs published, and
documents in Last Call, as well as the monthly IETF status reports.
A.4. Acronyms and Abbreviations Used in the Tao
Some of the acronyms and abbreviations from this document are listed
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
FAQ Frequently Asked Question(s)
FYI For Your Information (RFC)
IAB Internet Architecture Board
IAD IETF Administrative Director
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and
I-D Internet Draft
IESG Internet Engineering Steering Group,
IETF Internet Engineering Task Force,
INET Internet Society Conference,
IPR Intellectual property rights
IRTF Internet Research Task Force, http://www.irtf.org/
ISO International Organization for Standardization,
ISO-IEC/JTC1 Joint Technical Committee of the International
Organization for Standardization and
International Electrotechnical Commission,
ISOC Internet Society, http://www.isoc.org
ITU International Telecommunication Union,
RFC Request for Comments
STD Standard (RFC)
W3C World Wide Web Consortium, http://www.w3.org/
WG Working Group
Appendix B. IETF Guiding Principles
If you've gotten this far in the Tao, you've learned a lot about how
the IETF works. What you'll find in this appendix summarizes much of
what you've read and adds a few new points to ponder. Be sure to
read through all the principles; taken as a whole, they'll give you a
new slant on what makes the IETF work.
P1. The IETF works by an open process and by rough consensus. This
applies to all aspects of the operation of the IETF, including
creation of IETF documents and decisions on the processes that
are used. But the IETF also observes experiments and running
code with interest, and this should also apply to the
operational processes of the organization.
P2. The IETF works in areas where it has, or can find, technical
P3. The IETF depends on a volunteer core of active participants.
P4. Membership of the IETF or of its WGs is not fee-based or
organizationally defined, but is based upon self-identification
and active participation by individuals.
B.2. Management and Leadership
P5. The IETF recognizes leadership positions and grants power of
decision to the leaders, but decisions are subject to appeal.
P6. Delegation of power and responsibility are essential to the
effective working of the IETF. As many individuals as possible
will be encouraged to take on leadership of IETF tasks.
P7. Dissent, complaint, and appeal are a consequence of the IETF's
nature and should be regarded as normal events, but ultimately
it is a fact of life that certain decisions cannot be
P8. Leadership positions are for fixed terms (although we have no
formal limitation on the number of terms that may be served).
P9. It is important to develop future leaders within the active
P10. A community process is used to select the leadership.
P11. Leaders are empowered to make the judgment that rough
consensus has been demonstrated. Without formal membership,
there are no formal rules for consensus.
P12. Although the IETF needs clear and publicly documented process
rules for the normal cases, there should be enough flexibility
to allow unusual cases to be handled according to common sense.
We apply personal judgment and only codify when we're certain.
(But we do codify who can make personal judgments.)
P13. Technical development work should be carried out by tightly
chartered and focused Working Groups.
P14. Parts of the process that have proved impractical should be
removed or made optional.
B.4. Working Groups
P15. Working Groups (WGs) should be primarily responsible for the
quality of their output, and therefore for obtaining early
review; WG chairs as WG leaders, backed up by the IETF
leadership, should act as a quality backstop.
P16. WGs should be primarily responsible for assessing the negative
impact of their work on the Internet as a whole, and therefore
for obtaining cross-area review; the IETF leadership should act
as a cross-area backstop.
P17. Early review of documents is more effective in dealing with
major problems than late review.
P18. Area Directors (ADs) are responsible for guiding the formation
and chartering of WGs, for giving them direction as necessary,
and for terminating them.
P19. WG chairs are responsible for ensuring that WGs execute their
charters, meet their milestones, and produce deliverables that
are ready for publication.
P20. ADs are responsible for arranging backstop review and final
P21. IETF documents often start as personal drafts, may become WG
drafts, and are approved for permanent publication by a
leadership body independent of the WG or individuals that
P22. IETF documents belong to the community, not to their authors.
But authorship is recognized and valued, as are lesser
contributions than full authorship.
P23. Technical quality and correctness are the primary criteria for
reaching consensus about documents.
P24. IETF specifications may be published as Informational,
Experimental, Standards Track, or Best Current Practice.
P25. IETF Standards Track specifications are not considered to be
satisfactory standards until interoperable independent
implementations have been demonstrated. (This is the
embodiment of the "running code" slogan.) But, on legal
advice, the IETF does not take responsibility for
interoperability tests and does not certify interoperability.
P26. IETF processes are currently published as Best Current Practice
P27. Useful information that is neither a specification nor a
process may be published as Informational.
P28. Obsolete or deprecated specifications and processes may be
downgraded to Historic.
P29. The standards track should distinguish specifications that have
been demonstrated to interoperate.
P30. Standards Track and Best Current Practice documents must be
subject to IETF wide rough consensus (Last Call process). WG
rough consensus is normally sufficient for other documents.
P31. Substantive changes made after a document leaves a WG must be
referred back to the WG.
P32. The IETF determines requirements for publication and archiving
of its documents.
[BCP9] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[BCP10] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP22] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP25] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
[BCP39] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
[BCP45] Harris, S., "IETF Discussion List Charter", BCP 45, RFC
3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
[BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3978, March 2005.
[BCP79] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., "A Mission Statement for the IETF", BCP
95, RFC 3935, October 2004.
[BCP101] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, RFC
4071, April 2005.
[BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes
for Management of IETF Liaison Relationships", BCP 102,
RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF", BCP
103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
Standards", RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[STD3] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
127 Segre Place
Santa Cruz, CA 95060
1722 Chandler Road
Ann Arbor, MI 48104
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).