On Thu, 18 Sep 2008 10:07:12 -0700 (PDT) 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 = = = = = = = Hi, My comment isn't similar to the rest of the mail threads here: I find the use of the word "codepoint" confusing here. It apparently means something different to some readers (or writers) here. To me (and I'm almost never unique in things like this), it means a point in a character set space. See http://en.wikipedia.org/wiki/Codepoint or possibly http://code.google.com/search/#q=codepoint . Maybe here it means an extension of that, like "a (virtual) point in some world network address space." Is that close? Perhaps it should define what a codepoint is or use some other word/phrase for it. > 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. Regards, --- ~Randy _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf