Network Working Group S. Moonesamy
Internet-Draft
Intended Status: Informational
Expires: December 11, 2012 June 9, 2012
The Internet Engineering Task Force: A guide for newcomers
draft-moonesamy-ietf-newcomers-00
Abstract
This document describes the inner workings of Internet Engineering
Task Force (IETF). It is an informal guide for newcomers to the
IETF.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Moonesamy Expires December 11, 2012 [Page 1]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials,this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. About this document . . . . . . . . . . . . . . . . . . . . 4
2. What Is the IETF . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Note Well . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Internet Architecture Board (IAB) . . . . . . . . . . . . . 5
3.2. Internet Engineering Steering Group (IESG) . . . . . . . . 5
3.2.1. Working Groups . . . . . . . . . . . . . . . . . . . . 6
3.4 Internet Research Task Force (IRTF) . . . . . . . . . . . . 7
4. Participating in the IETF . . . . . . . . . . . . . . . . . . . 7
4.1. IETF Mailing Lists . . . . . . . . . . . . . . . . . . . . 8
5. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Planning your week . . . . . . . . . . . . . . . . . . . . 10
5.3.1. Dress Code . . . . . . . . . . . . . . . . . . . . . . 11
5.3.2. Social Event . . . . . . . . . . . . . . . . . . . . . 11
5.3.3. Working Group Sessions . . . . . . . . . . . . . . . . 11
5.3.4. Birds of a Feather (BOF) . . . . . . . . . . . . . . . 12
5.4. Proceedings . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Where Do I Fit In . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Newcomers . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. IT Managers . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Network Operators and ISPs . . . . . . . . . . . . . . . . 14
6.4. Networking Hardware and Software Vendors . . . . . . . . . 15
6.5. Academics . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Press Coverage . . . . . . . . . . . . . . . . . . . . . . 15
7. Getting an RFC Published . . . . . . . . . . . . . . . . . . . 16
7.1. Letting Go Gracefully . . . . . . . . . . . . . . . . . . . 17
7.2. Internet-Draft . . . . . . . . . . . . . . . . . . . . . . 18
7.2.1 Internet-Draft Names . . . . . . . . . . . . . . . . . . 18
Moonesamy Expires December 11, 2012 [Page 2]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
7.2.2. Writing an Internet-Draft . . . . . . . . . . . . . . . 19
7.2.2.1. Security Considerations . . . . . . . . . . . . . . 20
7.2.2.2. IANA Considerations . . . . . . . . . . . . . . . . 20
7.2.3. Submitting an Internet-Draft . . . . . . . . . . . . . 20
7.2.4. Last Call . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.5. IESG Evaluation . . . . . . . . . . . . . . . . . . . . 21
8. Administrative Support . . . . . . . . . . . . . . . . . . . . 21
8.1. IETF Administrative Support Activity . . . . . . . . . . . 21
8.2. IETF Secretariat . . . . . . . . . . . . . . . . . . . . . 21
9. Organizational Relationships . . . . . . . . . . . . . . . . . 22
9.1. IETF Trust . . . . . . . . . . . . . . . . . . . . . . . . 22
9.2. Internet Society . . . . . . . . . . . . . . . . . . . . . 22
9.3. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . 22
9.4. Internet Assigned Numbers Authority (IANA) . . . . . . . . 22
9.5. Liaisons between the IETF and other Standards
Organizations . . . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acronyms and Abbreviations Used . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Background
The first IETF meeting was held in January 1986 at Linkabit in San
Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in
October 1986, was the first that vendors attended. The concept of
Working Groups was introduced at the 5th IETF meeting at the NASA
Ames Research Center in California in February 1987. The 7th IETF,
held at MITRE in McLean, Virginia, in July 1987, was the first
meeting with more than 100 attendees. The 14th IETF meeting was held
at Stanford University in July 1989. It marked a major change in the
structure of the IETF.
The structure of the IAB (then the Internet Activities Board, now the
Internet Architecture Board), which until that time oversaw many
"task forces", was changed, leaving it with only two: the IETF and
the IRTF. The IRTF is tasked to consider long-term research problems
in the Internet. The IETF also changed at that time.
After the Internet Society (ISOC) was formed in January 1992, the IAB
proposed to ISOC that the IAB's activities should take place under
the auspices of the Internet Society. During INET92 in Kobe, Japan,
the ISOC Trustees approved a new charter for the IAB to reflect the
proposed relationship.
The IETF met in Amsterdam, The Netherlands, in July 1993. This was
the first IETF meeting held in Europe, and the US/non-US attendee
Moonesamy Expires December 11, 2012 [Page 3]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
split was nearly 50/50. The IETF first met in Asia (in Adelaide,
Australia) in 2000.
1.1. About this document
Attendance at the Internet Engineering Task Force (IETF) meetings has
grown phenomenally since the early years. When the meetings were
small, it was relatively easy for a newcomer to understand how the
IETF works. Nowadays a newcomer meets many more new people, some
previously known only as the authors of documents or through email
messages. This document describes several aspects of the IETF with
the goal of explaining to newcomers how the IETF works. The acronyms
and abbreviations used in this document are expanded in place and are
explained in Appendix A. The RFCs cited as references provide more
details about the IETF.
2. What Is the IETF
The IETF is not a traditional standards organization although many
specifications that are produced become standards [RFC2026][RFC6410].
The IETF is unusual in that it is not registered as an organization
or incorporated in any country. It does not have members or a board
of directors. The IETF is open to anyone; it does not charge any
fees or has any requirements for participation. The closest thing
there is to being an IETF member is by participating in the
discussions on the IETF mailing lists.
The IETF is made up of volunteers, many of whom meet three times a
year at IETF meetings. Anyone may register for a meeting and then
attend. Many of the attendees are new to the IETF at each meeting.
Some of those go on to become regular attendees.
The goal of the IETF is to make the Internet work better. The
Mission Statement documented in RFC 3935 [RFC3935] describes what the
IETF is trying to achieve. The IETF in no way runs the Internet. The
IETF makes voluntary standards which are often adopted by Internet
users.
A summary of the IETF work and events of the last day is available at
https://tools.ietf.org/dailydose/
2.1. Note Well
The "Note Well" (see http://www.ietf.org/about/note-well.html ) lays
out the rules for IETF process and intellectual property rights. You
should read it carefully because you are deemed to agree to the "Note
Well" by participating in the IETF.
Moonesamy Expires December 11, 2012 [Page 4]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
3. Hierarchy
3.1. Internet Architecture Board (IAB)
The IAB [RFC2850] is responsible for keeping an eye on the "big
picture" of the Internet. The IAB stays informed about important
long-term issues in the Internet. It brings these topics to the
attention of people it thinks should know about them. IAB members
are selected for two-year positions by the IETF community.
The IAB focuses on long-range planning and coordination among the
various areas of IETF activity. It pays special attention to
emerging activities in the IETF. When a new IETF Working Group is
proposed, the IAB reviews its charter for architectural consistency
and integrity. Even before the group is chartered, IAB members
discuss new ideas with the people proposing them.
The IAB sponsors and organizes the Internet Research Task Force and
convenes invitational workshops that provide in-depth reviews of
specific Internet architectural issues. Typically, the workshop
reports make recommendations to the IETF community and to the
Internet Engineering Steering Group (IESG). The IAB also approves the
nominations of IESG members and acts acts as the appeals board for
appeals against IESG.
3.2. Internet Engineering Steering Group (IESG)
The IESG [RFC3710] is responsible for technical management of IETF
activities and the Internet standards process. It administers the
process. The IESG doesn't exercise much direct leadership, such as
the kind you will find in many other standards organizations. As its
name suggests, its role is to set directions rather than to give
orders. The IESG gets IETF Working Groups (WGs) started and finished
and makes sure that the Internet-Drafts that are about to become IETF
RFCs are correct.
The IESG consists of the Area Directors (ADs) appointed for two
years. The process for choosing the members of the IAB and IESG is
detailed in RFC 3777 [RFC3777]. The current Areas and abbreviations
are shown below.
Area Description
-----------------------------------------------------------------
Applications (APP) Protocols seen by user programs such as
email and the web
General (GEN) IETF process and catch-all for WGs that
don't fit in other Areas (which is
Moonesamy Expires December 11, 2012 [Page 5]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
rare)
Internet (INT) Different ways of moving IP packets and
DNS information
Operations and Operational aspects, network monitoring,
Management (OPS) and configuration
Real-time Delay-sensitive interpersonal
Applications and communications
Infrastructure (RAI)
Routing (RTG) Getting packets to their destinations
Security (SEC) Authentication and privacy
Transport (TSV) Special services for special packets
The IESG has a great deal of influence on whether Internet-Drafts
become RFCs. IETF participants sometimes reverently ask Area
Directors for their opinion on a particular subject. When asked for
specific technical comments the Area Directors often defer to IETF
participants whom they feel have more knowledge than they do on that
topic.
The entire IESG reviews each Internet-Draft that is proposed to
become a RFC to help avoid having IETF protocols which are at odds
with each other. For example, the result of one Working Group might
clash with a technology developed in a Working Group from another
Area. The Area Directors for a particular Area are expected to know
more about the combined work of the Working Groups in that Area than
anyone else. The IESG usually moves in a reactive fashion because of
its high workload.
3.2.1. Working Groups
The vast majority of the IETF's work is done in many Working Groups
[RFC2418]; at the time of this writing, there are about 115 different
Working Groups. Each Working Group has one or two chairs.
A Working Group is really just a mailing list (see
https://datatracker.ietf.org/wg/ ). Anyone can join the Working
Group by subscribing to the mailing list. Each Working Group has a
charter that the Working Group is supposed to follow. The charter
states the scope of discussion for the Working Group, as well as its
goals. The Working Group's mailing list and face-to-face meetings
are supposed to focus on just what is in the charter and not to
Moonesamy Expires December 11, 2012 [Page 6]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
wander off on other topics. The large majority of the discussion
should be on the topics listed in the charter. Some Working Group
charters specify what the Working Group will not do, particularly if
there were some attractive but nebulous topics brought up during the
drafting of the charter.
The IESG usually approves most Working Group requests for Internet-
Drafts to be published as RFCs. It may step in when something has
gone wrong. The quality of the IETF standards comes both from the
review they get in a Working Group and the scrutiny that they gets
from the IESG.
3.4 Internet Research Task Force (IRTF)
The Internet Research Task Force (IRTF) [RFC2014] has responsibility
for organizing groups to investigate research topics related to the
Internet protocols, applications, and technology. The products of a
Research Group are research results that may be disseminated by
publication in scholarly journals and conferences, as white papers
for the community or as Informational RFCs.
4. Participating in the IETF
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 and helpful manner with the goal of improving the
proposal. 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 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. You can
help the development of protocols before they become standards by
implementing (but not deploying) from I-Ds to ensure that the authors
have done a good job. If you find errors or omissions, offer
improvements based on your implementation experience.
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. Authors of
Internet-Drafts 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
Moonesamy Expires December 11, 2012 [Page 7]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
standard.
4.1. IETF Mailing Lists
The IETF announcement mailing list (see
https://www.ietf.org/mailman/listinfo/IETF-Announce ) is where all
important information, RFC announcements and Last Calls are sent.
The is IETF general discussion list (see
https://www.ietf.org/mailman/listinfo/ietf ) where IETF participants
comment about Internet-Drafts going through Last Call. Non-
subscribers may have their postings to an IETF mailing list delayed
until the messages are approved by the mailing list moderator.
The IETF general discussion list is unmoderated. IETF participants
generally post messages to it to express their opinions about issues
affecting the IETF or the Internet. The IETF general discussion list
is not a place for companies or individuals to solicit or advertise,
as noted in the IETF Discussion List Charter [RFC3005]. The list
have two "sergeants at arms" who keep an eye open for inappropriate
postings. There is a process for banning persistent offenders from
the list, but fortunately this is extremely rare.
The IETF mailing lists represent the IETF participants at large. It
is important to note that attending an IETF meeting does not mean
you'll be automatically added to IETF mailing lists. It is worth
noting that neither attendee names and addresses nor IETF mailing
lists are ever offered for sale.
5. IETF Meetings
The computer industry is rife with conferences, seminars,
expositions, and all manner of other kinds of meetings. IETF face-
to-face meetings are nothing like these. The meetings, held three
times a year, are week-long gatherings whose primary goal is to
reinvigorate the Working Groups to get their tasks done, and whose
secondary goal is to promote a fair amount of mixing between the
Working Groups and the Areas. The cost of the meetings is paid by
the people attending and by the corporate host for each meeting.
IETF meetings are of little interest to sales and marketing folks,
but of high interest to engineers and developers.
The general flow of an IETF meeting is that it begins with tutorials
and an informal gathering on Sunday, and that there are WG and BoF
sessions from Monday to Friday. A WG session lasts between one to
two and a half hours. Some WGs have several sessions during the
week.
Moonesamy Expires December 11, 2012 [Page 8]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
There are two plenary sessions, one technical and one administrative,
in the evenings during the week. The technical plenary is organized
by the IAB and usually has one or two panels of experts on topics of
interest across many WGs and Areas. The administrative plenary,
organized by the IETF Chair, covers things like progress reports from
the RFC Editor and announcements of upcoming meetings. The plenaries
are a good time to share with the IESG and IAOC. Praise is welcome.
It is more often a venue for people to raise their concerns or
complain about the IETF.
The IETF meets in North America, Europe and Asia approximately once a
year in each region. The past few meetings have had about 1,200
attendees. There have been more than 83 IETF meetings so far, and a
list of upcoming meetings is available on the IETF web pages,
http://www.ietf.org/meeting/upcoming.html.
Newcomers to IETF face-to-face meetings are often in a bit of shock.
They expect them to be like other standards bodies or like computer
conferences. Fortunately, the shock wears off after a day or two,
and many new attendees get quite animated about how much fun they are
having. Some IETF participants can be surprisingly rude, such as
talking loudly during functions when someone is speaking at the
microphone or pushing through a crowd to get to food or drinks. This
type of anti-social behavior seems to be more common at IETF meetings
than at computer conferences. Newcomers should be patient with the
old folks; these folks sometimes provide good advice.
One particular feature of IETF meetings is the use of wireless
Internet connections throughout the meeting space. It is common to
see people in a Working Group meeting apparently reading email or
perusing the web during presentations they find boring. Sometimes
they may be consulting the drafts under discussion, looking up
relevant material online or following another WG meeting using
instant messaging.
5.1. Registration
To attend an IETF meeting, you have to register and pay a
registration fee. The meeting site and advance registration are
announced about two months ahead of the meeting. An announcement
goes out via email to the IETF-announce mailing list, and information
is posted on the IETF web site, http://www.ietf.org, that same day.
You can register and pay on the web before the meeting or in person
at the meeting. To get a lower registration fee, you must pay by the
early registration deadline (about one week before the meeting). The
registration fee covers all of the week's sessions, the Sunday
evening welcome reception (cash bar), daily continental breakfasts,
Moonesamy Expires December 11, 2012 [Page 9]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
and afternoon beverage and snack breaks.
Registration is open throughout the week of the meeting. It is
highly recommended that attendees arrive for early registration,
usually beginning at noon on Sunday and continuing throughout the
Sunday evening reception. The reception is a popular event where you
can get a small bite to eat and socialize with other early arrivals.
If you need to leave messages for other attendees, you can do so at
the cork boards that are often near the registration desk. These
cork boards will also have last-minute meeting changes and room
changes. You can also turn in lost-and-found items to the
registration desk. At the end of the meeting, anything left over
from the lost-and-found will usually be turned over to the hotel or
brought back to the IETF Secretariat's office.
The IETF registration desk is often a convenient place to arrange to
meet people. If someone says "meet me at registration", you should
clarify if they mean the IETF registration desk, or the hotel
registration desk. This has been a common cause of missed
connections.
5.2. Agenda
The agenda for the IETF meetings is a very fluid thing. It is
available on the web starting a few weeks before the meeting. Some
Working Groups meet multiple times during a meeting.
The final agenda is simply the version that went to the printer. A
map showing the room locations are also shown on the agenda
distributed at the meeting. Room assignments can change as the
agenda changes. The Secretariat will post agenda changes on the
bulletin board near the IETF registration desk (not the hotel
registration desk).
5.3. Planning your week
IETF Working Group sessions are scheduled from Monday morning through
Friday afternoon. It is best to plan to be present the whole week,
to benefit from cross-fertilization between Working Groups and from
hallway discussions. As noted below, the agenda is fluid, and there
have been many instances of participants missing important sessions
due to last-minute scheduling changes after their travel plans were
fixed. Being present the whole week is the only way to avoid this
annoyance.
If you cannot find meetings all week to interest you, you can still
make the most of the IETF meeting by working between sessions. Most
Moonesamy Expires December 11, 2012 [Page 10]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
IETF attendees carry laptop computers. It is common to see many in
the hallways working during meeting sessions. There is often good
wireless Internet coverage in many places of the meeting venue
(restaurants, coffee shops, and so on), so catching up on email when
not in meetings is a fairly common task for IETFers.
5.3.1. Dress Code
Many newcomers are often embarrassed when they show up Monday morning
in suits, to discover that everybody else is wearing T-shirts, jeans
(shorts, if weather permits) and sandals. The general rule is "dress
for the weather" (unless you plan to work so hard that you won't go
outside, in which case, "dress for comfort" is the rule).
People attending an IETF meeting usually wear a name tag. Members of
the press wear orange-tinted badges. Some people have a little
colored dot on their name tag. A few people have more than one.
These dots identify people who have volunteered to do a lot of extra
work. The colors have the meanings shown below.
Color Meaning
--------------------------------------
Blue Working Group/BOF chair
Green Host group
Red IAB member
Yellow IESG member
Orange Nominating Committee member
Purple IAOC
Pink IRSG member
Teal RSE
Local hosts are the people who can answer questions about restaurants
and points of interest in the area.
5.3.2. Social Event
The social event is sometimes high-tech-related event, or it might be
in an art museum or a reception hall. Not all IETF meetings have
social events. The social event is designed to give people a chance
to meet on a social rather than technical level. Everyone is
encouraged to wear their name tags and leave their laptops behind.
5.3.3. Working Group Sessions
The heart of an IETF meeting is the Working Group sessions. Different
WGs chairs have very different styles, so it is impossible to
generalize how a WG meeting will feel. Even though nearly all WGs
have agendas for their meetings, some meetings stick tightly to their
Moonesamy Expires December 11, 2012 [Page 11]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
agenda while others are run more loosely.
There are a few important things that are true for all WG sessions at
an IETF meeting. Near the beginning of the meeting, the chair will
pass around the "blue sheets", which are paper forms on which
everyone prints their name and puts their email address. These are
used for long-term archival purpose to show how many people came to a
particular meeting and, in rare cases, exactly who showed up. The
normal etiquette is to watch where the blue sheets came from and to
pass them along in the same direction.
When speaking in a meeting, you should always go to the microphones
in the room. For controversial topics, there will be a line at the
mic, but do not hesitate to be the first person at the mic if you
have a question or a contribution to the discussion. The WG chair or
presenter will indicate when you can speak. Although it would be
easier to just raise your hand from where you are sitting, the mics
perform a very useful task: they let the people listening remotely
and in the room hear your question or comment. It is also expected
that you will say your name at the mic so that the person taking
minutes will know who is speaking.
IETF procedures require all decisions to be confirmed "on the list"
and you will often hear a Working Group chair say, "Let's take it to
the list" to close a discussion.
5.3.4. Birds of a Feather (BOF)
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. A 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 sessions 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
Moonesamy Expires December 11, 2012 [Page 12]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
Internet-Drafts already in process, whereas others start from
scratch.
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
document.
Some 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. Only two meetings of a BOF can
be scheduled on a particular subject; either a WG has to form or the
topic should be dropped.
5.4. Proceedings
IETF proceedings are compiled two months after each meeting and are
available on the web. Be sure to look through a copy - the
proceedings are filled with information about IETF that you're not
likely to find anywhere else. For example, you'll find snapshots of
most WG charters at the time of the meeting, giving you a better
understanding of the evolution of any given effort.
The proceedings sometimes start with an informative message. Each
volume contains the final (hindsight) agenda, an IETF overview, Area
and Working Group reports, and slides from the protocol and technical
presentations. The Working Group reports and presentations are
sometimes incomplete, if the materials haven't been turned in to the
Secretariat in time for publication.
An attendee list is also included, which contains names and
affiliations as provided on the registration form. For information
about obtaining copies of the proceedings, see the web listing at
http://www.ietf.org/meeting/proceedings.html.
6. Where Do I Fit In
The IETF is different things to different people. There are many
people who have been very active in the IETF who have never attended
an IETF meeting. Some people attend an IETF meeting to get a feel
for the IETF. The following guidelines (based on stereotypes of
people in various industries) might help you decide whether you
actually want to come and, if so, what might be the best use of your
Moonesamy Expires December 11, 2012 [Page 13]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
time at your first meeting.
6.1. Newcomers
Newcomers are encouraged to attend the Newcomer's Orientation on
Sunday afternoon which is designed for first-time attendees. The
orientation is intended to provide introductory information about the
IETF. The session covers the structure of the IETF and how the IETF
works.
Later in the afternoon is the Newcomer's Meet and Greet, which is
only open to newcomers and WG chairs. This is a great place to try
to find people knowledgeable in the areas in which you are
interested. Feel free to approach any Working Group chair, not just
those in your area, to either learn about their Working Group or to
have them help find you someone in yours.
Newcomers to the IETF not be afraid to strike up conversations with
people who have dots on their name tag. If the IAB and IESG members
and Working Group and BOF chairs didn't want to talk to anybody, they
wouldn't be wearing the dots in the first place.
IETF meetings are usually intense times for Area Directors. Talking
to an Area Director during an IETF meeting will often lead to a
request to send her or him email about two weeks later. When you
start a hallway conversation with an Area Director (or even a Working
Group chair, for that matter), it is often good to give them about 30
seconds of context for the discussion.
6.2. IT Managers
An IETF meeting is not the places to go if your intention is to find
out what will be hot in the Internet industry next year. You can
safely assume that going to Working Group meetings will confuse you
more than it will help you understand what is happening, or will be
happening, in the industry.
As an IT manager you might want to consider sending specific people
who are responsible for technologies that are under development in
the IETF. As these people read the current Internet-Drafts and the
messages on the relevant Working Group lists, they will get a sense
of whether or not their presence would be worthwhile for your company
or for the Working Groups.
6.3. Network Operators and ISPs
Running a network is hard enough without having to grapple with new
protocols or new versions of the protocols with which you are already
Moonesamy Expires December 11, 2012 [Page 14]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
dealing. If you work for the type of network that is always using
the very latest hardware and software, and you are following the
relevant Working Groups, you could certainly find participating in
the IETF valuable. A fair amount of IETF work also covers many other
parts of operations of ISPs and large enterprises, and the input of
network operators is quite valuable to keep this work vibrant and
relevant. Many of the best operations documents from the IETF come
from real-world operators, not vendors and academics.
6.4. Networking Hardware and Software Vendors
The image of the IETF being mostly ivory tower academics may have
been true in the past, but the jobs of typical attendees are now in
industry. In most areas of the IETF, employees of vendors are the
ones writing the protocols and leading the Working Groups. If you
create Internet hardware or software, and no one from your company
has ever attended an IETF meeting, it behooves you to come to a
meeting if for no other reason than to tell the others how relevant
the meeting was or was not to your business.
It isn't likely useful, for everyone from a technical department to
go, particularly if they are not all reading the Internet-Drafts and
following the Working Group mailing lists. Many companies have just
a few designated meeting attendees who are chosen for their ability
to do complete and useful trip reports. In addition, many companies
have internal coordination efforts and a standards strategy. If a
company depends on the Internet for some or all of its business, the
strategy should probably cover the IETF.
6.5. Academics
IETF meetings are often excellent places for computer science folks
to find out what is happening in the way of soon-to-be-deployed
protocols. Professors and grad students (and sometimes overachieving
undergraduates) who are doing research in networking or
communications can get a wealth of information by following Working
Groups in their specific fields of interest. Wandering into
different Working Group meetings can have the same effect as going to
symposia and seminars in your department. Academics and Researchers
are likely to be interested in IRTF activities (see
http://www.irtf.org/ ).
6.6. Press Coverage
Given that the IETF is one of the best-known bodies that is helping
move the Internet forward, it's normal for the computer press (and
even the trade press) to want to cover its actions. A small number
of magazines have assigned reporters and editors to cover the IETF in
Moonesamy Expires December 11, 2012 [Page 15]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
depth over a long period of time. The default press contact for the
IETF is the IETF Administrative Director (IAD), who can be reached at
<mailto:iad@ietf.org>.
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. 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.
Press errors can occur by saying that the IETF is considering
something when in fact there is only an Internet-Draft. It's
impossible to determine what will happen with a draft by looking at
the draft or talking to the author of the draft. The press is not
fully to blame for the mistake 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. 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.
They should try to talk to the WG chair or Area Director in any
case.
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 rare that a reporter can
resist over-hyping a nascent protocol as the next big thing for the
Internet. Such stories do much more harm than good, both for the
readers of the article and for the IETF.
7. Getting an RFC Published
One of the most common questions seasoned IETF participants 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. Very few people get through the process unscathed
though.
One of the first things you must decide is whether you want your
document to be considered in a Working Group, of you want it to be
considered as an individual (that is, non-WG) submission to the IETF.
Even though most IETF standards come from Working Groups, some are
Moonesamy Expires December 11, 2012 [Page 16]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
individual efforts: there might be no appropriate Working Group, or a
potentially-appropriate Working Group might be to busy on other work
to consider your idea.
Every IETF standard, published as an RFC (Request for Comments),
starts out as an Internet-Draft (often called an "I-D" or just
"draft"). The basic steps for getting something published as an IETF
standard are as follows:
1. Submit the document as an Internet-Draft
2. Convince IETF participants to review and 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 sponsor the draft (if it's an
individual submission). If the draft is an official Working
Group product, the WG chair will help you with the publication
process.
6. If the Area Director accepts to sponsor the draft, he or she
will do an initial review, and maybe ask for updates before
they move it forward.
7. Discuss concerns with the IESG members. Their concerns might
be resolved with a simple answer or they might require
additions or changes to the document.
7.1. Letting Go Gracefully
Some people do not understand that is that they must give up change
control of the protocol for it to be published as a RFC. 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.
The change control on Internet standards doesn't end when the
Moonesamy Expires December 11, 2012 [Page 17]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
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 implementers 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 ideas
of their authors, nor do they exist so that a company can say, "We
have an IETF standard". If a RFC only has one implementation
(whereas two are required for it to advance on the standards track),
it was probably a mistake to publish it in the first place.
7.2. Internet-Draft
Internet-Drafts are tentative documents. They are meant for readers
to comment on. The author decides which comments to incorporate in
the draft. Internet-Drafts automatically expire from the six months.
A person who doesn't understand RFCs (or is intentionally trying to
fool people) may brag 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 BCP 78 [RFC5378], "IETF
Rights in Contributions". Note that authors cannot take someone
else's document and pass it off as their own; see BCP 78, section
5.6, point (a).
7.2.1 Internet-Draft Names
There are some informal rules for Internet-Draft naming that have
evolved over the years. The author's name is used as part of the
filename. 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-author-rfc2345bis-00.txt".
If an Internet-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 GROW WG about BGP might be named "draft-ietf-
grow-bgp-00.txt". If it is 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". After
the first revision of a draft, the number in the filename is
incremented; for instance, the second edition of the GROW draft named
above would be "draft-smith-grow-bgp-01.txt".
Moonesamy Expires December 11, 2012 [Page 18]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
The filename changes after one or more versions, such as when a
personal effort is adopted as a Working Group draft; when a draft has
its filename changed, the number reverts to -00. The WG chairs will
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.
7.2.2. Writing an Internet-Draft
It is important that multiple readers and implementers of a standard
have the same understanding of a document. To this end, information
should be orderly and detailed. The reader is more likely to have
general networking knowledge and experience rather than expertise in
a particular protocol. An explanation of the protocol and its use
will give the reader a reference point for understanding the protocol
and where it fits in the Internet. The "Guide for Internet Standards
Writers" [RFC2360] 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.
An Internet-Draft does not need to look exactly like an RFC. If you
follow the I-D guidelines given at http://www.ietf.org/ietf/1id-
guidelines.txt, chances are quite good that your draft will be fine.
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.
The "Key words for use in RFCs to Indicate Requirement Levels" are
defined in RFC 2119 [RFC2119].
An Internet-Draft may contain two types of references; normative and
informative. A normative reference is a reference to a document that
must be followed in order to implement the standard. A informative
reference is one that is helpful to an implementer 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.
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. Read the IETF IPR page at http://www.ietf.org/ipr
and BCP 79 [RFC3979][RFC4879] and file an IPR disclosure.
Intellectual property rights aren't mentioned in RFCs because RFCs
Moonesamy Expires December 11, 2012 [Page 19]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
never change after they are published but knowledge of IPR can change
at any time.
There is a tool called "xml2rfc" available from
http://xml.resource.org. It takes XML-formatted text and generates
an Internet-Draft.
7.2.2.1. Security Considerations
Every RFC requires 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. See "Guidelines for Writing RFC Text on
Security Considerations" [RFC3552] for more information on writing
good security considerations sections.
7.2.2.2. IANA Considerations
Many IETF protocols make use of values which are uniquely assigned to
ensure consistent interpretation between independent implementations.
These assignments are defined in the IETF Protocol Parameter
Registries [RFC6220]. For historical reasons these registries are
operated by IANA. If you are writing an Internet standard which
needs an assignment, read the RFC ( https://www.iana.org/protocols/ )
which defines the registration requirements. Registration is
generally done in the "IANA Considerations" [RFC5226] section of an
Internet-Draft.
7.2.3. Submitting an Internet-Draft
Internet-Drafts can be submitted at
https://datatracker.ietf.org/submit/ The IETF Tools web pages (
http://tools.ietf.org/ ) has pointers to tools that will automate
some of your work for the IETF. There is a very useful checking tool
at http://tools.ietf.org/tools/idnits which can be used to help
prevent the draft from being rejected due to errors in form and
formatting. There is a list of common issues (
http://www.ietf.org/ID-Checklist.html ) that have been known to stop
documents in the IESG.
7.2.4. Last Call
The purpose of IETF Last Call is to get community-wide discussion on
an Internet-Draft so the IESG determine whether it has IETF
consensus. It is also a time when people in the Working Group who
Moonesamy Expires December 11, 2012 [Page 20]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
feel that they weren't heard can make their comments to everyone.
The IETF Last Call is at least two weeks for Working Group drafts and
four weeks for individual submissions. The discussion for a Last
Call is held on the IETF general discussion list
<mailto:ietf@ietf.org> and is open to everyone. IETF Last Call
comments posted by people who have just read the draft for the first
time can expose issues that IETF and Working Group regulars may have
completely missed.
It is generally considered bad form to send IETF Last Call comments
on documents that you have not read, or to send comments but not be
prepared to discuss your views. The IETF Last Call is not a vote.
Campaigns aimed at getting people to post messages in support or
opposition to a document usually backfire.
7.2.5. IESG Evaluation
Any Area Director may record a "DISCUSS" ballot position against an
Internet-Draft if he or she has serious concerns. If these concerns
cannot be resolved by discussion, an override procedure is defined
such that at least two IESG members must express concerns. This
procedure helps to ensure that an Area Director's "pet peeve" cannot
indefinitely block something. If the IESG approves the draft they
ask the RFC Editor to publish it as a RFC.
8. Administrative Support
8.1. IETF Administrative Support Activity
The IETF Administrative Support Activity (IASA) [RFC4071] provides
the administrative structure required to support the IETF standards
process and to support the IETF's technical activities. Within this
activity is the office of the IETF Administrative Director (IAD) and
the IETF Administrative Oversight Committee (IAOC).
8.2. IETF Secretariat
A few people, who are part of the IETF Secretariat, are paid to
provide day-to-day logistical support for the IETF, coordinate IETF
meetings. The IETF Secretariat is also responsible for keeping the
official Internet-Drafts directory up to date and orderly,
maintaining the IETF web site, and for helping the IESG do its work.
It provides various tools for use by the community and the IESG. The
IETF Secretariat is under contract to IASA, which in turn is
financially supported by the fees collected for attending the IETF
meetings.
Moonesamy Expires December 11, 2012 [Page 21]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
There is a list of e-mail addresses to contact (
https://www.ietf.org/contact-the-ietf.html ) the IETF Secretariat.
9. Organizational Relationships
9.1. IETF Trust
The IETF Trust was set up in 2005 to have a stable and legally-
identifiable entity for the IETF. The IETF Trust holds and licenses
the intellectual property of the IETF. The members of the IETF
Administrative Oversight Committee serve as IETF Trustees. You can
find out more about the IETF Trust at their web site (
http://trustee.ietf.org ).
9.2. Internet Society
The Internet Society (ISOC) provides insurance coverage for many of
the people holding leadership positions in the IETF process and acts
as a public relations channel for the times that one of the "I"
groups wants to say something to the press. Since 2005 the Internet
Society employs the IETF Administrative Director (IAD) who works
full-time overseeing IETF meeting planning and operational aspects of
the IETF Secretariat.
9.3. RFC Editor
The RFC Editor [RFC4844] edits, formats, and publishes Internet-
Drafts as RFCs, working in conjunction with the IESG. An important
secondary role is to provide one definitive repository for all RFCs
(see http://www.rfc-editor.org ). Once an RFC is published, it is
never revised. If the specification it describes changes, the
standard will be re-published in another RFC that "obsoletes" the
first.
Up through the end of 2009 the RFC Editor was a single entity. The
function was split by the IAB into several roles that can be
performed by different people or organizations.
9.4. Internet Assigned Numbers Authority (IANA)
The Internet Assigned Numbers Authority (IANA) activities are
currently performed by the Internet Corporation for Assigned Names
and Numbers (ICANN). IANA services to the IETF are provided for free
as specified in [RFC2860]. The IETF is not involved in domain name
and IP address assignment functions.
9.5. Liaisons between the IETF and other Standards Organizations
Moonesamy Expires December 11, 2012 [Page 22]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
The IETF tries to have cordial relationships with other standards
organizations. The IETF has liaisons ( http://www.ietf.org/liaison )
with large standards organizations, including the ITU-T (the
Telecommunication Standardization Sector of the International
Telecommunication Union), the W3C (World Wide Web Consortium), the
IEEE (the Institute of Electrical and Electronics Engineers) and the
Unicode Consortium. Liaisons are kept as informal as possible and
must be of demonstrable value in improving the quality of IETF
specifications [RFC2850]. In practice, the IETF prefers liaisons to
take place directly at Working Group level with formal relationships
and liaison documents [RFC4053] in a backup role.
10. Acknowledgments
This document contains a large amount of text from RFC 4677 which is
is known as the Tao of the IETF.
RFC 4677 was co-authored by Paul Hoffman and Susan Harris.
Contributors include Brian Carpenter, Scott Bradner, Michael Patton,
Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault,
Russ Housley, the IETF Secretariat, members of the User Services
Working Group, and members of the PESCI (Process Evolution
Consideration for the IETF) design team.
The original version of RFC 4677, published in 1994, was written by
Gary Malkin. His knowledge of the IETF, insights, and unmatched
writing style set the standard for this later revision, and his
contributions to the RFC 4677 are also much appreciated.
11. References
11.1. Informative References
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
and Procedures", BCP 8, RFC 2014, October 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2360] Scott, G., "Guide for Internet Standards Writers", BCP 22,
RFC 2360, June 1998.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
Moonesamy Expires December 11, 2012 [Page 23]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
[RFC2850] Internet Architecture Board and B. Carpenter, Ed.,
"Charter of the Internet Architecture Board (IAB)",
BCP 39, RFC 2850, May 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45,
RFC 3005, November 2000.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February
2004.
[RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
and Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF",
BCP 103, RFC 4053, April 2005.
[RFC4071] Austein, R., Ed., and B. Wijnen, Ed., "Structure of the
IETF Administrative Support Activity (IASA)", BCP 101,
RFC 4071, April 2005.
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[RFC4879] Narten, T., "Clarification of the Third Party Disclosure
Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5378] Bradner, S., Ed., and J. Contreras, Ed., "Rights
Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
Moonesamy Expires December 11, 2012 [Page 24]
INTERNET DRAFT The IETF: a guide for newcomers June 9, 2012
November 2008.
[RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,
Huston, G., Ed., and Internet Architecture Board,
"Defining the Role and Function of IETF Protocol Parameter
Registry Operators", RFC 6220, April 2011.
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
October 2011.
Appendix A. Acronyms and Abbreviations Used
Some of the acronyms and abbreviations from this document are listed
below.
Term Meaning
-----------------------------------------------------------------
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
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 Numbers
I-D Internet-Draft
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IPR Intellectual property rights
IRTF Internet Research Task Force
ISOC Internet Society
PS Proposed Standard (RFC)
RFC Request for Comments
STD Standard (RFC)
WG Working Group
Authors' Addresses
S. Moonesamy
76, Ylang Ylang Avenue
Quatre Bornes
Mauritius
EMail: sm+ietf@elandsys.com
Moonesamy Expires December 11, 2012 [Page 25]