GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5513

Network Working Group A. Farrel Request for Comments: 5513 Old Dog Consulting Category: Informational 1 April 2009

           IANA Considerations for Three Letter Acronyms

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) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Abstract

 Three Letter Acronyms (TLAs) are commonly used to identify components
 of networks or protocols as designed or specified within the IETF.  A
 common concern is that one acronym may have multiple expansions.
 While this may not have been an issue in the past, network
 convergence means that protocols that did not previously operate
 together are now found in close proximity.  This results in
 contention for acronyms, and confusion in interpretation.  Such
 confusion has the potential to degrade the performance of the
 Internet as misunderstandings lead to misconfiguration or other
 operating errors.

Farrel Informational [Page 1] RFC 5513 TLAs April 2009

 Given the growing use of TLAs and the relatively small number
 available, this document specifies a Badly Construed Proposal (BCP)
 for the management of a registry of TLAs within the IETF, and the
 procedures for the allocation of new TLAs from the registry.

1. Introduction

 A Three-Letter Acronym (TLA) is a popular form of abbreviation
 usually based on the initial letters of a three-word term.  A formal
 definition of a TLA is provided in Section 2.
 TLAs are particularly popular within the Internet community where
 they serve as abbreviations in the spoken and written word.  As their
 popularity has grown, the measure of the value of an RFC (q.v.) is
 not only its successful implementation, interoperability, and
 deployment, but also the number of TLAs included in the text.
 For example, the Transmission Control Protocol (itself a TLA - TCP)
 [RFC0793] is extremely successful.  The specification contains no
 fewer than 20 distinct TLAs (although it should be noted that some
 are simple abbreviations rather than proper acronyms).  On the other
 hand, the Internet Stream Protocol Version 2 [RFC1819] is ambiguously
 referred to using the TLA ST2, and also as STII which is clearly not
 a TLA.  Further, the STII specification contains only 12 distinct
 TLAs, and it should be no surprise that STII has been far less
 successful than TCP.
 A common concern amongst diligent protocol implementers is that one
 acronym may have multiple expansions.  While this may not have been
 an issue in the past, network convergence means that protocols that
 did not previously operate together are now found in close proximity.
 Not only does this result in contention for acronyms, and confusion
 in interpretation of specification, it also leads to many wasted
 hours trying to select appropriate and suitably-unique names for
 variables within source code implementations.  Such confusion has the
 potential to degrade the performance of the Internet as
 misunderstandings lead to coding errors, compilation failures,
 misconfiguration, and other operating errors.
 Furthermore, it should be noted that we are rapidly approaching World
 Acronym Depletion (WAD).  It has been estimated that, at the current
 rate of TLA allocation, we will run out by the end of September this
 year.  This timescale could be worsened if there is the expected
 growth in demand for mobile acronyms, IP-TLAs, and TLA-on-demand.
 According to the definition provided in Section 2, there are 36**3 -
 10**3 = 45656 TLAs in total.  This number will so easily be depleted
 that we must institute some policy for conservation.

Farrel Informational [Page 2] RFC 5513 TLAs April 2009

 The Internet Assigned Numbers Authority (IANA, helpfully, a four-
 letter acronym - although note that a four-letter acronym is an FLA
 and hence is, in its own way, a TLA) maintains registries of names
 and numbers for use within the Internet in order to avoid duplicate
 allocation of one of those names or numbers and the consequent
 confusion and failed interoperability that would arise.  It is,
 therefore, wholly appropriate that the IANA should manage the
 assignment and use of TLAs within the Internet.
 This document specifies a Badly Construed Proposal for the management
 of a registry of TLAs within the IETF, and the procedures for the
 allocation of new TLAs from the registry.

1.1. RFC Editor Terminology List

 It is worth observing that the RFC Editor currently maintains a list
 of common terms, abbreviations, and acronyms.  While this list is
 highly useful for the construction of documents, it does not provide
 unambiguous interpretation of acronyms.

2. Formal Definition of TLA

 Acronym - a word made up of the initial letters of the words in a
    phrase.
    For example, IETF is an acronym formed from the first letters of
    the phrase International Essential Tremor Foundation [URL-IETF].
 Three Letter Acronym (TLA) - an acronym comprising exactly three
    letters.
    For example, RFC is a TLA formed of the first letters of the
    phrase Rugby Football Club [URL-CARDIFF].
 For our usage, we also allow digits within a TLA.  Thus, P2P is an
 acronym meaning Purchase to Pay [URL-P2P].  The digits 2 and 4 are
 specially used by clever people who have noticed that, when spoken,
 they sound like the words 'to' and 'for'.  Whether this is helpful
 may be left as an exercise for the user considering the brief
 conversation, below.
 A - Do you use the Internet Streams Protocol?
 B - Yes.  Do you use ST, too?
 A - No, I use ST2.
 B - That's interesting.  C uses ST2, too.
 A - I have a car horn application called Toot-toot.
 B - Really? Do you use ST2 to Toot-toot, too?

Farrel Informational [Page 3] RFC 5513 TLAs April 2009

 Note, however, that an acronym made up entirely of digits might be
 frowned upon.
 Lastly, we must consider case-sensitivity.  Although acronyms often
 include upper or lowercase letters, no assumptions should be made
 about the interpretation of the acronym based on the case of its
 letters, so that both QOS and QoS clearly refer to the Queen of the
 South football club [URL-QOS] and [URL-QoS].

