This document discusses Request for Comments (RFCs) and Internet Drafts (IDs), which are documents published by the Internet Engineering Task Force (IETF) that specify and describe Internet standards and proposed standards. It explains that RFCs document standards and operational practices, while IDs are works in progress that may eventually become RFCs. It provides reasons for reading these documents, such as learning how protocols are supposed to work, finding related information, and helping to improve specifications. It also outlines the different types of RFCs and publication process for IDs, and where to find these documents.

1. Why you should read RFCs
and Internet Drafts
(and what you need to know to do so)
AusNOG 2015
Mark Smith
markzzzsmith@gmail.com

2. So talking about documents and groups that
publish them can be a bit dry.
Image courtesy of Gabriel Millos - https://flic.kr/p/4AR2qy

3. So why should you read
RFCs?

4. But first, what are they?

5. “Request For Comments” documents, published
by the IETF.

6. Or the
Internet Engineering Task Force

7. “The Internet Engineering Task Force is a
loosely self-organized group of people who
contribute to the engineering and evolution of
Internet technologies.”
- RFC3160

8. So people participate in the IETF, helping to
produce RFCs.

9. The first RFC was written on a typewriter in a
bathroom in 1969 by Steve Crocker.

11. There are now more than 7500 of them!

12. You can access all of the RFCs at:
https://www.ietf.org/rfc.html

13. So why should you read them?

14. Reason
To find out how things are
really supposed to work.

15. Reason
Because books don't yet exist.

16. Reason
To help improve them by
making them clearer.

17. Reason
To find related information.

18. Reason
So you can better lodge bugs
with vendors.

19. Reason
To see what might be coming.

20. Reason
To create future feature
demand.

21. Reason
Because they're readable!

22. Reason
To have something to do on
public transport.

23. Reason
To be amused and entertained.

24. So what do you need to know to
read RFCs?

25. RFCs aren't just protocol specifications.

26. 4 Common RFC types
Standards Track Experimental
Best Current PracticeInformational

27. Standards Track RFCs

28. Standards Track RFCs are protocol
specifications on the way to becoming an
Internet Standard.

30. There actually aren't many proper Internet
Standards though, because the IETF believe in
“rough consensus and running code.”

31. The IETF expect protocols to be shown to work
before they become full Internet Standards.

32. Of all 7500+ RFCs, only 80 are currently Internet
Standards.

34. Experimental RFCs

35. Experimental RFCs are “published for
examination, experimental implementation,
and
evaluation.”

36. In other words, the IETF think there is merit in
them, but they're not completely confident of
their value.

38. Standards Track RFCs are not allowed to
depend on Experimental RFCs.

39. Make sure you're well aware of limitations of
Experimental RFCs and their implementations
if you're going to use them.

41. Yes, that is 1:1 Stateless NAT for IPv6.

43. The IETF don't think those limitations are all that
acceptable (RFC2993), which is why that RFC is
Experimental.

44. Experimental RFCs can also include the famous
April Fools RFCs.

45. CC Image courtesy of OliBac
http://www.flickr.com/photos/olibac/2415284302/sizes/l/in/photostream/

46. Getting a bit thirsty?

47. Courtesy of [cipher] - https://flic.kr/p/5UHweP
Here's a refreshing picture of a glass of water.

48. Informational RFCs

49. Informational RFCs provide information that the
IETF consider to be useful, interesting or
amusing to the networking community.

51. This can include protocol specifications or
device methods of operation that are not IETF
standards.

53. Informational RFCs can also include the famous
April Fools RFCs.

55. Best Current Practice (BCP)
RFCs

56. BCP RFCs describe best current practices for
the operation of the Internet and the IETF.

58. So that is why I think you should
read RFCs, and what you need
to know to do so.

59. So why should you read
Internet Drafts?

60. But first, what are they?

61. Internet Drafts (IDs) are the documents that
may eventually become IETF RFCs.

62. But they also may not become RFCs.

