G. Malkin, Xylogics, Inc.
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
Over the last two years, the attendance at Internet Engineering Task Force (IETF) Plenary meetings has grown phenomenally. Approximately 38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know.
The IETF Secretariat is made up of the following people: Steve Coya (Executive Director of the IETF), Cynthia Clark, Lois Keiper, Debra Legare, John Stewart, and Megan Davies Walnut. These are the people behind the Registration Table, and the success, of the IETF meetings. I thank them for their hard work, and for their input and review of this document. Thanks also to Vinton Cerf, Christian Huitema, and Jon Postel for their review and comments. And, as always, special thanks to April Marine and Joyce Reynolds.
What is the IETF? . . . . . . . . . . . . . . . . . . . . . . 2
Humble Beginnings . . . . . . . . . . . . . . . . . . . . . . 3
The Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 4
IETF Mailing Lists . . . . . . . . . . . . . . . . . . . . . 5
Registration . . . . . . . . . . . . . . . . . . . . . . . . 6
Newcomers' Orientation . . . . . . . . . . . . . . . . . . . 7
Dress Code . . . . . . . . . . . . . . . . . . . . . . . . . 7
Seeing Spots Before Your Eyes . . . . . . . . . . . . . . . . 7
Terminal Room . . . . . . . . . . . . . . . . . . . . . . . . 8
Social Event . . . . . . . . . . . . . . . . . . . . . . . . 8
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Other General Things . . . . . . . . . . . . . . . . . . . . 9
Section 2 - The "You've got to know it" Stuff
Registration Bullets . . . . . . . . . . . . . . . . . . . . 10
Mailing Lists and Archives . . . . . . . . . . . . . . . . . 11
Important Email Addresses . . . . . . . . . . . . . . . . . . 12
IETF Proceedings . . . . . . . . . . . . . . . . . . . . . . 13
InterNIC Archives . . . . . . . . . . . . . . . . . . . . . . 13
Be Prepared . . . . . . . . . . . . . . . . . . . . . . . . . 14
RFCs and Internet-Drafts . . . . . . . . . . . . . . . . . . 15
Frequently Asked Questions (and Their Answers) . . . . . . . 16
Pointers to Useful Documents and Files . . . . . . . . . . . 17
Section 3 - The "Reference" Stuff
Tao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
IETF Area Abbreviations . . . . . . . . . . . . . . . . . . . 19
Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 20
References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Security Considerations . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . 22
The Internet Engineering Task Force is a loosely self-organized group of people who make technical and other contributions to the engineering and evolution of the Internet and its technologies. It is the principal body engaged in the development of new Internet Standard specifications. Its mission includes:
The IETF Plenary meeting is not a conference, although there are technical presentations. The IETF is not a traditional standards organization, although many standards are produced. The IETF is the volunteers who meet three times a year to fulfill the IETF mission.
There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there is to being an IETF member is being on the IETF or Working Group mailing lists (see the IETF Mailing Lists section). This is where the best information about current IETF activities and focus can be found.
The first IETF meeting was held in January, 1986 at Linkabit in San Diego with 15 attendees. The 4th IETF, held at SRI in Menlo Park in October, 1986, was the first at which non-government vendors attended. The concept of Working Groups (WG) 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 over 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 universe. The IAB (then Internet Activities Board, now Internet Architecture Board), which until that time oversaw many Task Forces, changed its structure to leave only two: the IETF and the IRTF. The IRTF is tasked to consider the 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.
A recent first for the IETF was its first European meeting. In July, 1993, the IETF met in Amsterdam, The Netherlands. The U.S./non-U.S. attendees split was nearly 50/50.
To completely understand the structure of the IETF, it is useful to understand the overall structure in which the IETF resides. There are four groups in the structure: the ISOC and its Board of Trustees (BOT), the IAB, the IESG, and the IETF itself.
Internet standardization is an organized activity of the ISOC. The ISOC is a professional society that is concerned with the growth and evolution of the worldwide Internet, with the way in which the Internet is and can be used, and with the social, political, and technical issues which arise as a result. The BOT is responsible for approving appointments to the IAB from among the nominees submitted by the IETF nominating committee.
The IAB is a technical advisory group of the ISOC. It is chartered to provide oversight of the architecture of the Internet and its protocols, and to serve, in the context of the Internet Standards process, as a body to which the decisions of the IESG may be appealed. The IAB is responsible for approving appointments to the IESG from among the nominees submitted by the IETF nominations committee.
The IESG is responsible for technical management of IETF activities and the Internet Standards process. As part of the ISOC, it administers the process according to the rules and procedures which have been ratified by the ISOC BOT. The IESG is directly responsible for the actions associated with entry into and movement along the IETF "standards track", including final approval of specifications as Internet Standards.
The IETF is divided into nine functional Areas. They are: Applications, Internet Services, Network Management, Operational Requirements, Routing, Security, Service Applications, Transport, and User Services. Each Area has at least one Area Director. There is also an Area Director who oversees Standards Management. The Area Directors, along with the IETF Chair, form the IESG. Phillip Gross has been the IETF Chair since the IETF's 7th meeting. He founded the IESG and serves as its Chair as well.
Each Area has several Working Groups. A Working Group is a group of people who work under a charter to achieve a certain goal. That goal may be the creation of an informational document, the creation of a protocol standard, or the resolution of problems in the Internet. Most Working Groups have a finite lifetime. That is, once a Working Group has achieved its goal, it disbands. As in the IETF, there is no official membership for a Working Group. Unofficially, a Working Group member is somebody who's on that Working Group's mailing list; however, anyone may attend a Working Group meeting (see the Be Prepared section below).
Areas may also have Birds of a Feather (BOF) groups. They generally have the same goals as Working Groups, except that they have no charter and usually only meet once or twice. BOFs are often held to determine if there is enough interest to form a Working Group.
Anyone who plans to attend an IETF meeting should join the IETF announcements mailing list. This is where all of the meeting information, new and revised Internet-Draft and RFC announcements, IESG Recommendations, and Last Calls are posted. People who'd like to "get technical" may also join the IETF discussion list, "[email protected]". This was the only list before the announcement list was created and is where discussions of cosmic significance are held (most Working Groups have their own mailing lists for discussions relating to their work). To join the IETF announcement list, send a request to:
[email protected]
To join the IETF discussion list, send a request to:
[email protected]
To join both of the lists, simply send a single message, to either "-request" address, and indicate that you'd like to join both lists.
Do not, ever, under any circumstances, for any reason, send a request to join a list to the list itself! The thousands of people on the list don't need, or want, to know when a new person joins. Similarly, when changing email addresses or leaving a list, send your request only to the "-request" address, not to the main list. This means you!!
The IETF discussion list is unmoderated. This means that anyone can express their opinions about issues affecting the Internet. However, it is not a place for companies or individuals to solicit or advertise. Only the Secretariat can send a message to the announcement list.
Even though the IETF mailing lists "represent" the IETF membership at large, it is important to note that attending an IETF meeting does not automatically include addition to either mailing list.
As previously mentioned, all meeting announcements are sent to the IETF announcement list. Within the IETF meeting announcement is a Registration Form and complete instructions for registering, including, of course, the cost. The Secretariat highly recommends that attendees preregister. Early registration, which ends about one month before the meeting, carries a lower registration fee. As the size of the meetings has grown, so has the length of the lines at the registration desk. Fortunately, there are three lines: "preregistered and prepaid" (which moves very quickly), "preregistered and on-site payment" (which moves a little more slowly), and "registration and on-site payment" (take a guess).
Registration is open all week. However, the Secretariat highly recommends that attendees arrive for early registration, beginning at 6:00 P.M. (meeting local time), on the Sunday before the opening plenary. Not only will there be fewer people, but there will also be a reception at which people can get a byte to eat. If the registration lines are long, one can eat first and try again when the lines are shorter.
Registered attendees (and there isn't any other kind) receive a Registration Packet. It contains a general orientation sheet, the At-A-Glance sheet, a list of Working Group acronyms, the most recent Agenda, and a name tag. The At-A-Glance is a very important reference and is used throughout the week. It contains Working Group/BOF room assignments and a map of room locations. Attendees who prepaid will also find their receipt in their packet.
Newcomers are encouraged to attend the IETF Newcomers' Orientation. As the name implies, it is an orientation for first time attendees to IETF meetings. The orientation is organized and conducted by the IETF Secretariat and is intended to provide useful introductory information. The Secretariat tries to keep the orientation session informal, and is usually successful at it.
The orientation is typically 30-45 minutes long and covers a number of topics: what's in the attendee packets, what all the dots on name tags mean, and how to read the At-A-Glance. There is also discussion about the organization of the IETF: Working Groups and their Areas, and the IESG. There is ample time at the end for questions. The Secretariat also provides handouts which include the text from the IETF Overview and a list of important files maintained on the IETF Shadow directories.
The orientation is held on Sunday afternoon and ends about 30 mintues before the Registration Reception. However, attending the orientation does NOT mean you can go to the reception early!
Since attendees must wear their name tags, they must also wear shirts or blouses. Pants or skirts are also highly recommended. Seriously though, 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. There are those in the IETF who refuse to wear anything other than suits. Fortunately, they are well known (for other reasons) so they are forgiven this particular idiosyncrasy. 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!).
Some of the people at the IETF will have a little colored dot on their name tag. A few people have more than one. These dots identify people who are silly enough to volunteer to do a lot of extra work. The colors have the following meanings:
red - IAB member
yellow - IESG member
blue - Working Group/BOF chair
green - Local host
Local hosts are the people who can answer questions about the terminal room, restaurants, and points of interest in the area.
Some people have Gold Stars on their name tags. The stars indicate that those people chaired Working Groups or BOFs in the IETF Area which submitted all of its Working Group/BOF Minutes and Area Report from the previous meeting first. The stars are the Secretariat's way of saying "Thank You" for providing the necessary information quickly.
It is important that newcomers to the IETF not be afraid to strike up conversations with people who wear these dots. 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.
To make life simpler for the Secretariat, Registration Packets are also coded with little colored dots. These are only for Secretariat use, so nobody else needs to worry about them. Please, don't peel them off your packet and put them on your name tag.
One of the most important (depending on your point of view) things the local host does is provide Internet access to the meeting attendees. In general, the connectivity is excellent. This is entirely due to the Olympian efforts of the local hosts, and their ability to beg, borrow and steal. The people and companies who donate their equipment, services, and time are to be heartily congratulated and thanked.
While preparation far in advance of the meeting is encouraged, there may be some unavoidable "last minute" things which can be accomplished in the terminal room. It may also be useful to people who need to make trip reports or status reports while things are still fresh in their minds.
Another of the most important things organized and managed by the local hosts is the IETF social event. The social event has become something of a tradition at the IETF meetings. It has been immortalized by Marshal Rose with his reference to "many fine lunches and dinners" [ROSE], and by Claudio and Julia Topolcic with their rendition of "Nerds in Paradise" on a pink T-shirt.
Newcomers to the IETF are encouraged to attend the social event.
Everyone is encouraged to wear their name tags. The social event is designed to give people a chance to meet on a social, rather than technical, level.
Sometimes, the social event is a computer or high-tech related event. At the Boston IETF, for example, the social was dinner at the Computer Museum. Other times, the social might be a dinner cruise or a trip to an art gallery.
The Agenda for the IETF meetings is a very fluid thing. It is sent, in various forms, to the IETF announcement list three times prior to the meeting. The final Agenda is included in the Registration Packets. Of course, "final" in the IETF doesn't mean the same thing as it does elsewhere in the world. The final Agenda is simply the version that went to the printers.
The Secretariat will announce Agenda changes during the morning plenary sessions. Changes will also be posted on the bulletin board near the IETF Registration Table (not the hotel registration desk).
Assignments for breakout rooms (that's where the Working Groups and BOFs meet) and a map showing the room locations make up the At-A- Glance sheet (included in the Registration Packets). Room assignments are as flexible as the Agenda. Some Working Groups meet multiple times during a meeting and every attempt is made to have a Working Group meet in the same room each session. Room assignment changes are not necessarily permanent for the week. Always check the At-A-Glance first, then the bulletin board. When in doubt, check with a member of the Secretariat at the Registration Table.
The opening Plenary on Monday morning is the most heavily attended session. It is where important introductory remarks are made, so people are encouraged to attend.
The IETF Secretariat, and IETFers in general, are very approachable. Never be afraid to approach someone and introduce yourself. Also, don't be afraid to ask questions, especially when it comes to jargon and acronyms!
Hallway conversations are very important. A lot of very good work gets done by people who talk together between meetings and over lunches and dinners. Every minute of the IETF can be considered work time (much to some people's dismay).
A "Bar BOF" is an unofficial get-together, usually in the late evening, during which a lot of work gets done over drinks.
It's unwise to get between a hungry IETFer (and there isn't any other kind) and coffee break brownies and cookies, no matter how interesting a hallway conversation is.
IETFers are fiercely independent. It's safe to question opinions and offer alternatives, but don't expect an IETFer to follow orders.
The IETF, and the plenary sessions in particular, are not places for vendors to try to sell their wares. People can certainly answer questions about their company and its products, but bear in mind that the IETF is not a trade show. This does not preclude people from recouping costs for IETF related T-shirts, buttons and pocket protectors.
Registration is such an important topic, that it's in this RFC twice! This is the "very important registration bullets" section.
As previously mentioned, 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 which have been moved off of the IETF list onto lists created specifically for those topics. It is highly recommended that everybody follow the discussions on the mailing lists of the Working Groups which they 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 cannot attend the IETF meetings.
All IETF discussion lists have a "-request" address which handles the administrative details of joining and leaving the list. It is generally frowned upon when such administrivia appears on the discussion mailing list.
Most IETF discussion lists are archived. That is, all of the messages sent to the list are automatically stored on a host for anonymous FTP access. To find out where a particular list is archived, send a message to the list's "-request" address, NOT to the list itself.
There are some important IETF email addresses with which everyone should be familiar. They are all located at "cnri.reston.va.us" (e.g., "[email protected]"). To personalize things, the names of the Secretariat staff who respond to the messages are given for each address.
The IETF Proceedings are compiled in the two months following each IETF meeting. The Proceedings usually start with a message from Steve Coya, the Executive Director of the IETF. Each contains the final (hindsight) Agenda, an IETF overview, a report from the IESG, Area and Working Group reports, network status briefings, slides from the protocol and technical presentations, and the attendees list. The attendees list includes an attendee's name, affiliation, work phone number, work fax number, and email address, as provided on the Registration Form.
A copy of the Proceedings will be sent to everyone who registered for the IETF. The cost is included in the registration fee. The Proceedings are sent to the mailing addresses provided on the Registration Forms.
For those who could not attend a meeting but would like a copy of the Proceedings send a check for $35 (made payable to CNRI) to:
Corporation for National Research Initiatives
Attn: Accounting Department - IETF Proceedings
1895 Preston White Drive, Suite 100
Reston, VA 22091
Please indicate which meeting Proceedings you would like to receive by specifying the meeting date (e.g., July 1993) or meeting number and location (e.g., 27th meeting in Amsterdam). Availability of previous meetings' Proceedings is limited, so ask BEFORE sending payment.
There is a tremendous amount of material available for those who follow the work of the IETF. To make it easier to know what to read to prepare for a meeting, the InterNIC has established a document archive. Beginning about one month prior to an IETF meeting, Working Group/BOF Chairs and Area Directors put documents relevent to the discussions to be held into the archives. Those people who plan to attend a Working Group/BOF session should check the archives for documents which need to be read. The documents are left in the archives for about two months after the end of the IETF meeting.
On the host "ds.internic.net", documents are stored in the directory "/pub/current-ietf-docs" under subdirectories named for each Area and then for each Working Group. For example, a document for the NISI Working Group, which is in the User Services Area, would be stored as "current-ietf-docs/usv/nisi/nisi-doc1.txt". Each Area will also have a subdirectory called "bof", where documents to be discussed in BOF sessions will be placed. A directory called "plenary" will also be created under "/pub/current-ietf-docs" to put documents or viewgraphs related to a plenary session. Any filename conflicts will be resolved by the archive administrator working with the submitter of the document via email.
It is important to note that the service is provided by the InterNIC and that the documents are submitted by the people who work on them. The IETF Secretariat does not manage or monitor the archive service.
Access via anonymous FTP:
Anonymous FTP to ds.internic.net
Change directory to /pub/current-ietf-docs
Browse and get the document of interest
Access via GOPHER (from a Gopher client):
Point to gopher.internic.net
Select menu item 4, InterNIC Directory and Database Services ...
Then menu item named "Internet Documentation (RFC's FYI's, etc.)/"
Lastly menu item named "Current IETF Conference Documents (...)/"
If you do not have a Gopher client, use the InterNIC's public-access Gopher client. Simply telnet to "gopher.internic.net" and login as "gopher" (no password required).
This topic cannot be stressed enough. As the IETF grows, it becomes more and more important for attendees to arrive prepared for the Working Group meetings they plan to attend. This doesn't apply only to newcomers; everybody should come prepared.
Being prepared means having read the documents which the Working Group or BOF Chair has distributed. It means having followed the discussions on the Working Group's mailing list or having reviewed the archives. For the Working Group/BOF Chairs, it means getting all of the documents out early (i.e., several weeks) to give everybody time to read them and announcing an agenda and sticking to it.
At the Chair's discretion, some time may be devoted to bringing new Working Group attendees up to speed. In fact, long lived Working Groups have occasionally held entire sessions which were introductory in nature. As a rule, however, a Working Group is not the place to go for training. Observers are always welcome, but they must realize that the work effort cannot be delayed for education. Anyone wishing to attend a Working Group for the first time might seek out the Chair prior to the meeting and ask for some introduction.
Another thing, for everybody, to consider is that Working Groups go through phases. In the initial phase (say, the first two meetings), all ideas are welcome. The idea is to gather all the possible solutions together for consideration. In the development phase, a solution is chosen and developed. Trying to reopen issues which were decided more than a couple of meetings back is considered bad form. The final phase (the last two meetings) is where the "spit and polish" are applied to the architected solution. This is not the time to suggest architectural changes or open design issues already resolved. It's a bad idea to wait until the last minute to speak out if a problem is discovered. This is especially true for people whose excuse is that they hadn't read the documents until the day before a comments period ended.
Time at the IETF meetings is a precious thing. Working Groups are encouraged to meet between IETF meetings, either in person or by video or telephone conference. Doing as much work as possible over the mailing lists would also reduce the amount of work which must be done at the meeting.
Originally, RFCs were just what the name implies; they were requests for comments. The early RFCs were messages between the ARPANET architects about how to resolve certain problems. Over the years, RFCs became more formal. It reached the point that they were being cited as standards, even when they weren't.
To help clear up some confusion, there are now two special sub-series within the RFCs: FYIs and STDs. The For Your Information RFC sub- series was created to document overviews and topics which are introductory. Frequently, FYIs are created by groups within the IETF User Services Area. The STD RFC sub-series was created to identify those RFCs which do in fact specify Internet Standards.
Every RFC, including FYIs and STDs, have an RFC number by which they are indexed and by which they can be retrieved. FYIs and STDs have FYI numbers and STD numbers, respectively, in addition to RFC numbers. This makes it easier for a new Internet user, for example, to find all of the helpful, informational documents by looking for the FYIs amongst all the RFCs. If an FYI or STD is revised, its RFC number will change, but its FYI or STD number will remain contant for ease of reference.
There is also an RTR subseries of RFCs for Reseaux Associes pour la Recherche Europeenne (RARE) Technical Reports. These are technical reports developed in the RARE community that are published as RFCs to provide easy access to the general Internet community.
Internet-Drafts (I-D) are working documents of the IETF. Any group (e.g., Working Group, BOF) or individual may submit a document for distribution as an I-D. An I-D is valid for six months. Guidelines require that an expiration date appear on every page of an I-D. An I-D may be updated, replaced or obsoleted at any time. It is not appropriate to use I-Ds as reference material or to cite them, other than as a "working draft" or "work in progress".
For additional information, read the following documents:
Frequently Asked Questions (and Their Answers)
Q: My Working Group moved this morning. Where is it now?
A: Not all room assignment changes are permanent. Check the At-A-Glance sheet and the message board for announcements.
Q: Where is Room A?
A: Check the map on the At-A-Glance sheet. An enlarged version is on
the bulletin board.
Q: Where can I get a copy of the Proceedings?
A: The Proceedings are automatically sent to each attendee about two
months after the meeting.
Q: When is on-site registration?
A: The IETF registration table is set up Sunday night from 6:00 p.m.
- 8:00 p.m. and Monday - Thursday from about 8:30 a.m. - 6:00 p.m.
Starting time in the mornings and Friday's hours may vary
depending on the meeting schedule.
Q: Where is lunch served?
A: The meeting does not include lunch or dinner. Ask a local host
(somebody with a green dotted badge) for a recommendation.
Q: Where are the receipts for the social event?
A: The social is not managed by the IETF Secretariat. Ask a local
host.
Pointers to Useful Documents and Files
This is a list of documents and files that provide useful information about the IETF meetings, Working Groups, and documentation. These files reside in the "ietf" directory on the Anonymous FTP sites listed below. Files with names beginning with "0" (zero) pertain to IETF meetings. These may refer to a recently held meeting if the first announcement of the next meeting has not yet been sent to the IETF mailing list. Files with names beginning with "1" (one) contain general IETF information. This is only a partial list of the available files.
o 0mtg-agenda.txt Agenda for the meeting o 0mtg-at-a-glance.txt Logistics information for the meeting o 0mtg-rsvp.txt Meeting registration form o 0mtg-sites.txt Future meeting sites and dates o 0mtg-traveldirections.txt Directions to the meeting site o 0tao.txt This document
o 1directories.txt The IETF Shadow directory locations and
contents.
o 1id-guidelines.txt Guidelines to Authors of Internet-Drafts
Contains information on writing and
submitting I-Ds.
o 1ietf-description.txt Short description of the IETF and IESG,
including a list of Area Directors.
o 1nonwg-discuss.txt A list of mailing lists created to
discuss specific IETF issues.
o 1proceedings-request.txt A Proceedings order form for the
current and previous meetings.
o 1wg-summary.txt List of all Working Groups, by Area,
including the name and address of the
chairperson, and the mailing list
address.
o 1wg-summary-by-acronym Same as above, but sorted by the
Working Groups' acronyms.
o 1wg-charter.txt Abbreviated versions of all current
Working Group charters.
o 1wg-charters-by-acronym Same as above, but sorted by the
Working Groups' acronyms.
Additionally, the full charters and minutes of the Working Groups and BOFs are archived in the "ietf" directory.
All of these documents are available by anonymous FTP from the following primary sites (there may be closer shadow sites, so check with your network administrator):
These files are also available through the Internet Gopher at "ietf.cnri.reston.va.us".
Residing on the same archive sites are the RFCs and Internet-Drafts. They are in the "rfc" and "internet-drafts" directories, respectively. The file "rfc-index.txt" contains the latest information about the RFCs (e.g., which have been obsoleted by which). In general, only the newest version of an Internet-Draft is available.
All of the files, RFCs and Internet-Drafts are also available via email from various mail servers. To to get the IETF agenda, Internet-Draft abstracts and RFC 1150 from the mail server at the InterNIC, for example, you would send the following message:
To: [email protected] Message header Subject: anything you want FILE /ietf/0mtg-agenda.txt Body of the message FILE /internet-drafts/1id-abstracts.txt FILE /rfc/rfc1150.txt PATH [email protected]
Where: FILE specifies the name of a file to be returned and PATH specifies the email address to which the file(s) should be sent.
RFCs may also be retrieved, using email, from ISI's RFC-Info server at "[email protected]". To get a specific RFC, include the following in the body of the message:
Retrieve: RFC Doc-ID: RFC0951
This example would cause a copy of RFC 951 (the leading zero in the Doc-ID is required) to be emailed to the requestor. To get a list of available RFCs which match certain criteria, include the following in the body of the message:
LIST: RFC Keywords: Gateway
This example would email a list of all RFCs with "Gateway" in the title, or as an assigned keyword, to the requestor. To get information on other ways to get RFCs:
HELP: ways_to_get_rfcs
Pronounced "Dow", Tao means "the Way." It is the basic principle behind the teachings of Lao-tse, a Chinese master. Its familiar symbol is the black and white Yin-Yang circle.
APP Applications
INT Internet Services
MGT Network Management
OPS Operational Requirements
RTG Routing
SAP Service Applications
SEC Security
TSV Transport
USV User Services
:-) Smiley face
ANSI American National Standards Institute
ARPA Advanced Research Projects Agency
ARPANET Advanced Research Projects Agency Network
AS Autonomous System
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
BOF Birds Of a Feather
BSD Berkeley Software Distribution
BTW By The Way
CCIRN Coordinating Committee for Intercontinental Research Networks
CCITT International Telegraph and Telephone Consultative Comittee
CIDR Classless Inter-Domain Routing
CIX Commercial Information Exchange
CNI Coalition for Networked Information
CREN The Corporation for Research and Educational Networking
DARPA U.S. Defense Advanced Research Projects Agency (now ARPA)
DDN U.S. Defense Data Network
DISA U.S. Defense Information Systems Agency
EGP Exterior Gateway Protocol
FAQ Frequently Asked Question
FARNET Federation of American Research NETworks
FIX U.S. Federal Information Exchange
FNC U.S. Federal Networking Council
FQDN Fully Qualified Domain Name
FYI For Your Information (RFC)
GOSIP U.S. Government OSI Profile
IAB Internet Architecture Board
IANA Internet Assigned Numbers Authority
I-D Internet-Draft
IEN Internet Experiment Note
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IMHO In My Humble Opinion
IMR Internet Monthly Report
InterNIC Internet Network Information Center
IR Internet Registry
IRSG Internet Research Steering Group
IRTF Internet Research Task Force
ISO International Organization for Standardization
ISOC Internet Society
ISODE ISO Development Environment
ITU International Telecommunication Union
MIB Management Information Base
MIME Multipurpose Internet Mail Extensions
NIC Network Information Center
NIS Network Information Services
NIST National Institute of Standards and Technology
NOC Network Operations Center
NREN National Research and Education Network
NSF National Science Foundation
OSI Open Systems Interconnection
PEM Privacy Enhanced Mail
PTT Postal, Telegraph and Telephone
RARE Reseaux Associes pour la Recherche Europeenne
RFC Request For Comments
RIPE Reseaux IP Europeenne
SIG Special Interest Group
STD Standard (RFC)
TLA Three Letter Acronym
TTFN Ta-Ta For Now
UTC Universal Time Coordinated
WG Working Group
WRT With Respect To
WYSIWYG What You See is What You Get
FYI1 Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I.", FYI 1, RFC 1150, Proteon, USC/Information Sciences Institute, March 1990.
GAID "Guidelines to Authors of Internet Drafts", 1id-guidelines.txt.
ROSE Rose, M., "The Open Book: A Practical Perspective on OSI", Prentice Hall, Englewood Cliffs, NJ, 1989.
RFC1111 Postel, J., "Request for Comments on Request for Comments", RFC 1111, USC/Information Sciences Institute, August 1989.
RFC1160 Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May 1990.
RFC1310 Chapin, L., Chair, "The Internet Standards Process", RFC 1310, Internet Activities Board, March 1992.
RFC1311 Postel, J., Editor, "Introduction to the STD Notes", RFC 1311, USC/Information Sciences Institute, March 1992.
STD1 Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 1500, Internet Architecture Board, August 1993.
Security issues are not discussed in this memo.
Gary Scott Malkin
Xylogics, Inc.
53 Third Avenue
Burlington, MA 01803
Phone: (617) 272-8140
EMail: [email protected]