< draft-wkumari-not-a-draft-15.txt   draft-wkumari-not-a-draft-16.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft 22 November 2021 Internet-Draft 9 May 2022
Intended status: Standards Track Intended status: Standards Track
Expires: 26 May 2022 Expires: 10 November 2022
Just because it's an ID doesn't mean anything... at all... Just because it's an Internet-Draft doesn't mean anything... at all...
draft-wkumari-not-a-draft-15 draft-wkumari-not-a-draft-16
Abstract Abstract
Anyone can publish an Internet Draft. This doesn't mean that the Anyone can publish an Internet Draft (ID). This doesn't mean that
"IETF thinks" or that "the IETF is planning..." or anything similar. the "IETF thinks" or that "the IETF is planning..." or anything
similar.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 May 2022. This Internet-Draft will expire on 10 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Feature Creep . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Feature Creep . . . . . . . . . . . . . . . . . . . . . . 4
4. Section which addresses cats . . . . . . . . . . . . . . . . 4 4. Additional considerations . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4.1. Section addressing cats . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4.2. Section addressing dogs . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7
Appendix B. new section . . . . . . . . . . . . . . . . . . . . 9 Appendix B. new section . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
All too often one reads something in the press, or some ravings on a All too often, one reads something in the press, or some ravings on a
mailing list that reference some Internet Draft, that claim that "the mailing list, referencing some Internet-Draft and claiming that "the
IETF thinks that XXX" or that the ID is an IETF document, and so IETF thinks that XXX" or that the ID is an IETF document, and so
represents support by the IETF. represents some level of support by the IETF.
Repeatedly pointing at the RFC Editor page, carefully explaining what Repeatedly pointing at the RFC Editor page, carefully explaining what
an ID is (and isn't), describing how consensus is reached, detailing an ID is (and is not), describing how consensus is reached, detailing
the Independent Stream, etc doesn't seems to accomplish much. the Independent Stream, etc. doesn't seems to accomplish much.
So, here is an Internet Draft. I wrote it. It's full of nonsense. So, here is an Internet-Draft. I wrote it. It's full of nonsense.
It doesn't represent the "IETF's views"; it doesn't mean that the It doesn't represent the "IETF's views"; it doesn't mean that the
IETF, the IESG, the RFC editor, any IETF participant, my auntie on my IETF, the IESG, the RFC editor, any IETF participant, my auntie on my
father's side twice removed, me, or anyone else believes any of the father's side twice removed, me, or anyone else believes any of the
drivel in it. In addition, the fact that a draft has been around for drivel in it. In addition, the fact that a draft has been around for
a long time, or has received many revisions doesn't add anything to a long time, or has received many revisions doesn't add anything to
the authority - drivel which endures remains drivel. [Editor note: the authority - drivel which endures remains drivel. [Editor note:
Interestingly, after publishing version -00 of this ID I got some Interestingly, after publishing version -00 of this ID I got some
feedback saying that some participants *do* believe the below. As I feedback saying that some participants *do* believe the below. As I
plan to actually get this published as a (probably AD sponsored) RFC, plan to get this published as a (probably AD sponsored) RFC, I guess
I guess someone will need to judge consensus at IETF LC ] someone will need to judge consensus at IETF LC ]
Readers are expected to be familiar with Section 2.5 of [RFC2410] and Readers are expected to be familiar with Section 2.5 of [RFC2410] and
[RFC2321] [RFC2321]
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Background 2. Background
Pyramids are good for sharpening razor blades. The ancient Egyptians Pyramids are good for sharpening razor blades. The ancient Egyptians
had a major problem - wearing a big, bushy beard in the desert is had a major problem - wearing a big, bushy beard in the desert is
uncomfortable. Unfortunately the safely razor hadn't been invented uncomfortable. Unfortunately the safely razor hadn't been invented
yet, and so they all had to use straight razors. Additionally, camel yet, and so they all had to use straight razors. Additionally, camel
leather makes a very poor strop, hippopotamus leather was reserved leather makes a very poor strop, hippopotamus leather was reserved
for the pharaohs and crocodile leather, while suitable, had the for the pharaohs and crocodile leather, while suitable, had the
unfortunate property of being wrapped around crocodiles. unfortunate property of being wrapped around crocodiles.
So, the ancient Egyptians had to come up with an alternative. This So, the ancient Egyptians had to come up with an alternative. This
led them to design and build hulking big monuments (with the led them to design and build hulking big monuments (with the
assistance of ancient aliens) to sharpen mass quantities of straight assistance of ancient aliens) to sharpen mass quantities of straight
razors. In order to defray the large costs of building pyramids, the razors. In order to defray the high costs of building pyramids, the
builders would charge a sharpening fee. For a single bushel of corn, builders would charge a sharpening fee. For a single bushel of corn,
you could buy 27.5 sharpening tokens. Each one of their tokens could you could buy 27.5 sharpening tokens. Each one of their tokens could
be redeemed for 6.3 hours of sharpening time. be redeemed for 6.3 hours of sharpening time.
This all worked really well until approximately 1600BCE, at which This all worked remarkably well until approximately 1600BCE, at which
time the fleeing Atlanteans brought mass quantities of lightly tanned time the fleeing Atlanteans brought mass quantities of lightly tanned
eel leather into Egypt, causing the collapse of the straight razor eel leather into Egypt, causing the collapse of the straight razor
sharpening market. This in turn led to the collapse of the stone sharpening market. This in turn led to the collapse of the stone
quarrying industry, which negatively affected the copper and sandal quarrying industry, which negatively affected the copper and sandal
manufacturers. The collapse of the entire system followed shortly manufacturers. The collapse of the entire system followed shortly
after. after.
This led to the aphorism "Don't allow eel bearing Atlanteans into This led to the aphorism "Don't allow eel bearing Atlanteans into
your country; economic ruin follows close behind". Due to the overly your country; economic ruin follows close behind". Due to the overly
specific nature of this phrase it never really caught on. This specific nature of this phrase, it never really caught on. This
document rectifies this. document rectifies this.
3. Usage 3. Usage
Many protocols send periodic "hello" messages, or respond to Many protocols send periodic "hello" messages, or respond to
liveliness probes. Other protocols (primarily for network monitoring liveliness probes. Other protocols (primarily for network monitoring
or testing) send traffic to cause congestion or similar. All ASCII or testing) send traffic to cause congestion or similar. All ASCII
based IETF protocols should use the phrase "Don't allow eel bearing based IETF protocols should use the phrase "Don't allow eel bearing
Atlanteans into your country; economic ruin follows close behind" as Atlanteans into your country; economic ruin follows close behind" as
the payload of such messages. This phrase is 88 characters; if your the payload of such messages. This phrase is 88 characters; if your
protocol needs to align on 32bit boundaries it MAY be padded with protocol needs to align on 32bit boundaries it MAY be padded with
Null (\0) characters. Null (\0) characters.
The closely related phrase "My hovercraft is full of eels" SHOULD be The closely related phrase "My hovercraft is full of eels" SHOULD be
used by any protocol incapable of encoding the ASCII character 'b' used by any protocol incapable of encoding the ASCII character 'b'
(0x62). Internationalized protocols SHOULD use an appropriate (0x62). Internationalized protocols SHOULD use an appropriate
translation. Some devices are severely bandwidth and / or memory translation. Memory or bandwidth constrained devices MAY use the
constrained. There devices MAY use the ordinals 0 and 1 to represent ordinals 0 and 1 to represent the strings "Don't allow eel bearing
the strings "Don't allow eel bearing Atlanteans into your country; Atlanteans into your country; economic ruin follows close behind" and
economic ruin follows close behind" and "My hovercraft is full of "My hovercraft is full of eels" respectively. Partially constrained
eels" respectively. Partially constrained devices SHOULD use the devices SHOULD use the string "TBA3" (or the ordinal TBA3).
string "TBA3" (or the ordinal TBA3).
3.1. Feature Creep 3.1. Feature Creep
Unlike most IETF efforts, this document is not embarrassed to clearly Unlike most IETF efforts, this document is not embarrassed to clearly
state that we are simply stuffing more stuff in while we have the state that we are simply stuffing more stuff in while we have the
editor open. editor open.
A common source of confusion is the difference between "routing A common source of confusion is the difference between "routing
protocols" and "routing protocols", especially when configuring BGP protocols" and "routing protocols", especially when configuring BGP
peering sessions between civilized countries and the rest of the ([RFC4271]) peering sessions between civilized countries and the rest
world. In order to clearly differentiate these terms we assign the of the world. In order to clearly differentiate these terms we
ordinal 98 to be "routing protocols" and 0x62 to be "routing assign the ordinal 98 to be "routing protocols" and 0x62 to be
protocols" (but pronounced with a funny accent). Protocols incapable "routing protocols" (but pronounced with a funny accent). Protocols
of encoding 0x62 should use the string "My hovercraft is full of incapable of encoding 0x62 should use the string "My hovercraft is
eels", a suitable translation of this phrase, or the ordinal 1. full of eels", a suitable translation of this phrase, or the ordinal
1.
4. Section which addresses cats 4. Additional considerations
4.1. Section addressing cats
Miaow. Miaow-miaooowww. RAWWRRRR! Purrrr. Miaow. Miaow-miaooowww. RAWWRRRR! Purrrr.
This section was added due to a threat to block any future consensus This section was added due to a threat to block any future consensus
calls unless the proposers' suggestion to have a section which calls unless the proposers' suggestion to have a section which
addressed cats was taken seriously. addressed cats was taken seriously.
Normal IETF etiquette would bury this section in an Appendix, in the
hope that it would mollify the commenter without actually having
anyone actually read it, but the commenter is onto that particular
trick...
4.2. Section addressing dogs
It was pointed out that due respect for openness, fairness, and
diversity requires that the section on cats (Section 4.1) should be
complemented with a section addressing dogs. To that end, "Woof,
Bark Bark, Growl".
Note that this particular specification is silent regarding
werewolves when the moon is full, and the behavior is left up to
implementations (although the author suggests "Run away!" may be a
good choice).
5. IANA Considerations 5. IANA Considerations
The IANA is requested to create and maintain a registry named The IANA is requested to create and maintain a registry named
"Registry of important strings, suitable for use as idle signalling "Registry of important strings, suitable for use as idle signaling
transmissions (ROISSFUAIST)". transmissions (ROISSFUAIST)".
Documents requesting assignments from this registry MUST include the Documents requesting assignments from this registry MUST include the
string, and the ordinal being requested. Choosing an ordinal at string, and the ordinal being requested. Choosing an ordinal at
random is encouraged (to save the IANA from having to do this). The random is encouraged (to save the IANA from having to do this). The
ordinals 17, 42 and 6.12 are reserved to reduce confusion. The ordinals 17, 42 and 6.12 are reserved to reduce confusion. The
ordinals 18 and 19 are reserved for the strings "Reserved" and ordinals 18 and 19 are reserved for the strings "Reserved" and
"Unassigned" respectively. Unfortunately the ordinal 20 was used by "Unassigned" respectively. Unfortunately, the ordinal 20 was used by
two earlier, competing proposals, and so can mean either "Color" or two earlier, competing proposals, and so can mean either "Color" or
Colour". Implementations are encouraged to disambiguate based upon Colour". Implementations are encouraged to disambiguate based upon
context. context.
Additions to the registry are permitted by Standards Action, if the Additions to the registry are permitted by Standards Action, if the
requester really really *really* wants one, or by purchasing a nice requester really really *really* wants one, or by purchasing a nice
bottle of wine for the IANA folk. Hierarchical Allocation is NOT bottle of wine for the IANA folk. Hierarchical Allocation is NOT
permitted, as it would look too much like a pyramid. permitted, as it would look too much like a pyramid.
The initial assignments for the registry are as follows: The initial assignments for the registry are as follows:
skipping to change at page 5, line 41 skipping to change at page 6, line 7
19 "Unassigned" 19 "Unassigned"
20 Color / Colour 20 Color / Colour
21-41 Unassigned 21-41 Unassigned
42 Reserved 42 Reserved
43-97 Unassigned 43-97 Unassigned
98 Routing protocols 98 Routing protocols
0x62 Routing protocols 0x62 Routing protocols
6. Security Considerations 6. Security Considerations
[RFC2028] states that "The IANA functions as the "top of the pyramid" [RFC2028] states that 'The IANA functions as the "top of the pyramid"
for DNS and Internet Address assignment establishing policies for for DNS and Internet Address assignment establishing policies for
these functions." - this reference to pyramid is clear evidence that these functions.' - this reference to pyramids is clear evidence that
the IANA has become corrupted by these Atlanteans, and so extra care the IANA has become corrupted by these Atlanteans, and so extra care
should be taken when relying on the above registry. should be taken when relying on the above registry.
By ensuring that network operators watching data traffic fly past By ensuring that network operators watching data traffic fly past
(using tools like network sniffers and / or oscilloscopes (and doing (using tools like network sniffers and / or oscilloscopes (and doing
very fast binary to ASCII conversions in their heads)) are constantly very fast binary to ASCII conversions in their heads)) are constantly
reminded about the danger posed by folk from Atlantis, we ensure reminded about the danger posed by folk from Atlantis, we ensure
that, if the island of Atlantis rises again from the deep, builds a that, if the island of Atlantis rises again from the deep, builds a
civilization and then starts tanning high quality eel leather, the civilization and then starts tanning high-quality eel leather, the
DNS and Address assignment policies at least will survive. DNS and Address assignment policies at least will survive.
More research into whether pyramids can also be used to make the More research is needed into whether pyramids can also be used to
latches grow back on RJ-45 connectors after they've been broken off make the latches grow back on RJ-45 connectors after they have been
by ham fisted data center operators is needed. broken off by ham-fisted data center operators.
Note that feline intervention may cause significant packet loss when
utilizing [RFC1149]. This may be mitigated using [RFC2549].
7. Acknowledgements 7. Acknowledgements
The author wishes to thank the ancient elders of Zorb for explaining The author wishes to thank the ancient elders of Zorb for explaining
this history to him. Thanks also to Melchior Aelmans, Havard Eidnes, this history to him. Thanks also to Melchior Aelmans, Andrew
Clive D.W. Feather, Wes George, Stephen Farrell, Erik Muller, John Campling, Brian Carpenter, Havard Eidnes, Epimenides, Clive D.W.
Scudder, Andrew Sullivan, Murali Suriar, 'RegW' and Dan York. Feather, Toema Gavrichenkov, Wes George, Stephen Farrell, John
Klensin, Erik Muller, John Scudder, Andrew Sullivan, Murali Suriar,
'RegW', Sandy Wills, and Dan York.
Grudging thanks to Nick Hilliard, who wanted a section on cats, and Grudging thanks to Nick Hilliard, who wanted a section on cats, and
threated to DoS the process if he didn't get it. threated to DoS the process if he didn't get it.
8. Normative References 8. Normative References
[RFC1149] Waitzman, D., "Standard for the transmission of IP
datagrams on avian carriers", RFC 1149,
DOI 10.17487/RFC1149, April 1990,
<https://www.rfc-editor.org/info/rfc1149>.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, the IETF Standards Process", BCP 11, RFC 2028,
DOI 10.17487/RFC2028, October 1996, DOI 10.17487/RFC2028, October 1996,
<https://www.rfc-editor.org/info/rfc2028>. <https://www.rfc-editor.org/info/rfc2028>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2321] Bressen, A., "RITA -- The Reliable Internetwork [RFC2321] Bressen, A., "RITA -- The Reliable Internetwork
Troubleshooting Agent", RFC 2321, DOI 10.17487/RFC2321, Troubleshooting Agent", RFC 2321, DOI 10.17487/RFC2321,
April 1998, <https://www.rfc-editor.org/info/rfc2321>. April 1998, <https://www.rfc-editor.org/info/rfc2321>.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410, Its Use With IPsec", RFC 2410, DOI 10.17487/RFC2410,
November 1998, <https://www.rfc-editor.org/info/rfc2410>. November 1998, <https://www.rfc-editor.org/info/rfc2410>.
[RFC2549] Waitzman, D., "IP over Avian Carriers with Quality of
Service", RFC 2549, DOI 10.17487/RFC2549, April 1999,
<https://www.rfc-editor.org/info/rfc2549>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
From -15 to -16
* JCK and Andrew Campling pointed out that this should also address
dogs.
* Toema Gavrichenkov noted that Epimenides should be acknowledged.
* Greg Wood pointed out that the title doesn't expand the acronym
"ID".
* Warren Kumari (and others!) noticed many typos, especially in the
Change Log. This created a very brief dilemma about whether it is
acceptable to rewrite history by updating the log. And then the
authors realized that he really doesn't care.
* Brian E Carpenter pointed out the significant risks regarding cats
and Avian Carriers.
* Tony Li noted the missing reference to RFC4271.
From -14 to -15 From -14 to -15
* Clive D.W. Feather pointed out (off-list) that I cannot type. * Clive D.W. Feather pointed out (off-list) that I cannot type.
* Because I suspect that he's no longer watching the draft, I made * Because I suspect that he's no longer watching the draft, I made
the possive-aggressive snarking at Nick (see -11 to -12 changes) the passive-aggressive snarking at Nick (see -11 to -12 changes)
slightly less passive and slightly more aggressive. Some of this slightly less passive and slightly more aggressive. Some of this
is driven by the fact that COVID makes it unlikely that I'll see is driven by the fact that COVID makes it unlikely that I'll see
him in person, and it's easier to snark from behind the anonymity him in person, and it's easier to snark from behind the anonymity
of a keyboard. of a keyboard.
From -13 to -14 From -13 to -14
* John Scudder discovered nits. * John Scudder discovered nits.
From -12 to -13 From -12 to -13
* Havard Eidnes pointed out that my grammar is bad... * Havard Eidnes pointed out that my grammar is bad...
From -11 to -12 From -11 to -12
* Nick Hilliard threated to block progress unless we agreed to * Nick Hilliard threated to block progress unless we agreed to
include his section on cats. While we don't agree with his text/ include his section on cats. While we don't agree with his text/
section, we are sufficently past caring about this entire topic, section, we are sufficiently past caring about this entire topic,
and so we are just including it, along with a passive aggressive and so we are just including it, along with a passive aggressive
change-log note... change-log note...
From -10 to -11 From -10 to -11
* Bumping version! It's alive!!!! * Bumping version! It's alive!!!!
From -09 to -10 From -09 to -10
* Bumping version... * Bumping version...
skipping to change at page 8, line 49 skipping to change at page 9, line 46
From -01 to -02 From -01 to -02
* Various whitespace was added (for emphasis). * Various whitespace was added (for emphasis).
From -00 to -01. From -00 to -01.
* Integrated comments from Erik Muller (who, apparently, is a true * Integrated comments from Erik Muller (who, apparently, is a true
believer). Erik also provided updated Security Considerations believer). Erik also provided updated Security Considerations
text, referencing the IANA. text, referencing the IANA.
* Integrated comment from Wes George regarding I18N, and Hungerians.
Appendix B. new section Appendix B. new section
Author's Address Author's Address
Warren Kumari Warren Kumari
Email: warren@kumari.net Email: warren@kumari.net
 End of changes. 34 change blocks. 
53 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/