asciidoctor-rfc 0.9.0 → 0.9.1

data/spec/examples/rfc748.md.2.xml.txt

@@ -0,0 +1,168 @@
+
+
+
+
+Network Working Group                                         M. Crispin
+Internet-Draft                                                     SU-AI
+Intended status: Informational                             April 1, 1978
+Expires: October 3, 1978
+
+
+                      TELNET RANDOMLY-LOSE Option
+                                rfc-748
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on October 3, 1978.
+
+Copyright Notice
+
+   Copyright (c) 1978 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                  Expires October 3, 1978                [Page 1]
+
+Internet-Draft         TELNET RANDOMLY-LOSE Option            April 1978
+
+
+Table of Contents
+
+   1.  Command name and code . . . . . . . . . . . . . . . . . . . .   2
+   2.  Command meanings  . . . . . . . . . . . . . . . . . . . . . .   2
+   3.  Default . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   4.  Motivation for the option . . . . . . . . . . . . . . . . . .   2
+   5.  Description of the option . . . . . . . . . . . . . . . . . .   3
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   3
+
+1.  Command name and code
+
+                           RANDOMLY-LOSE    256
+
+2.  Command meanings
+
+   IAC WILL RANDOMLY-LOSE:
+      The sender of this command REQUESTS permission to, or confirms
+      that it will, randomly lose.
+
+   IAC WON'T RANDOMLY-LOSE:
+      The sender of this command REFUSES to randomly lose.
+
+   IAC DO RANDOMLY-LOSE:
+      The sender of this command REQUESTS that the receiver, or grants
+      the receiver permission to, randomly lose.
+
+   IAC DON'T RANDOMLY-LOSE:
+      The command sender DEMANDS that the receiver not randomly lose.
+
+3.  Default
+
+       WON'T RANDOMLY-LOSE
+
+       DON'T RANDOMLY-LOSE
+
+   i.e., random lossage will not happen.
+
+4.  Motivation for the option
+
+   Several hosts appear to provide random lossage, such as system
+   crashes, lost data, incorrectly functioning programs, etc., as part
+   of their services.  These services are often undocumented and are in
+   general quite confusing to the novice user.  A general means is
+   needed to allow the user to disable these features.
+
+
+
+
+
+
+
+Crispin                  Expires October 3, 1978                [Page 2]
+
+Internet-Draft         TELNET RANDOMLY-LOSE Option            April 1978
+
+
+5.  Description of the option
+
+   The normal mode does not allow random lossage; therefore the system
+   is not allowed to crash, mung user files, etc.  If the server wants
+   to provide random lossage, it must first ask for permission from the
+   user by sending IAC WILL RANDOMLY-LOSE.
+
+   If the user wants to permit the server to randomly lose, it replys
+   with IAC DO RANDOMLY-LOSE.  Otherwise it sends IAC DONT RANDOMLY-
+   LOSE, and the server is forbidden from randomly losing.
+
+   Alternatively, the user could request the server to randomly lose, by
+   sending IAC DO RANDOMLY-LOSE, and the server will either reply with
+   IAC WILL RANDOMLY-LOSE, meaning that it will then proceed to do some
+   random lossage (garbaging disk files is recommended for an initial
+   implementation).  Or, it could send IAC WONT RANDOMLY-LOSE, meaning
+   that it insists upon being reliable.
+
+   Since this is implemented as a TELNET option, it is expected that
+   servers which do not implement this option will not randomly lose;
+   ie, they will provide 100% reliable uptime.
+
+Author's Address
+
+   M. Crispin
+   SU-AI
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                  Expires October 3, 1978                [Page 3]

data/spec/examples/rfc7511.md.2.xml.txt

