I think that this statement is reasonably clear, and I support it.
To be pedantic, a statement that an RFC author's contact information
is not an example could be added.
Regards
Marshall
On Sep 18, 2008, at 1:07 PM, The IESG wrote:
The IESG has received the attached text for a proposed IESG Statement:
IESG Statement on the Usage of Assignable Codepoints in Specification
Examples
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this proposed IESG statement. Please send
substantive
comments to the ietf@xxxxxxxx mailing lists by 2008-10-02.
Exceptionally,
comments may be sent to iesg@xxxxxxxx instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
On behalf of the IESG,
Russ Housley
= = = = = = Text of Proposed IESG Statement = = = = = = =
IESG Statement on the Usage of Assignable Codepoints in Specification
Examples
Protocol specifications and other documents intended for RFC
publication
often include useful examples with correctly formatted and
syntactically
valid codepoints. Example codepoints may be names, addresses or
assigned
numbers, such as email addresses, domain names, IP addresses or
ports. The
value used in an example may already have been assigned or may become
assigned in the future to entities on the Internet, and this can cause
problems.
Codepoints used in specification examples can result (and have in the
past resulted) in some amount of unwanted traffic. The impact of this
unwanted traffic varies highly depending on the context and nature
of the
example. Some examples of causing unwanted traffic include:
1) Spam: apparently valid email addresses in an RFC are widely
believed
to have been harvested and included in Spam lists. The domain may
receive
spam at mailboxes other than the one used in the example email
address, if
the domain name is used in common name or brute force attacks.
2) Test code: when test implementors use the examples from the
specification, sometimes they forget to change the example addresses,
potentially resulting in unwanted traffic to the example address.
3) Configuration files: example configuration files are commonly
copied
and then edited. Configuration files may be distributed to a large
number
of hosts as part of a software package. That software may be
deployed or
tested before removing the example address. In several cases, this
class
of error caused substantial impact on the resource named. The
results were
effectively distributed denial of service attacks and increased
operational costs for the targets.
Use of examples in RFCs is not a new concern. The issues have been
known
and considered for several types of codepoints. BCP 32 (RFC 2606 -
Reserved Top Level DNS Names) reserved some domain names for use in
examples. RFC 3330 (Special-Use IPv4 Addresses) and RFC 5156
(Special-Use
IPv6 Addresses) assigned some IP address ranges specially for
examples and
documentation. RFC4735 (Example Media Types for Use in Documentation)
registered one example media type and one subtype under each of the
registered media types for example use. Other similar specifications
and
reserved codepoints exist.
The IESG understands that not all types of codepoints have reserved
values or ranges for documentation and examples. The IESG also
understands
that sometimes the use of reserved values makes examples harder to
read or
less apt. In these cases authors have several options:
- The specification itself can request further values or codepoints to
be assigned.
- The author can get permission from the holders of assigned values.
However, the stability of the assignment needs to be considered.
- The author can request approval for use of non-example addresses,
names or codepoints, with an analysis of the expected effect of this
use.
Documents that update previously published RFCs fall under less
pressure
to update examples that have already been published. The use of
reserved
codepoints is still recommended in these documents when new examples
are
added or when examples change.
Upon publication of this statement, the IESG will apply the following
requirements to documents submitted for publication as RFCs in the
IETF
Stream. The document SHOULD use values reserved for examples where
such
assignments exist (e.g. BCP 32, RFC 3330, RFC 4735, and RFC 5156)
and when
the necessary semantic can be communicated clearly enough. If
unassigned
codepoints are desired it is RECOMMENDED that those codepoints be
assigned
or registered. If assigned codepoints are desired, it is
RECOMMENDED that
the authors get approval from the current codepoint holder.
Designers of
new protocols SHOULD consider example usage and register or assign
values
for example usage.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf