CSS Requirements for RFCs
draft-iab-rfc-css-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7993.
|
|
|---|---|---|---|
| Author | Heather Flanagan | ||
| Last updated | 2016-02-11 (Latest revision 2016-01-05) | ||
| Replaces | draft-flanagan-rfc-css | ||
| RFC stream | Internet Architecture Board (IAB) | ||
| Formats | |||
| Additional resources | |||
| Stream | IAB state | Community Review | |
| Consensus boilerplate | Unknown | ||
| IAB shepherd | (None) |
draft-iab-rfc-css-00
Network Working Group S. Previdi, Ed.
Internet-Draft Individual
Intended status: Standards Track C. Filsfils
Expires: July 24, 2018 K. Raza
D. Dukes
Cisco Systems, Inc.
J. Leddy
B. Field
Comcast
D. Voyer
D. Bernier
Bell Canada
S. Matsushima
Softbank
I. Leung
Rogers Communications
J. Linkova
Google
E. Aries
Facebook
T. Kosugi
NTT
E. Vyncke
Cisco Systems, Inc.
D. Lebrun
Universite Catholique de Louvain
D. Steinberg
Steinberg Consulting
R. Raszuk
Bloomberg
January 20, 2018
IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-08
Abstract
Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending an SR
header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through
any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain.
Segment Routing can be applied to the IPv6 data plane with the
addition of a new type of Routing Extension Header. This draft
Previdi, et al. Expires July 24, 2018 [Page 1]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
describes the Segment Routing Extension Header Type and how it is
used by SR capable nodes.
Requirements Language
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].
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 https://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 July 24, 2018.
Copyright Notice
Copyright (c) 2018 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
(https://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.
Previdi, et al. Expires July 24, 2018 [Page 2]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
Table of Contents
1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Data Planes supporting Segment Routing . . . . . . . . . 4
2.2. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 5
2.3.1. SR Domain in a Service Provider Network . . . . . . . 6
2.3.2. SR Domain in a Overlay Network . . . . . . . . . . . 7
3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 9
3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 11
3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 12
3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 13
3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 14
3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 14
3.1.6. NSH Carrier TLV . . . . . . . . . . . . . . . . . . . 15
3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 16
4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 17
4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 18
5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 19
5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 20
5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1. Source routing threats . . . . . . . . . . . . . . . 21
6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 21
6.1.3. Service stealing threat . . . . . . . . . . . . . . . 22
6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 22
6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 23
6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 23
6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 24
6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 25
6.2.3. Pre-shared key management . . . . . . . . . . . . . . 25
6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 26
6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 26
6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 26
6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 27
6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
7.1. Segment Routing Header TLVs Register . . . . . . . . . . 28
8. Manageability Considerations . . . . . . . . . . . . . . . . 29
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29
Previdi, et al. Expires July 24, 2018 [Page 3]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
11.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Segment Routing Documents
Segment Routing terminology is defined in
[I-D.ietf-spring-segment-routing].
The network programming paradigm
[I-D.filsfils-spring-srv6-network-programming] defines the basic
functions associated to an SRv6 SID.
Segment Routing use cases are described in [RFC7855] and
[I-D.ietf-spring-ipv6-use-cases].
Segment Routing protocol extensions are defined in
[I-D.ietf-isis-segment-routing-extensions], and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
2. Introduction
Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing],
allows a node to steer a packet through a controlled set of
instructions, called segments, by prepending an SR header to the
packet. A segment can represent any instruction, topological or
service-based. SR allows to enforce a flow through any path
(topological or service/application based) while maintaining per-flow
state only at the ingress node to the SR domain. Segments can be
derived from different components: IGP, BGP, Services, Contexts,
Locators, etc. The list of segment forming the path is called the
Segment List and is encoded in the packet header.
SR allows the use of strict and loose source based routing paradigms
without requiring any additional signaling protocols in the
infrastructure hence delivering an excellent scalability property.
The source based routing model described in
[I-D.ietf-spring-segment-routing] is inherited from the ones proposed
by [RFC1940] and [RFC2460]. The source based routing model offers
the support for explicit routing capability.
2.1. Data Planes supporting Segment Routing
Segment Routing (SR), can be instantiated over MPLS
([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document
defines its instantiation over the IPv6 data-plane based on the use-
cases defined in [I-D.ietf-spring-ipv6-use-cases].
Previdi, et al. Expires July 24, 2018 [Page 4]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
This document defines a new type of Routing Header (originally
defined in [RFC2460]) called the Segment Routing Header (SRH) in
order to convey the Segment List in the packet header as defined in
[I-D.ietf-spring-segment-routing]. Mechanisms through which segment
are known and advertised are outside the scope of this document.
2.2. SRv6 Segment
An SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are
often used as a shorter reference for "SRv6 Segment".
An SRv6-capable node N maintains a "My Local SID Table". This table
contains all the local SRv6 segments explicitly instantiated at node
N. N is the parent node for these SID's.
A local SID of N could be an IPv6 address of a local interface of N
but it does not have to. Most often, a local SID is not an address
of a local interface of N. The My Local SID Table is thus not
populated by default with all the addresses of a node.
An illustration is provided in
[I-D.filsfils-spring-srv6-network-programming].
Every SRv6 local SID instantiated has a specific instruction bounded
to it.
This information is stored in the "My Local SID Table". The "My
Local SID Table" has three main purposes:
o Define which local SID's are explicitly instantiated.
o Specify which instruction is bound to each of the instantiated
SID's.
o Store the parameters associated to such instruction (i.e. OIF,
NextHop,...).
A node may receive a packet with an SRv6 SID in the DA without an
SRH. In such case the packet should still be processed by the
Segment Routing engine.
2.3. Segment Routing (SR) Domain
We define the concept of the Segment Routing Domain (SR Domain) as
the set of nodes participating into the source based routing model.
These nodes may be connected to the same physical infrastructure
(e.g.: a Service Provider's network) as well as nodes remotely
connected to each other (e.g.: an enterprise VPN or an overlay).
Previdi, et al. Expires July 24, 2018 [Page 5]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
A non-exhaustive list of examples of SR Domains is:
o The network of an operator, service provider, content provider,
enterprise including nodes, links and Autonomous Systems.
o A set of nodes connected as an overlay over one or more transit
providers. The overlay nodes exchange SR-enabled traffic with
segments belonging solely to the overlay routers (the SR domain).
None of the segments in the SR-enabled packets exchanged by the
overlay belong to the transit networks
The source based routing model through its instantiation of the
Segment Routing Header (SRH) defined in this document equally applies
to all the above examples.
It is assumed in this document that the SRH is added to the packet by
its source, consistently with the source routing model defined in
[RFC2460]. For example:
o At the node originating the packet (host, server).
o At the ingress node of an SR domain where the ingress node
receives an IPv6 packet and encapsulates it into an outer IPv6
header followed by a Segment Routing header.
2.3.1. SR Domain in a Service Provider Network
The following figure illustrates an SR domain consisting of an
operator's network infrastructure.
(-------------------------- Operator 1 -----------------------)
( )
( (-----AS 1-----) (-------AS 2-------) (----AS 3-------) )
( ( ) ( ) ( ) )
A1--(--(--11---13--14-)--(-21---22---23--24-)--(-31---32---34--)--)--Z1
( ( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ ) )
A2--(--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--)--Z2
( ( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | ) )
( ( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| ) )
A3--(--(--15---17--18-)--(-25---26---27--28-)--(-35---36---38--)--)--Z3
( ( ) ( ) ( ) )
( (--------------) (------------------) (---------------) )
( )
(-------------------------------------------------------------)
Figure 1: Service Provider SR Domain
Previdi, et al. Expires July 24, 2018 [Page 6]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
Figure 1 describes an operator network including several ASes and
delivering connectivity between endpoints. In this scenario, Segment
Routing is used within the operator networks and across the ASes
boundaries (all being under the control of the same operator). In
this case segment routing can be used in order to address use cases
such as end-to-end traffic engineering, fast re-route, egress peer
engineering, data-center traffic engineering as described in
[RFC7855], [I-D.ietf-spring-ipv6-use-cases] and
[I-D.ietf-spring-resiliency-use-cases].
Typically, an IPv6 packet received at ingress (i.e.: from outside the
SR domain), is classified according to network operator policies and
such classification results into an outer header with an SRH applied
to the incoming packet. The SRH contains the list of segment
representing the path the packet must take inside the SR domain.
Thus, the SA of the packet is the ingress node, the DA (due to SRH
procedures described in Section 5) is set as the first segment of the
path and the last segment of the path is the egress node of the SR
domain.
The path may include intra-AS as well as inter-AS segments. It has
to be noted that all nodes within the SR domain are under control of
the same administration. When the packet reaches the egress point of
the SR domain, the outer header and its SRH are removed so that the
destination of the packet is unaware of the SR domain the packet has
traversed.
The outer header with the SRH is no different from any other
tunneling encapsulation mechanism and allows a network operator to
implement traffic engineering mechanisms so to efficiently steer
traffic across his infrastructure.
2.3.2. SR Domain in a Overlay Network
The following figure illustrates an SR domain consisting of an
overlay network over multiple operator's networks.
Previdi, et al. Expires July 24, 2018 [Page 7]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
(--Operator 1---) (-----Operator 2-----) (--Operator 3---)
( ) ( ) ( )
A1--(--11---13--14--)--(--21---22---23--24--)--(-31---32---34--)--C1
( /|\ /|\ /| ) ( |\ /|\ /|\ /| ) ( |\ /|\ /| \ )
A2--(/ | \/ | \/ | ) ( | \/ | \/ | \/ | ) ( | \/ | \/ | \)--C2
( | /\ | /\ | ) ( | /\ | /\ | /\ | ) ( | /\ | /\ | )
( |/ \|/ \| ) ( |/ \|/ \|/ \| ) ( |/ \|/ \| )
A3--(--15---17--18--)--(--25---26---27--28--)--(-35---36---38--)--C3
( ) ( | | | ) ( )
(---------------) (--|----|---------|--) (---------------)
| | |
B1 B2 B3
Figure 2: Overlay SR Domain
Figure 2 describes an overlay consisting of nodes connected to three
different network operators and forming a single overlay network
where Segment routing packets are exchanged.
The overlay consists of nodes A1, A2, A3, B1, B2, B3, C1, C2 and C3.
These nodes are connected to their respective network operator and
form an overlay network.
Each node may originate packets with an SRH which contains, in the
segment list of the SRH or in the DA, segments identifying other
overlay nodes. This implies that packets with an SRH may traverse
operator's networks but, obviously, these SRHs cannot contain an
address/segment of the transit operators 1, 2 and 3. The SRH
originated by the overlay can only contain address/segment under the
administration of the overlay (e.g. address/segments supported by A1,
A2, A3, B1, B2, B3, C1,C2 or C3).
In this model, the operator network nodes are transit nodes and,
according to [RFC2460], MUST NOT inspect the routing extension header
since they are not the DA of the packet.
It is a common practice in operators networks to filter out, at
ingress, any packet whose DA is the address of an internal node and
it is also possible that an operator would filter out any packet
destined to an internal address and having an extension header in it.
This common practice does not impact the SR-enabled traffic between
the overlay nodes as the intermediate transit networks never see a
destination address belonging to their infrastructure. These SR-
enabled overlay packets will thus never be filtered by the transit
operators.
Previdi, et al. Expires July 24, 2018 [Page 8]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
In all cases, transit packets (i.e.: packets whose DA is outside the
domain of the operator's network) will be forwarded accordingly
without introducing any security concern in the operator's network.
This is similar to tunneled packets.
3. Segment Routing Extension Header (SRH)
A new type of the Routing Header (originally defined in [RFC2460]) is
defined: the Segment Routing Header (SRH) which has a new Routing
Type, (suggested value 4) to be assigned by IANA.
The Segment Routing Header (SRH) is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Entry | Flags | Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128 bits IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
...
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128 bits IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
// Optional Type Length Value objects (variable) //
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o Next Header: 8-bit selector. Identifies the type of header
immediately following the SRH.
Previdi, et al. Expires July 24, 2018 [Page 9]
Internet-Draft IPv6 Segment Routing Header (SRH) January 2018
Internet-Draft I-D January 2016
o A fixed-width font must be used for code and artwork-tagged
sections.
o All fonts should be publicly licensed and supported by all major
web browsers.
5. Printing
The CSS must include support for a printer-friendly output. The
print rules should be a part of the embedded style sheet; consumers
of an RFC may develop their own print-specific style sheet as
desired.
6. Lists
Lists should provide ample whitespace between list elements for
legibility unless a 'compact' class is specified (e.g., .dlCompact,
.ulCompact, .olCompact).
7. CSS Classes and Attributes
This section describes the CSS classes that result in specific
changes to the natural language content of a document. A full list
of available classes, not including basic selectors, are included in
"Appendix A".
7.1. .alignCenter
To be used with '.artwork' to indicate the figure should align in the
center of the page flow.
7.2. .alignRight
To be used with '.artwork' to indicate the figure should align on the
right of the page flow.
7.3. .artwork
These classes will mostly be styled as part of .artwork. Specific
classes may include '.art-ascii-art' and '.art-svg'. Artwork will be
held in its own block of space, centered in the page flow, and will
not float. Images should have a max width of 100% so views will
scale properly across a variety of screens and devices.
Flanagan Expires July 7, 2016 [Page 5]
Internet-Draft I-D January 2016
7.3.1. .art-ascii-art
Must use a mono-spaced font.
7.3.2. .art-logo
No visible changes to the natural language content; keep in default
style. Note that such images are not currently allowed in RFCs.
7.4. .closeParen
Close the whitespace before a closing parenthesis after a <span>
block by moving the text within the block to the right and moving the
closing parenthesis to the left..
7.5. .comma
Close the whitespace before a comma after a <span> block by moving
the text within the block to the left and moving the comma to the
right.
7.6. .cref
A comment within an I-D; should be visually distinct.
For I-Ds only; not for RFCs.
7.7. .crefAnchor
A comment within an I-D; should be visually distinct.
For I-Ds only; not for RFCs.
7.8. .crefSource
A comment within an I-D; should be visually distinct.
For I-Ds only; not for RFCs.
7.9. .dlCompact
Use less spacing on a definition list than the default.
7.10. .dlHanging
Use the standard hanging indent for a definition list; indent terms.
Flanagan Expires July 7, 2016 [Page 6]
Internet-Draft I-D January 2016
7.11. .dlParallel
Do not use the standard hanging indent for a definition list; align
terms and definitions along left side.
7.12. .docInfo
Hide from visible content.
7.13. .eref
Standard link formatting (underlined, change in color).
7.14. .finalized
Hide from visible content.
7.15. .fullStop
Close the whitespace before a period or full stop after a <span>
block by moving the text within the block to the left and moving the
period to the right.
7.16. .note
Notes should be emphasized and distinct from normal paragraph text.
7.16.1. .rfcEditorRemove
An RFC Editor note may be added after the standard boilerplage. It
should be visually distinct to highlight final removal of the note by
the RFC Editor.
7.17. .olCompact
Use less spacing on a numbered list than the default.
7.18. .olPercent
If the style attribute from the source XML contains a percent sign, a
particular style setting will be required to make this setting behave
like an HTML ordered list.
7.19. .openParen
Close the whitespace after an opening parenthesis and before a <span>
block by moving the text within the block to the left and moving the
opening parenthesis to the right.
Flanagan Expires July 7, 2016 [Page 7]
Internet-Draft I-D January 2016
7.20. .pilcrow
Pilcrows, when used as described in draft-hildebrand-html-rfc, should
appear at the end of the paragraph, artwork, or sourcecode segment.
They should not appear until moused-over. They should not show when
printed, and should not be selected when copied with a copy/paste
function.
7.21. .relref
Should be clearly distinguished as links.
7.22. .rendered
Hide from visible content.
7.23. .sourcecode
Code examples or components should be in a fixed-width font if the
human language used has an available fixed-width font option, and
should be visually distinct. If no fixed-width font is available,
use the default font for that human language.
7.24. .toc
The table of contents should be clearly distinguished using an
indented, ordered list with the list style set to 'none', allowing
for hyperlinked, in-line dotted number notation (e.g., 1., 1.1.,
1.1.1.).
7.25. .type
No visible changes to the natural language content; keep in default
style.
7.26. .ulCompact
Use less spacing on a bulleted list than the default.
7.27. .ulEmpty
Indent from the margin of the previous paragraph.
7.28. .url
Should be clearly distinguished as links.
Flanagan Expires July 7, 2016 [Page 8]
Internet-Draft I-D January 2016
7.29. .xref
Should be clearly distinguished as links.
8. Security Considerations
Security vulnerabilities can be introduced through the CSS. How much
detail do we need to go into here to say "don't do foolish things and
introduce security issues?"
9. IANA Considerations
This draft contains no action for IANA
10. Acknowledgements
With many thanks to the RFC Format Design Team for their efforts in
making this transition successful: Nevil Brownlee (ISE), Tony Hansen,
Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach,
Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.
Additional thanks to Arlen Johnson of Spherical Cow Group, LLC, for
his assistance in clarifying the requirements in more CSS designer-
friendly language.
11. Draft Change Log
To be removed before publication
11.1. Changes from -02 to -03
Moved Appendix to correct location; fixed typos; moved lang-* to
Appendix,
11.2. Changes from -01 to -02
Adjusted class names where possible to a common naming pattern
(CamelCase).
Added alignCenter, alignRight, dlHanging, closedParen, openParen,
ulEmpty
11.3. Changes from -00 to -01
Moved full list of classes to Appendix; only discussed classes that
will have visible changes to the text in the body
Introduction: text regarding expected future changes added.
Flanagan Expires July 7, 2016 [Page 9]
Internet-Draft I-D January 2016
Body: added text regarding anchors and tags; this text also applied
to .relref, .url, .xref
Artwork: clarified non-floating behavior of artwork
List behavior: clarified the behavior of .ulCompact, .olCompact, and
.dlCompact as distinct from default list behavior; clarified behavior
of .dlparallel
Note: clarified text around behavior of notes
RFC: added additional class to allow the CSS to distinguish between
RFCs and Internet Drafts if desired
TOC: clarified text around behavior of table of contents
12. Normative References
[HTMLBP] W3C, "Best Practices for Authoring HTML Current Status",
n.d., <http://www.w3.org/standards/techs/htmlbp>.
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
Headers, and Boilerplates", RFC 5741,
DOI 10.17487/RFC5741, December 2009,
<http://www.rfc-editor.org/info/rfc5741>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
DOI 10.17487/RFC7322, September 2014,
<http://www.rfc-editor.org/info/rfc7322>.
[I-D.hildebrand-html-rfc]
Hildebrand, J. and P. Hoffman, "HyperText Markup Language
Request For Comments Format", draft-hildebrand-html-rfc-10
(work in progress), August 2015.
[I-D.flanagan-rfc-framework]
Flanagan, H., "RFC Format Framework", draft-flanagan-rfc-
framework-08 (work in progress), December 2015.
Appendix A. List of classes
This section lists all the CSS classes. Except for those also listed
above in section 7, none of these result in specific changes to the
natural language content of a document.
o .adr
o .alignCenter
Flanagan Expires July 7, 2016 [Page 10]
Internet-Draft I-D January 2016
o .alignRight
o .annotation
o .artwork
.art-ascii-art
.art-logo
.art-svg
o .ascii
o .author
o .authors
o .bcp14
o .city
o .closeParen
o .comma
o .compact
o .country-name
o .cref
o .crefAnchor
o .crefSource
o .dlCompact
o .dlHanging
o .dlParallel
o .docInfo
o .email
o .eref
Flanagan Expires July 7, 2016 [Page 11]
Internet-Draft I-D January 2016
o .finalized
o .fn
o .fullStop
o .index
o .indexChar
o .indexIndex
o .indexItem
o .indexPrimary
o .indexSubItem
o .initial
o .iref
o .irefItem
o .irefRefs
o .irefSubItem
o .label
o .locality
o .nameRole
o .note
.rfcEditorRemove
o .olCompact
o .olPercent
o .openParen
o .org
o .organization
Flanagan Expires July 7, 2016 [Page 12]
Internet-Draft I-D January 2016
o .pilcrow
o .postal-code
o .published
o .refAuthor
o .refContent
o .refDate
o .refTitle
o .reference
o .referenceGroup
o .region
o .relref
o .rendered
o .RFC
o .rfcEditorRemove
o .role
o .selfRef
o .series
o .seriesInfo
o .sourcecode
.lang-*
o .street-address
o .status
o .street-address
o .surname
Flanagan Expires July 7, 2016 [Page 13]
Internet-Draft I-D January 2016
o .tel
o .toc
o .type
o .ulCompact
o .url
o .workgroup
o .xref
o .vcard
Author's Address
Heather Flanagan
RFC Editor
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220
Flanagan Expires July 7, 2016 [Page 14]