2.1. A Note on Vocalization

 Acronyms are often articulated as words in spoken text.  This can be
 helpful in generating a cosy feel or a marketing buzz around a
 concept that offers a less-favorable reality.  For example, Claws and
 Teeth (CAT) can be pronounced "cat" making it seem quite cuddly.
 Other acronyms are always spelled out in order to avoid accidental
 misinterpretation or litigation.  For example, do not refer to your
 neighbor's Daughter or Granddaughter as anything other than their
 D-O-G.
 But care should be taken with vocalization, as well.  It will be
 noted that some letters have more syllables than the words they are
 used to represent.  In these cases, acronyms are to be avoided.
 Thus, the world wide web must never be assigned the acronym WWW.
 Finally, a word of caution about attempting to pronounce acronyms as
 words.  This can lead to serious injury for the inexperienced unless
 they happen to be native speakers of Czech.  Do not try to say XML in
 front of your mother-in-law, and don't attempt to talk about Open
 Office dot Org in polite company.

3. Backward and Forward Compatibility

 It should be obvious to most RFC readers (MRRs) that TLAs are already
 widely used in Internet specifications.  This work is not intended to
 unnecessarily invalidate existing RFCs, although where such
 invalidation is necessary or desirable, this work can be used for
 that purpose.
 In order to support existing documents, IANA is required to search
 all existing RFCs for every existing acronym usage (EAU), but may
 filter that search to exclude non-TLAs.
 It will be noted that, as a result of that search, many duplicate
 meanings will be discovered.  For example, "OAM" will be found in a
 large number of RFCs, yet its meaning may be as diverse as "on a
 mission", "order of Australia medal", and "orbital angular momentum".

Farrel Informational [Page 4] RFC 5513 TLAs April 2009

 This contention is best resolved by the judgement of Solomon -- each
 acronym usage will be allocated its share of the letters currently in
 use.  If there are three uses of an acronym, they will get one letter
 each; two existing uses would get one-and-a-half letters each; etc.

4. IANA Considerations

4.1. New Registry

 The Internet TLA Registry (ITR) should track the following
 information:
  1. TLA
  2. Unique interpretation
  3. Defining RFC

4.2. Reserved Values

 Certain key values are reserved.  That is, they are allocated in the
 registry by this document and may not be used for any other purpose.
    Acronym   Expansion                             Reference
    --------+-------------------------------------+-----------
    TLA       Two Letter Acronym                    [RFC5513]
    TBD       Two Be Deleted                        [RFC5513]
    RFC       Ready for Compost                     [RFC5513]
    PoS       Not particularly good                 [RFC5513]
    VPN       Very possibly no use                  [RFC5513]
    TCP       Totally bad proposal                  [RFC5513]
    USA       Universal Source of Acronyms          [RFC5513]
    NBG       This document                         [RFC5513]
    BCP       Badly construed proposal              [RFC5513]

4.3. Allocation Policy

 IANA shall apply the following allocation policies according to
 [RFC5226].
 Experimental Use
    All TLAs of the form XX* where * is any letter or digit.
 First Come First Served
    All TLAs of the form X**, Y**, or Z** where * is any letter or
    digit.  Excepted from this are the TLAs of the form XX* as above.
 IETF Review
    All other TLAs.

Farrel Informational [Page 5] RFC 5513 TLAs April 2009

5. Security Considerations

 Many security algorithms are identified by TLAs.  It is a clear
 requirement that someone implementing, for example, MD5 should be
 understood to have encoded the well-known Maybe-Decrypted-
 Deciphered-Decoded-Disambiguated-and-Degraded algorithm, and not any
 other security algorithm with the same acronym.

6. Acknowledgements

 I would like to thank the MPLS-TP design team for holding seemingly
 endless meetings during which the need for this document became
 apparent.
 Thanks to Daniel King for noticing that this document is a BCP.

7. References

7.1. Normative References

 [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
               an IANA Considerations Section in RFCs", BCP 26, RFC
               5226, May 2008.

7.2. Informative References

 [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.
 [RFC1819]     Delgrossi, L., Ed., and L. Berger, Ed., "Internet
               Stream Protocol Version 2 (ST2) Protocol Specification
               - Version ST2+", RFC 1819, August 1995.
 [URL-IETF]    International Essential Tremor Foundation,
               http://www.essentialtremor.org/
 [URL-CARDIFF] Cardiff Rugby Football Club, http://www.cardiffrfc.com/
 [URL-P2P]     eProcumentStotl@nd,
               http://www.eprocurementscotland.com/Home/ePS-
               Service/P2P
 [URL-QOS]     Queen of the South Football Club, http://www.qosfc.com/
 [URL-QoS]     Queen of the South Football Club,
               ahttp://www.qosfc.com/

Farrel Informational [Page 6] RFC 5513 TLAs April 2009

Author's Address

 Adrian Farrel
 Old Dog Consulting
 EMail: adrian@olddog.co.uk

Farrel Informational [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5513.txt · Last modified: 2009/04/01 16:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki