Re: Call for review of proposed IESG Statement on Examples

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]