ESN LLC v. Cisco Systems, Inc. et al

Filing 83

CLAIM CONSTRUCTION SUR-REPLY BRIEF filed by Cisco Systems, Inc., Cisco-Linksys LLC. (Attachments: # 1 Exhibit R, # 2 Exhibit S, # 3 Exhibit T, # 4 Exhibit U)(Smith, Kevin)

Exhibit S

Network Working Group
Request for Comments: FYI: 17 4677

P. Hoffman
VPN Consortium S. Harris

Obsoletes: 3160 Category: Informational

University of Michigan
September 2006

The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice
Copyright (C) The Internet Society ( 2006). Abstract

This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview.

Hoffman & Harris

Informational

[Page 11

RFC 4677

The Tao of IETF

September 2006

Table of Contents
1. Introduction ....................................................4 2. Acknowledgements ................................................5 3. What Is the IETF? ...............................................5 3.1. Humble Beginnings ..........................................6 3.2. The Hierarchy ..............................................7 3.2.1. ISOC (Internet Society) .............................7 3.2.2. IESG (Internet Engineering Steering Group ) ..........8 3.2.3. IAB (Internet Architecture Board) ..................10 3.2.4. IANA (Internet Assigned Numbers Authority) .........11 3.2.5. RFC Editor .........................................11 3.2.6. IETF Secretariat ...................................12 3.3. IETF Mailing Lists ............... .......................12 4. IETF Meetings ..................................................13 4.1. Registration ......................... ...................14 4.2. Take the Plunge and Stay All Week! ........................15 4.3. Newcomer Training ......... ..............................16 4.4. Dress Code ........................................ ... ..16 4.5. Seeing Spots Before Your Eyes .............................16 4.6. Terminal Room .............................................17 4.7. Meals and Other Delights ..................................17 4.8. Social Event ...... ...................................18 4.9. Agenda ....................................................18 4.10. EDU to the Rescue ........................................19 4.11. Where Do I Fit In? .......................................19 4.11.1. IS Managers .......................................19 4.11.2. Network Operators and ISPs ........................19 4.11.3. Networking Hardware and Software vendors ..........20 4.11.4. Academics ......... ..............................20 4.11.5. Computer Trade Press ..............................20 4.12. Proceedings ..............................................21 4.13. Other General Things ...........................21 5. Working Groups .................................................22 5.1. Working Group Chairs ......................................23 5.2. Getting Things Done in a Working Group .... ..............24 5.3. Preparing for Working Group Meetings ......................25 5.4. Working Group Mailing Lists ...............................26 5.5. Interim Working Group Meetings .........27 6. BOFs ......................... ..............................27 7. New to the IETF and Coming to a Meeting? STOP HERE! (Temporarily) ............................. ...................28 8. RFCs and Internet Drafts .......................................29 8.1. Getting an RFC Published ..............29 8.2. Letting Go Gracefully .....................................30 8.3. Internet Drafts ...........................................31 8.3.1. Recommended Reading for Writers ....................32 8.3.2. Filenames and Other Matters ........................33

Hoffman & Harris

Informational

[Page 21

RFC 4677

The Tao of IETF

September 2006

8.4. Standards-Track RFCs ......................................34 8.4.1. Telling It Like It Is -- Using MUST and SHOULD and MAY .......... ........... ...................35 8.4.2. Normative References in Standards ..................36 8.4.3. IANA Considerations ..................37 8.4.4. Security Considerations .........37 8.4.5. Patents in IETF Standards ....37 8.5. Informational and Experimental RFCs .... ..................38 9. How to Contribute to the IETF ...............................39 9.1. What You Can Do ...........................................39 9.2. What Your Company Can Do ..................................40 10. IETF and the Outside World ....................................40 10.1. IETF and Other Standards Groups ..........................40 10.2. Press Coverage of the IETF ..............41 11. Security Considerations .................42 Appendix A. Related Information ...................................43 A.1. Why "the Tao"? ,........ .. .. ... ............................43 A.2. Useful Email Addresses ....................................43 A.3. Useful Documents and Files ................................44 A.4. Acronyms and Abbreviations Used in the Tao ................44 Appendix B. IETF Guiding Principles ...............................45 B.1. General ............................. ...................45 B.2. Management and Leadership .................................45 B.3. Process ...................................................46 B.4. Working Groups ............................................46 B.5. Documents ............... ................................47 Informative References ... ... .............................. ..48

Hoffman & Harris

Informational

[Page 31

RFC 4677

The Tao of IETF

September 2006

they can follow the path of their, document through the process. BCP 9 (and various other documents that update it) goes into great detail on a topic that is very often misunderstood, even by seasoned IETF participants: different types of RFCs go through different processes and have different rankings. There are six kinds of RFCs: o o o o o o Proposed standards Draft standards Internet standards (sometimes called "full standards") Informational documents Experimental protocols Historic documents

Only the first three (proposed, draft, and full) are standards within the IETF. A good summary of this can be found in the aptly titled [RFC17961, "Not All RFCs Are Standards". There are also three sub-series of RFCs, known as FYIs, BCPs, and STDs. The For Your Information RFC sub-series was created to document overviews and topics that are introductory or that appeal to a broad audience; however, that series has not been added to in a long time. Best Current Practice documents describe the application of various technologies in the Internet. The STD RFC sub-series was created to identify RFCs that do in fact specify Internet standards. Some STDs are actually sets of more than one RFC, and the "standard" designation applies to the whole set of documents.

8.2.

Letting Go Gracefully

The biggest reason some people do not want their documents put on the IETF standards track is that they must give up change control of the protocol. That is, as soon as you propose that your protocol become an IETF standard, you must fully relinquish control of the protocol. If there is general agreement, parts of the protocol can be completely changed, whole sections can be ripped out, new things can be added, and the name can be changed. Some authors find it very hard to give up control of their pet protocol. If you are one of those people, don't even think about trying to get your protocol to become an IETF standard. On the other hand, if your goal is the best standard possible with the widest implementation, then you might find the IETF process to your liking.

Hoffman & Harris

Informational

[Page 301

RFC 4677

The Tao of IETF

September 2006

Incidentally, the change control on Internet standards doesn't end when the protocol is put on the standards track. The protocol itself can be changed later for a number of reasons, the most common of which is that implementors discover a problem as they implement the standard. These later changes are also under the control of the IETF, not the editors of the standards document. IETF standards exist so that people will use them to write Internet programs that interoperate. They don't exist to document the (possibly wonderful) ideas of their authors, nor do they exist so that a company can say, "We have an IETF standard". If a standardstrack RFC only has one implementation (whereas two are required for it to advance on the standards track), it was probably a mistake to put it on the standards track in the first place.
8.3. Internet Drafts

First things first. Every document that ends up in the RFC repository starts life as an Internet Draft. Internet Drafts are tentative documents -- they're meant for readers to comment on, so authors can mull over those comments and decide which ones to incorporate in the draft. In order to remind folks of their tentativeness,.Internet Drafts are automatically removed from the online directories after six months. They are most definitely not standards or even specifications. As [BCP9] says:
"An Internet Draft is NOT a means of 'publishing' a specification; specifications are published through the RFC mechanism.... Internet Drafts have no formal status, and are subject to change or removal at any time. Under no circumstances should an Internet Draft be

referenced by any paper, report, or Request-for-Proposal, nor should a vendor claim compliance with an Internet Draft".
You can always tell a person who doesn't understand the IETF (or is intentionally trying to fool people) when he or she brags about having published an Internet Draft; it takes no significant effort. When you submit an Internet Draft, you give some publication rights to the IETF. This is so that your Internet Draft is freely available to everyone who wants to read and comment on it. The rights you do and don't give to the IETF are described in [BCP78], "IETF Rights in Contributions".

There is a very useful checking tool at http://tools.ietf.org/tools/idnits/idnits.pyht. Using this tool before you turn in an Internet Draft will help prevent the draft from being rejected due to errors in form and formatting.

Hoffman & Harris

Informational

[Page 311

RFC 4677

The Tao of IETF

September 2006

An I-D should have approximately the same format as an RFC. Contrary to many people's beliefs, an I-D does not need to look exactly like an RFC, but if you can use the same formatting procedures used by the RFC Editor when you create your I-Ds, it will simplify the RFC Editor's work when your draft is published as an RFC. [RFC2223], "Instructions to RFC Authors", describes the nroff formatting used by the RFC Editor. There is also a-tool called "xml2rfc", available from http://xml.resource.org/, that takes XML-formatted text and turns it into a valid Internet Draft. An Internet Draft can be either a Working Group draft or an individual submission. Working Group drafts are usually reviewed by the Working Group before being accepted as a WG item, although the chairs have the final say. If you're interested in checking the status of a particular draft, or can't remember its exact name, or want to find out which drafts a WG is working on, two handy tools are available. The "Internet Drafts Database Interface at https://datatracker.ietf.org/public/idindex.cgi, lets you search for a draft by author, Working Group, date, or filename. The "I-D Tracker", at https://datatracker.ietf.org/public/pidtracker.cgi, is especially useful for authors who want to track the progress of their draft as it makes its way through the publication process.
There are some informal rules for Internet Draft naming that have evolved over the years. Internet Drafts that revise existing RFCs often have draft names with 'Ibis" in them, meaning "again" or "twice"; for example, a draft might be called "draft-someonerfc2345bis-OO.txt". 8.3.1. Recommended Reading for Writers

Before you create the first draft of your Internet Draft, you should read four documents: o More important than just explaining formatting, [RFC2223] also explains what needs to be in an Internet Draft before it can become an RFC. This document describes all the sections and notices that will need to be in your document, and it's good to have them there from the beginning so that readers aren't surprised when you put them in later versions.
[BCP22], "Guide for Internet Standards Writers", provides tips that will help you write a standard that leads to interoperability. For instance, it explains how to choose the right number of protocol options, how to respond to out-of-spec behavior, and how to show state diagrams.

o

Hoffman & Harris

Informational

[Page 321

RFC 4677

The Tao of IETF

September 2006

o

The online "Guidelines to Authors of Internet Drafts", http://www.ietf.org/ietf/lid-guidelines.txt, has up-to-date information about the process for turning in Internet Drafts, as well as the most current boilerplate information that has to be included in each Internet Draft. When you think you are finished with the draft process and are ready to request that the draft become an RFC, you should definitely read "Checklist for Internet Drafts (I-DS) Submitted for RFC Publication", http://www,ietf.org/ID-Checklist.html, a list of common issues that have been known to stop documents in the IESG. In fact, you should probably read that document well before you are finished, so that you don't have to make a bunch of last-minute changes.

Also, you should visit the IETF Tools web pages, http://tools.ietf.org, where you'll find pointers to other tools that will automate some of your work for the IETF. 8.3.2. Filenames and Other Matters

When you're ready to turn in your Internet Draft, send it to the Internet Drafts administrator at mailto:[e-mail]. There is a real person at the other end of this mail address, whose job is to make sure you've included the minimum items you need for the Internet Draft to be published. When you submit the first version of the draft, you also tell the draft administrator your proposed filename for the draft. If the draft is an official Working Group product, the name will start with "draft-ietf-11 followed by the designation of the WG, followed by a descriptive word or two, followed by "OO.txt". For example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-OO.txt". If it's not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "OO.txt". For example, a draft that someone named Smith wrote might be named "draft-smith-keying-OO.txt". If a draft is an individual submission but relates to a particular Working Group, authors sometimes follow their name with the name of the Working Group, such as "draft-smith-smime-keying-OO.txt". You are welcome to suggest names; however, it is up to the Internet Drafts administrator (and, if it is an official WG draft, the WG chair) to come up with the filename. If you follow the naming guidelines given at http://www,ietf.org/ietf/lid-guidelines.txt, chances are quite good that your suggested filename will be fine.

Hoffman & Harris

Informational

[Page 331

RFC 4677

The Tao of IETF

September 2006

After the first edition of a draft, the number in the filename is incremented; for instance, the second edition of the S/MIME draft named above would be "draft-ietf-smime-keying-Ol.txt". Note that there are cases where the filename changes after one or more versions, such as when a personal effort is pulled into a. Working Group; when a draft has its filename changed, the number reverts to -00. Be sure to let the Internet Drafts administrator know the previous name of the draft when such a name change occurs so that the databases can be kept accurate.
8.4. Standards-Track RFCs

The procedure for creating and advancing a standard is described in [BCP9]. After an Internet Draft has been sufficiently discussed and there is rough consensus that what it says would be a useful standard, it is presented to the IESG for consideration. If the draft is an official WG draft, the WG chair sends it to the appropriate Area Director after it has gone through Working Group last call. If the draft is an individual submission, the draft's author or editor submits it to the appropriate Area Director. BCP 9 also describes the appeals process for people who feel that a Working Group chair, an AD, or the IESG has made the wrong decision in considering the creation or advancement of a standard.
After the I-D is submitted to the IESG, the IESG announces an IETFwide last call. This helps get the attention of people who weren't following the progress of the draft, and it can sometimes cause further changes to the draft. It is also a time when people in the WG who feel that they weren't heard can make their comments to everyone. The IETF last call is two weeks for drafts coming from WGs and four weeks for individual submissions.

If the IESG approves the draft to become an Internet standard, they ask the RFC Editor to publish it as a Proposed standard. After it has been a Proposed standard for at least six months, the RFC's author (or the appropriate WG chair) can ask for it to become a Draft standard. Before that happens, however, someone needs to convince the appropriate Area Director that there are at least two independent, interoperable implementations of each part of the standard. This is a good test of the usefulness of the standard as a whole, as well as an excellent way to check if the standard was really readable. A few things typically happen at this point. First, it's common to find that some of the specifications in the standard need to be reworded because one implementor thought they meant one thing whereas another implementor thought they meant something else. Another common occurrence is that none of the implementations actually tried

Hoffman & Harris

Informational

[Page 341

RFC 4677

The Tao of IETF

September 2006

to implement a few of the features of the standard; these features get removed not just because no one tested them but also because they weren't needed. Don't be surprised if a particular standard doesn't progress from Proposed to Draft. In fact, most of the standards in common use are Proposed standards and never move forward. This may be because no one took the time to try to get them to Draft, or some of the normative references in the standard are still at Proposed standard, or it may be that everyone found more important things to do. A few years after a document has been a Draft standard, it can become an Internet standard, also known as "full standard" (it can happen in as little as four months, but this is rare). This doesn't happen often, and it is usually reserved for protocols that are absolutely required for the Internet to function. The IESG goes over the document with a fine-tooth comb and looks for evidence of widespread deployment before making a Draft standard an Internet standard.
8.4.1. Telling It Like It Is -- Using MUST and SHOULD and MAY

Writing specifications that get implemented the way you want is a bit of an art. You can keep the specification very short, with just a list of requirements, but that tends to cause implementors to take too much leeway. If you instead make the specification very wordy with lots of suggestions, implementors tend to miss the requirements (and often disagree with your suggestions anyway). An optimal specification is somewhere in between. One way to make it more likely that developers will create interoperable implementations of standards is to be clear about what's being mandated in a specification. Early RFCs used all kinds of expressions to explain what was needed, so implementors didn't always know which parts were suggestions and which were requirements. As a result, standards writers in the IETF generally agreed to limit their wording to a few specific words with a few specific meanings. [STD3], "Requirements for Internet Hosts -- Application and Support", written way back in 1989, had a short list of words that had appeared to be useful, namely, "must "should", and "may". These definitions were updated and further refined in [BCP14], "Key words for use in RFCs to Indicate Requirement Levels", which is widely referenced in current Internet standards. BCP 14 also specifically defines 'must not" and "should not", and it lists a few synonyms for the words defined,

Hoffman & Harris

Informational

[Page 351