63. In other words, IDs are usually work(s) in
progress, and have no formal IETF status.

64. So why should you read them?

65. Reason
Because many of the reasons
to read RFCs also apply to IDs.

66. Reason
Discover future networking
directions.

67. Reason
To help make them better.

68. Reason
For recognition.

69. So what do you need to know to
read IDs?

70. They can be written and submitted to the IETF
by anybody. (At all!)

71. Or they may originate in an IETF Working
Group.

72. They automatically expire after 6 months.

74. Publishing a new ID version revives or
updates an ID, pushing out the six month
expiry date.

75. Discovering IDs to read

76. ID-Announce Mailing List
ID-Announce mailing list subscriptions and HTTP
archives
https://www.ietf.org/list/announcement.html

78. ID name format
draft-<author>-[<IETF WG>]-<ID-brief-id>-<version#>

80. Need more water?

81. Courtesy of Loz Pycock - https://flic.kr/p/4DtcXG
Here is much more!

82. The primary place where IDs are discussed are
IETF Working Groups (WGs).

83. IETF Working Groups focus on specific
problems and related technologies.

84. 6man WG – IPv6 Protocol Maintenance
v6ops WG – IPv6 Operations
lager WG – Label Generation Rules
drinks WG – Data for Reachability of Inter/Intra-
Network SIP
and many others.

85. Working Groups are managed by Working
Group Chairs.

86. The majority of discussion about IDs takes
place on WG email lists.

87. Active WGs are at the following link, which also
provides email list subscription details:
https://datatracker.ietf.org/wg/

88. Discussion also happens at quarterly face-to-
face IETF meetings.

89. IETF47

90. Working Groups are organised into IETF Areas.

91. Area examples:
Applications Area (app)
Internet Area (int)
Operations and Management Area (ops)

92. 6man WG is under the Internet Area.
v6ops WG is under the Operations and
Management Area.

93. Areas are looked after by elected Area
Directors.

94. The group of Area Directors form the Internet
Engineering Steering Group (IESG).

95. Once a WG thinks an ID is ready to be
published as an RFC, it goes to the IESG for
review and/or approval.

96. If the IESG approve it, after some editorial
steps, it becomes an RFC.

97. New RFCs are announced on the IETF-
Announce mailing list.
https://www.ietf.org/list/announcement.html

98. Some recommended reading before you start
reading RFCs and IDs.

99. RFC1925 -
“The Twelve Networking Truths”

100. RFC1958 -
“Architectural Principles of the Internet”

101. RFC2119 -
“Key words for use in RFCs to Indicate
Requirement Levels”

102. RFC3160 -
“The Tao of IETF - A Novice's Guide to the
Internet Engineering Task Force”

103. RFC3439 -
“Some Internet Architectural Guidelines and
Philosophy”

104. RFC5505 -
“Principles of Internet Host Configuration”

105. RFC7282 -
“On Consensus and Humming in the IETF”

106. A few other IETF related groups/entities you
should know of.

107. Internet Architecture Board (IAB)
An elected group who provide oversight to the
IETF's activities, and think about the “big
picture”.

108. Internet Assigned Numbers
Authority (IANA)
Manage the numbers of the Internet and its
protocols:
Address Space Numbers (which they give to RIRs to give to us)
Port Numbers
Error and Status Codes

109. RFC Editor
Administer the publishing of RFCs, and
maintain the RFC archives.

110. Other recommended reading
“Where Wizards Stay Up Late: The Origins Of
The Internet” by Katie Hafner
“Network Geeks: How They Built the Internet”
by Brian E. Carpenter

111. Even more refreshment for such a dry topic?

112. Here's a flood.

113. Courtesy of Tim Green - https://flic.kr/p/cWJF5L

114. Questions?

115. Thanks for listening!
CC image courtesy of Kiwithing
http://www.flickr.com/photos/kiwisaotome/8261132558/size
s/c/in/photostream/