@@ -0,0 +1,448 @@
+
+
+
+
+Network Working Group                                         M. Wilhelm
+Internet-Draft                                             April 1, 2015
+Intended status: Informational
+Expires: October 3, 2015
+
+
+                        Scenic Routing for IPv6
+                                rfc-7511
+
+Abstract
+
+   This document specifies a new routing scheme for the current version
+   of the Internet Protocol version 6 (IPv6) in the spirit of "Green
+   IT", whereby packets will be routed to get as much fresh-air time as
+   possible.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on October 3, 2015.
+
+Copyright Notice
+
+   Copyright (c) 2015 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 1]
+
+Internet-Draft           Scenic Routing for IPv6              April 2015
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
+   2.  Scenic Routing  . . . . . . . . . . . . . . . . . . . . . . .   3
+     2.1.  Scenic Routing Option (SRO) . . . . . . . . . . . . . . .   3
+   3.  Implications  . . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  Routing Implications  . . . . . . . . . . . . . . . . . .   5
+     3.2.  Implications for Hosts  . . . . . . . . . . . . . . . . .   5
+     3.3.  Proxy Servers . . . . . . . . . . . . . . . . . . . . . .   6
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
+   6.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   6
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
+   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   8
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8
+
+1.  Introduction
+
+   In times of Green IT, a lot of effort is put into reducing the energy
+   consumption of routers, switches, servers, hosts, etc., to preserve
+   our environment.  This document looks at Green IT from a different
+   angle and focuses on network packets being routed and switched around
+   the world.
+
+   Most likely, no one ever thought about the millions of packets being
+   disassembled into bits every second and forced through copper wires
+   or being shot through dark fiber lines by powerful lasers at
+   continuously increasing speeds.  Although RFC 5841 [RFC5841] provided
+   some thoughts about Packet Moods and began to represent them as a TCP
+   option, this doesn't help the packets escape their torturous routine.
+
+   This document defines another way to deal with Green IT for traffic
+   and network engineers and will hopefully aid the wellbeing of a
+   myriad of network packets around the world.  It proposes Scenic
+   Routing, which incorporates the green-ness of a network path into the
+   routing decision.  A routing engine implementing Scenic Routing
+   should therefore choose paths based on Avian IP Carriers [RFC1149]
+   and/or wireless technologies so the packets will get out of the
+   miles/kilometers of dark fibers that are in the ground and get as
+   much fresh-air time and sunlight as possible.
+
+   As of the widely known acceptance of the current version of the
+   Internet Protocol (IPv6), this document only focuses on version 6 and
+   ignores communication still based on Vintage IP [RFC0791].
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 2]
+
+Internet-Draft           Scenic Routing for IPv6              April 2015
+
+
+1.1.  Conventions and Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   Additionally, the key words "*MIGHT*", "*COULD*", "*MAY WISH TO*",
+   "*WOULD PROBABLY*", "*SHOULD CONSIDER*", and "*MUST (BUT WE KNOW YOU
+   WON'T)*" in this document are to interpreted as described in RFC 6919
+   [RFC6919].
+
+2.  Scenic Routing
+
+   Scenic Routing can be enabled with a new option for IPv6 datagrams.
+
+2.1.  Scenic Routing Option (SRO)
+
+   The Scenic Routing Option (SRO) is placed in the IPv6 Hop-by-Hop
+   Options Header that must be examined by every node along a packet's
+   delivery path [RFC2460].
+
+   The SRO can be included in any IPv6 datagram, but multiple SROs MUST
+   NOT be present in the same IPv6 datagram.  The SRO has no alignment
+   requirement.
+
+   If the SRO is set for a packet, every node en route from the packet
+   source to the packet's final destination MUST preserve the option.
+
+   The following Hop-by-Hop Option is proposed according to the
+   specification in Section 4.2 of RFC 2460 [RFC2460].
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                     |  Option Type  | Option Length |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   SRO Param   |                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 1: Scenic Routing Option Layout
+
+   Option Type
+      8-bit identifier of the type of option.  The option identifier
+      0x0A (On Air) is proposed for Scenic Routing.
+
+
+
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 3]
+
+Internet-Draft           Scenic Routing for IPv6              April 2015
+
+
+              HEX         act  chg  rest
+              ---         ---  ---  -----
+              0A           00   0   01010     Scenic Routing
+
+                   Figure 2: Scenic Routing Option Type
+
+      The highest-order two bits are set to 00 so any node not
+      implementing Scenic Routing will skip over this option and
+      continue processing the header.  The third-highest-order bit
+      indicates that the SRO does not change en route to the packet's
+      final destination.
+
+   Option Length
+      8-bit unsigned integer.  The length of the option in octets
+      (excluding the Option Type and Option Length fields).  The value
+      MUST be greater than 0.
+
+   SRO Param
+      8-bit identifier indicating Scenic Routing parameters encoded as a
+      bit string.
+
+                             +-+-+-+-+-+-+-+-+
+                             | SR A W AA X Y |
+                             +-+-+-+-+-+-+-+-+
+
+                   Figure 3: SRO Param Bit String Layout
+
+      The highest-order two bits (SR) define the urgency of Scenic
+      Routing:
+
+         00 - Scenic Routing MUST NOT be used for this packet.
+
+         01 - Scenic Routing *MIGHT* be used for this packet.
+
+         10 - Scenic Routing SHOULD be used for this packet.
+
+         11 - Scenic Routing MUST be used for this packet.
+
+      The following BIT (A) defines if Avian IP Carriers should be used:
+
+         0 - Don't use Avian IP Carrier links (maybe the packet is
+         afraid of pigeons).
+
+         1 - Avian IP Carrier links may be used.
+
+      The following BIT (W) defines if wireless links should be used:
+
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 4]
+
+Internet-Draft           Scenic Routing for IPv6              April 2015
+
+
+         0 - Don't use wireless links (maybe the packet is afraid of
+         radiation).
+
+         1 - Wireless links may be used.
+
+      The following two bits (AA) define the affinity for link types:
+
+         00 - No affinity.
+
+         01 - Avian IP Carriers SHOULD be preferred.
+
+         10 - Wireless links SHOULD be preferred.
+
+         11 - RESERVED
+
+      The lowest-order two bits (XY) are currently unused and reserved
+      for future use.
+
+3.  Implications
+
+3.1.  Routing Implications
+
+   If Scenic Routing is requested for a packet, the path with the known
+   longest Avian IP Carrier and/or wireless portion MUST be used.
+
+   Backbone operators who desire to be fully compliant with Scenic
+   Routing *MAY WISH TO* -- well, they SHOULD -- have separate MPLS
+   paths ready that provide the most fresh-air time for a given path and
+   are to be used when Scenic Routing is requested by a packet.  If such
+   a path exists, the path MUST be used in favor of any other path, even
+   if another path is considered cheaper according to the path costs
+   used regularly, without taking Scenic Routing into account.
+
+3.2.  Implications for Hosts
+
+   Host systems implementing this option of receiving packets with
+   Scenic Routing requested MUST honor this request and MUST activate
+   Scenic Routing for any packets sent back to the originating host for
+   the current connection.
+
+   If Scenic Routing is requested for connections of local origin, the
+   host MUST obey the request and route the packet(s) over a wireless
+   link or use Avian IP Carriers (if available and as requested within
+   the SRO Params).
+
+   System administrators *MIGHT* want to configure sensible default
+   parameters for Scenic Routing, when Scenic Routing has been widely
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 5]
+
+Internet-Draft           Scenic Routing for IPv6              April 2015
+
+
+   adopted by operating systems.  System administrators SHOULD deploy
+   Scenic Routing information where applicable.
+
+3.3.  Proxy Servers
+
+   If a host is running a proxy server or any other packet-relaying
+   application, an application implementing Scenic Routing MUST set the
+   same SRO Params on the outgoing packet as seen on the incoming
+   packet.
+
+   Developers *SHOULD CONSIDER* Scenic Routing when designing and
+   implementing any network service.
+
+4.  Security Considerations
+
+   The security considerations of RFC 6214 [RFC6214] apply for links
+   provided by Avian IP Carriers.
+
+   General security considerations of wireless communication apply for
+   links using wireless technologies.
+
+   As the user is able to influence where flows and packets are being
+   routed within the network, this *MIGHT* influence traffic-engineering
+   considerations and network operators *MAY WISH TO* take this into
+   account before enabling Scenic Routing on their devices.
+
+5.  IANA Considerations
+
+   This document defines a new IPv6 Hop-by-Hop Option, the Scenic
+   Routing Option, described in Section 2.1.  If this work is
+   standardized, IANA is requested to assign a value from the
+   "Destination Options and Hop-by-Hop Options" registry for the purpose
+   of Scenic Routing.
+
+   There are no IANA actions requested at this time.
+
+6.  Related Work
+
+   As Scenic Routing is heavily dependent on network paths and routing
+   information, it might be worth looking at designing extensions for
+   popular routing protocols like BGP or OSPF to leverage the full
+   potential of Scenic Routing in large networks built upon lots of
+   wireless links and/or Avian IP Carriers.  When incorporating
+   information about links compatible with Scenic Routing, the routing
+   algorithms could easily calculate the optimal paths providing the
+   most fresh-air time for a packet for any given destination.
+
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 6]
+
+Internet-Draft           Scenic Routing for IPv6              April 2015
+
+
+   This would even allow preference for wireless paths going alongside
+   popular or culturally important places.  This way, the packets don't
+   only avoid the dark fibers, but they get to see the world outside of
+   the Internet and are exposed to different cultures around the globe,
+   which may help build an understanding of cultural differences and
+   promote acceptance of these differences.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <https://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC5841]  Hay, R. and W. Turkal, "TCP Option to Denote Packet Mood",
+              RFC 5841, DOI 10.17487/RFC5841, April 2010,
+              <https://www.rfc-editor.org/info/rfc5841>.
+
+   [RFC6214]  Carpenter, B. and R. Hinden, "Adaptation of RFC 1149 for
+              IPv6", RFC 6214, DOI 10.17487/RFC6214, April 2011,
+              <https://www.rfc-editor.org/info/rfc6214>.
+
+   [RFC6919]  Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
+              for Use in RFCs to Indicate Requirement Levels", RFC 6919,
+              DOI 10.17487/RFC6919, April 2013,
+              <https://www.rfc-editor.org/info/rfc6919>.
+
+7.2.  Informative References
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
+              DOI 10.17487/RFC0791, September 1981,
+              <https://www.rfc-editor.org/info/rfc791>.
+
+   [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>.
+
+
+
+
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 7]
+
+Internet-Draft           Scenic Routing for IPv6              April 2015
+
+
+Appendix A.  Acknowledgements
+
+   The author wishes to thank all those poor friends who were kindly
+   forced to read this document and that provided some nifty comments.
+
+Author's Address
+
+   Maximilian Wilhelm
+   Paderborn, NRW
+   Germany
+
+   Phone: +49 176 62 05 94 27
+   Email: max@rfc2324.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wilhelm                  Expires October 3, 2015                [Page 8]