From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2777.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc2777.txt (limited to 'doc/rfc/rfc2777.txt') diff --git a/doc/rfc/rfc2777.txt b/doc/rfc/rfc2777.txt new file mode 100644 index 0000000..3ddf9e7 --- /dev/null +++ b/doc/rfc/rfc2777.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 2777 Motorola +Category: Informational February 2000 + + + Publicly Verifiable Nomcom Random Selection + +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 (2000). All Rights Reserved. + +Abstract + + This document describes a method for making random selections in such + a way that the unbiased nature of the choice is publicly verifiable. + As an example, the selection of the voting members of the IETF + Nominations Committee from the pool of eligible volunteers is used. + Similar techniques would be applicable to other cases. + +Acknowledgement + + Matt Crawford made major contributions to this document. + +Table of Contents + + 1. Introduction............................................2 + 2. General Flow of a Publicly Verifiable Process...........2 + 2.1 Determination of the Pool..............................2 + 2.2 Publication of the Algorithm...........................2 + 2.3 Publication of Selection...............................3 + 3. Randomness..............................................3 + 3.1 Sources of Randomness..................................3 + 3.2 Skew...................................................4 + 3.3 Entropy Needed.........................................4 + 4. A Suggested Precise Algorithm...........................5 + 5. Fully Worked Example....................................6 + 6. Security Considerations.................................7 + 7. Reference Code.........................................8 + Appendix: History of NomCom Member Selection..............14 + References................................................15 + Author's Address..........................................15 + Full Copyright Statement..................................16 + + + +Eastlake Informational [Page 1] + +RFC 2777 Verifiable Random Selection February 2000 + + +1. Introduction + + Under the IETF rules, each year 10 persons are randomly selected from + among the eligible persons who volunteer to be the voting members of + the nominations committee (NomCom) to nominate members of the + Internet Engineering Steering Group (IESG) and the Internet + Architecture Board (IAB) [RFC 2727]. The number of eligible + volunteers in recent years has varied in the approximate range of 40 + to 60. + + It is highly desireable that the random selection of the voting + NomCom be done in a unimpeachable fashion so that no reasonable + charges of bias or favoritism can be brought. This is for the + protection of the IETF from bias and protection of the administrator + of the selection (currently, the appointed non-voting NomCom chair) + from suspicion of bias. + + A method such that public information will enable any person to + verify the randomness of the selection meets this criterion. This + document gives an example of such a method. + +2. General Flow of a Publicly Verifiable Process + + In general, a selection of NomCom members publicly verifiable as + unbiased or similar selection could follow the three steps given + below. + +2.1 Determination of the Pool + + First, you need to determine the pool from which the selection is to + be made. + + Volunteers are solicited by the appointed (non-voting) NomCom chair. + Their names are then passed through the IETF Secretariat to check + eligibility. (Current eligibility criteria relate to IETF meeting + attendance, records of which are maintained by the Secretariat.) The + full list of eligible volunteers is made public early enough that + there is a reasonable time to resolve any disputes as to who should + be in the pool, probably a week to ten days before the selection. + +2.2 Publication of the Algorithm + + The exact algorithm to be used, including the public future sources + of randomness, is made public. For example, the members of the final + list of eligible volunteers are ordered by publicly numbering them, + several public future sources of randomness such as government run + + + + + +Eastlake Informational [Page 2] + +RFC 2777 Verifiable Random Selection February 2000 + + + lotteries are specified, and an exact algorithm is specified whereby + eligible volunteers are selected based on a strong hash function [RFC + 1750] of these future sources of randomness. + +2.3 Publication of Selection + + When the prespecified sources of randomness produce their output, + those values plus a summary of the execution of the algorithm for + selection should be announced so that anyone can verify that the + correct randomness source values were used and the algorithm properly + executed. A cut off time for any complaint that the algorithm was + run with the wrong inputs or not faithfully executed should be + specified to finalize the output and provide a stable NomCom. + +3. Randomness + + The crux of the unbiased nature of the selection is that it is based + exactly on random information which will be revealed in the future + and thus can not be known to the person specifying the algorithm by + which that random information will be used to select the NomCom + members. The random information must be such that it will be + publicly revealed in a timely fashion. + + The random sources should not include anything that any reasonable + person would believe to be under the control or influence of the IETF + or its components, such as IETF meeting attendance statistics, + numbers of documents issued, or the like. + +3.1 Sources of Randomness + + Examples of good information to use are lottery winning numbers for + specified runnings of specified lotteries. Particularly for + government run lotteries, great care is usually taken to see that + they produce random quantities. Even in the unlikely case one were + to have been rigged, it would almost certainly be in connection with + winning money in the lottery, not in connection with IETF use. + + Other possibilities are such things as the closing price of a stock + on a particular day, daily balance in the US Treasury on a specified + day, the volume of trading on the New York Stock exchange on a + specified day, etc. (However, the reference code given below will not + handle integers that are too large.) Sporting events can be used but + only with care to specify exactly what quantities are being presumed + random and what will be done if they are cancelled or delayed. + + It is important that the last source of randomness, chronologically, + produce a substantial amount of the entropy needed. If most of the + randomness has come from the earlier of the specified sources, and + + + +Eastlake Informational [Page 3] + +RFC 2777 Verifiable Random Selection February 2000 + + + someone has even limited influence on the final source, they might do + an exhaustive analysis and exert such influence so as to bias the + selection in the direction they wanted. Thus it is best for the last + source to be an especially strong and unbiased source of a large + amount of randomness such as a government run lottery. + + It is best not to use too many different sources. Every additional + source increases the probability that it might be delayed or + cancelled calling into play contingency plans or, worst of all, + possibly creating a situation that was not anticipated. This would + either require arbitrary judgement by the Nomcom chair, defeating the + randomness of the selection, or a re-run with a new set of sources, + causing much delay. Probably a good number of sources is three. + +3.2 Skew + + Many of the sources of randomness suggested above produce data which + is not uniformly distributed. This is certainly true of stock prices + and horse race results, for example. However, use of a strong mixing + function [RFC 1750] will extract the available entropy and produce a + hash value whose bits, remainder modulo a small divisor, etc., are + uniformly distributed. + +3.3 Entropy Needed + + What we are doing is selection N items without replacement from a + population of P items. The number of different ways to do this is as + follows, where "!" represents the factorial function: + + P! + ------------- + N! * (P - N)! + + To do this in a completely random fashion requires as many random + bits as the logarithm base 2 of that quantity. Some sample + calculated approximate number of random bits for the selection of 10 + nomcom members from various pool sizes is given below: + + Random Selection of Ten Items From Pool + + Pool size 20 25 30 35 40 50 60 75 100 + Bits needed 18 22 25 28 30 34 37 40 44 + + Using an inadequate number of bits means that not all of the possible + selections would be available. For a substantially inadequate amount + of entropy, there would be substantial correlations between the + selection of two members of the pool, for example. However, as a + practical matter, for pool sizes likely to be encountered in IETF + + + +Eastlake Informational [Page 4] + +RFC 2777 Verifiable Random Selection February 2000 + + + nomcom membership selection, 40 bits of entropy should always be + adequate. Even if there is a large pool and theoretically more bits + are needed for complete randomness, 40 bits of entropy will assure + that the probability of selection of each pool member differs from + that of other pool members, the correlation between the selection of + any pair of pool members, etc., differs only insignificantly from + that for completely random selection. + + An MD5 [RFC 1321] hash has 128 bits and therefore can produce no more + than that number of bits of entropy. However, this is three times + what is likely to ever been needed for IETF nomcom membership + selection. + +4. A Suggested Precise Algorithm + + It is important that a precise algorithm be given for mixing the + random sources specified and making the selection based thereon. + Sources suggested above each produce either a single positive number + (i.e., closing price for a stock) or a small set of positive numbers + (many lotteries provide 6 numbers in the range of 1 through 40 or the + like, a sporting event could produce the scores of two teams, etc.). + A sample precise algorithm is as follows: + + For each source producing multiple numeric values, represent each as + a decimal number terminated by a period (or with a period separating + the whole from the fractional part) and without leading zeroes + (except for a single leading zero if the integer part is zero) or + trailing zeroes after the period. Order them from smallest to the + largest and concatenate them and follow the results by a "/". For + each source producing a single number, simply represent it as above + with a trailing "/". At this point you have a string for each + source, say s1/, s2/, ... Concatenate these strings in a pre- + specified order and represent each character as its ASCII code + producing s1/s2/.../. + + You can then produce a sequence of random values derived from a + strong mixing of these sources by calculating the MD5 hash [RFC 1321] + of this string prefixed and suffixed with a zero byte for the first + value, the string prefixed and suffixed by a 0x01 byte for the second + value, etc. Treat each of these derived random values as a positive + multiprecision integer. If there are P eligible volunteers, select + the first voting member by dividing the first derived random value by + P and using the remainder plus one as the position of the selectee in + the ordered list or volunteers. Select the second voting member by + dividing the second derived random value by P-1 and using the + remainder plus one as the position of the selectee in the list with + the first selectee eliminated. Etc. + + + + +Eastlake Informational [Page 5] + +RFC 2777 Verifiable Random Selection February 2000 + + + It is recommended that alphanumeric random sources be avoided due to + the greater difficulty in canonicalizing them in an independently + repeatable fashion; however, if any are used, all white space, + punctuation, and special characters should be removed and all letters + set to upper case. This will leave only an unbroken sequence of + letters A-Z and digits 0-9 which can be treated as a canonicalized + number above and suffixed with a "/". + +5. Fully Worked Example + + Assume the following ordered list of 25 eligible volunteers is + published in advance of selection: + + 1. John 11. Pollyanna 21. Pride + 2. Mary 12. Pendragon 22. Sloth + 3. Bashful 13. Pandora 23. Envy + 4. Dopey 14. Faith 24. Anger + 5. Sleepy 15. Hope 25. Kasczynski + 6. Grouchy 16. Charity + 7. Doc 17. Love + 8. Sneazy 18. Longsuffering + 9. Handsome 19. Chastity + 10. Cassandra 20. Smith + + Assume the following (fake example) ordered list of randomness + sources: + + 1. The People's Democracy of Betastani State Lottery six winning + numbers (ignoring the seventh "extra" number) for 1 October 1998. + 2. Numbers of the winning horses at Hialeia for all races for the + first day on or after x September 1998 on which at least two + races are run. + 3. The Republic of Alphaland State Lottery daily number for 1 + October 1998 treated as a single four digit integer. + 4. Closing price of Example Corporation stock on the Lunar Stock + Exchange for the first business day after x September 1998 when + it trades. + + Randomness publicly produced: + + Source 1: 9, 18, 26, 34, 41, 45 + Source 2: 2, 5, 12, 8, 10 + Source 3: 9319 + Source 4: 13 11/16 + + Resulting key string: + + 9.18.26.34.41.45./2.5.8.10.12./9319./13.6875/ + + + +Eastlake Informational [Page 6] + +RFC 2777 Verifiable Random Selection February 2000 + + + The table below gives the hex of the MD5 of the above key string + bracketed with a byte whose value is successively 0x00, 0x01, 0x02, + through 0x09. The divisor for the number size of the remaining pool + at each stage is given and the index of the selectee as per the + original number of those in the pool. + + index hex value of MD5 div selected + 1 746612D0A75D2A2A39C0A957CF825F8D 25 -> 12 <- + 2 95E31A4429ED5AAF7377A15A8E10CD9D 24 -> 6 <- + 3 AFB2B3FD30E82AD6DC35B4D2F1CFC77A 23 -> 8 <- + 4 06821016C2A2EA14A6452F4A769ED1CC 22 -> 3 <- + 5 94DA30E11CA7F9D05C66D0FD3C75D6F7 21 -> 2 <- + 6 2FAE3964D5B1DEDD33FDA80F4B8EF45E 20 -> 24 <- + 7 F1E7AB6753A773EFE46393515FDA8AF8 19 -> 11 <- + 8 700B81738E07DECB4470879BEC6E0286 18 -> 19 <- + 9 1F23F8F8F8E5638A29D332BC418E0689 17 -> 15 <- + 10 61A789BA86BF412B550A5A05E821E0ED 16 -> 22 <- + + Resulting selection, in order selected: + + 1. Pendragon (12) 6. Anger (24) + 2. Grouchy (6) 7. Pollyanna (11) + 3. Sneazy (8) 8. Chastity (19) + 4. Bashful (3) 9. Hope (15) + 5. Mary (2) 10. Sloth (22) + +6. Security Considerations + + Careful choice of should be made of randomness inputs so that there + is no reasonable suspicion that they are under the control of the + administrator. Guidelines given above to use a small number of + inputs with a substantial amount of entropy from the last shoud be + followed. And equal care needs to be given that the algorithm + selected is faithfully executed with the designated inputs values. + Publication of the results and a week or so window for the community + of interest to duplicate the calculations should give a reasonable + assurance against implementation tampering. + + To maintain the unpredictable character of selections, should a + member of the nomcom need to be replaced due to death, resignation, + expulsion, etc., new publicly announced future random sources should + be used for the selection of their replacement. + + + + + + + + + +Eastlake Informational [Page 7] + +RFC 2777 Verifiable Random Selection February 2000 + + +7. Reference Code + + This code makes use of the MD5 reference code from [RFC 1321] ("RSA + Data Security, Inc. MD5 Message-Digest Algorithm"). The portion of + the code dealing with multiple floating point numbers was written by + Matt Crawford. + + /**************************************************************** + * + * Reference code for + * "Publicly Verifiable Nomcom Random Selection" + * Donald E. Eastlake 3rd + * + ****************************************************************/ + #include + #include + #include + #include + #include + + #include "global.h" + #include "MD5.h" + + /* local prototypes */ + int longremainder ( unsigned char divisor, + unsigned char dividend[16] ); + int getinteger ( char *string ); + double NPentropy ( int N, int P ); + + + /* limited to 16 inputs of up to sixteen integers each */ + /****************************************************************/ + + main () + { + int i, j, k, k2, err, keysize, pool, selection; + unsigned char unch, uc16[16], remaining, *selected; + long int temp, array[16]; + MD5_CTX ctx; + char buffer[257], key [800], sarray[16][256]; + + pool = getinteger ( "Type size of pool:\n" ); + if ( pool > 255 ) + + { + printf ( "Pool too big.\n" ); + exit ( 1 ); + } + + + +Eastlake Informational [Page 8] + +RFC 2777 Verifiable Random Selection February 2000 + + + selected = (unsigned char *) malloc ( pool ); + if ( !selected ) + { + printf ( "Out of memory.\n" ); + exit ( 1 ); + } + selection = getinteger ( "Type number of items to be selected:\n" ); + if ( selection > pool ) + { + printf ( "Pool too small.\n" ); + exit ( 1 ); + } + if ( selection == pool ) + { + printf ( "All of the pool is selected.\n" ); + exit ( 0 ); + } + err = printf ( "Approximately %.1f bits of entropy needed.\n", + NPentropy ( selection, pool ) + 0.1 ); + if ( err <= 0 ) exit ( 1 ); + for ( i = 0, keysize = 0; i < 16; ++i ) + { + if ( keysize > 500 ) + { + printf ( "Too much input.\n" ); + exit ( 1 ); + } + /* get the "random" inputs. echo back to user so the user may + be able to tell if truncation or other glitches occur. */ + err = printf ( + "\nType #%d randomness or 'end' followed by new line.\n" + "Up to 16 integers or the word 'float' followed by up\n" + "to 16 x.y format reals.\n", i+1 ); + if ( err <= 0 ) exit ( 1 ); + gets ( buffer ); + j = sscanf ( buffer, + "%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld%ld", + &array[0], &array[1], &array[2], &array[3], + &array[4], &array[5], &array[6], &array[7], + &array[8], &array[9], &array[10], &array[11], + &array[12], &array[13], &array[14], &array[15] ); + if ( j == EOF ) + exit ( j ); + if ( !j ) + if ( buffer[0] == 'e' ) + break; + + else + + + +Eastlake Informational [Page 9] + +RFC 2777 Verifiable Random Selection February 2000 + + + { /* floating point code by Matt Crawford */ + j = sscanf ( buffer, + "float %ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]" + "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]" + "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]" + "%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]%ld.%[0-9]", + &array[0], sarray[0], &array[1], sarray[1], + &array[2], sarray[2], &array[3], sarray[3], + &array[4], sarray[4], &array[5], sarray[5], + &array[6], sarray[6], &array[7], sarray[7], + &array[8], sarray[8], &array[9], sarray[9], + &array[10], sarray[10], &array[11], sarray[11], + &array[12], sarray[12], &array[13], sarray[13], + &array[14], sarray[14], &array[15], sarray[15] ); + if ( j == 0 || j & 1 ) + printf ( "Bad format." ); + else { + for ( k = 0, j /= 2; k < j; k++ ) + { + /* strip trailing zeros */ + for ( k2=strlen(sarray[k]); sarray[k][--k2]=='0';) + sarray[k][k2] = '\0'; + err = printf ( "%ld.%s\n", array[k], sarray[k] ); + if ( err <= 0 ) exit ( 1 ); + keysize += sprintf ( &key[keysize], "%ld.%s", + array[k], sarray[k] ); + } + keysize += sprintf ( &key[keysize], "/" ); + } + } + else + { /* sort values, not a very efficient algorithm */ + for ( k2 = 0; k2 < j - 1; ++k2 ) + for ( k = 0; k < j - 1; ++k ) + if ( array[k] > array[k+1] ) + { + temp = array[k]; + array[k] = array[k+1]; + array[k+1] = temp; + } + for ( k = 0; k < j; ++k ) + { /* print for user check */ + err = printf ( "%ld ", array[k] ); + if ( err <= 0 ) exit ( 1 ); + keysize += sprintf ( &key[keysize], "%ld.", array[k] ); + } + keysize += sprintf ( &key[keysize], "/" ); + } + + + +Eastlake Informational [Page 10] + +RFC 2777 Verifiable Random Selection February 2000 + + + } /* end for i */ + + /* have obtained all the input, now produce the output */ + err = printf ( "Key is:\n %s\n", key ); + if ( err <= 0 ) exit ( 1 ); + for ( i = 0; i < pool; ++i ) + selected [i] = i + 1; + printf ( "index hex value of MD5 div selected\n" ); + for ( unch = 0, remaining = pool; + unch < selection; + ++unch, --remaining ) + { + MD5Init ( &ctx ); + MD5Update ( &ctx, &unch, 1 ); + MD5Update ( &ctx, (unsigned char *)key, keysize ); + MD5Update ( &ctx, &unch, 1 ); + MD5Final ( uc16, &ctx ); + k = longremainder ( remaining, uc16 ); + /* printf ( "Remaining = %d, remainder = %d.\n", remaining, k ); */ + for ( j = 0; j < pool; ++j ) + if ( selected[j] ) + if ( --k < 0 ) + { + printf ( "%2d " + "%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X%02X " + "%2d -> %2d <-\n", + unch+1, uc16[0],uc16[1],uc16[2],uc16[3],uc16[4],uc16[5],uc16[6], + uc16[7],uc16[8],uc16[9],uc16[10],uc16[11],uc16[12],uc16[13],uc16[14], + uc16[15], remaining, selected[j] ); + selected[j] = 0; + break; + } + } + printf ( "\nDone, type any character to exit.\n" ); + getchar (); + return 0; + } + + /* prompt for an integer input */ + /****************************************************************/ + int getinteger ( char *string ) + { + int i, j; + char tin[257]; + + while ( 1 ) + { + printf ( string ); + + + +Eastlake Informational [Page 11] + +RFC 2777 Verifiable Random Selection February 2000 + + + printf ( "(or 'exit' to exit) " ); + gets ( tin ); + j = sscanf ( tin, "%d", &i ); + if ( ( j == EOF ) + + || ( !j && ( ( tin[0] == 'e' ) || ( tin[0] == 'E' ) ) ) + ) + exit ( j ); + if ( j == 1 ) + return i; + } /* end while */ + } + + /* get remainder of dividing a 16 byte unsigned int + by a small positive number */ + /****************************************************************/ + int longremainder ( unsigned char divisor, + unsigned char dividend[16] ) + { + int i; + long int kruft; + + if ( !divisor ) + return -1; + for ( i = 0, kruft = 0; i < 16; ++i ) + { + kruft = ( kruft << 8 ) + dividend[i]; + kruft %= divisor; + } + return kruft; + } /* end longremainder */ + + /* calculate how many bits of entropy it takes to select N from P */ + /****************************************************************/ + /* P! + log ( ----------------- ) + 2 N! * ( P - N )! + */ + + double NPentropy ( int N, int P ) + { + int i; + double result = 0.0; + + if ( ( N < 1 ) /* not selecting anything? */ + || ( N >= P ) /* selecting all of pool or more? */ + ) + return 1.0; /* degenerate case */ + + + +Eastlake Informational [Page 12] + +RFC 2777 Verifiable Random Selection February 2000 + + + for ( i = P; i > ( P - N ); --i ) + result += log ( i ); + for ( i = N; i > 1; --i ) + result -= log ( i ); + /* divide by [ log (base e) of 2 ] to convert to bits */ + result /= 0.69315; + + return result; + } /* end NPentropy */ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Informational [Page 13] + +RFC 2777 Verifiable Random Selection February 2000 + + +Appendix: History of NomCom Member Selection + + For reference purposes, here is a list of the IETF Nominations + Committee member selection techniques and chairs so far: + + YEAR CHAIR SELECTION METHOD + + 1993/1994 Jeff Case Clergy + 1994/1995 Fred Baker Clergy + 1995/1996 Guy Almes Clergy + 1996/1997 Geoff Huston Spouse + 1997/1998 Mike St.Johns Algorithm + 1998/1999 Donald Eastlake 3rd This Algorithm + 1999/2000 Avri Doria This Alogrithm + + Clergy = Names were written on pieces of paper, placed in a + receptacle, and a member of the clergy picked the Nomcom members. + + Spouse = Same as Clergy except chair's spouse made the selection. + + Algorithm = Algorithmic selection based on the same concepts as + documented herein. + + This Algorithm = Algorithmic selection using the algorithm and + reference code (but not the fake example sources of randomness) + described herein. + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Informational [Page 14] + +RFC 2777 Verifiable Random Selection February 2000 + + +References + + RFC 1321 Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + RFC 1750 Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + RFC 2727 Galvin, J., "IAB and IESG Selection, Confirmation, and + Recall Process: Operation of the Nominating and Recall + Committees", BCP 10, RFC 2727, February 2000. + +Author's Address + + Donald E. Eastlake, 3rd + Motorola + 65 Shindegan Hill Road, RR #1 + Carmel, NY 10512 USA + + Phone: +1-914-276-2668 (h) + +1-508-261-5434 (w) + Fax: +1-508-261-4447 (w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake Informational [Page 15] + +RFC 2777 Verifiable Random Selection February 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Eastlake Informational [Page 16] + -- cgit v1.2.3