We’ve run into problems with the RFC5737 documentation examples not being suitable for the types of exampes we needed.
Previously, the suggestion was to put that explanation in the draft, to prevent recurrence of a complaint. e.g. https://mailarchive.ietf.org/arch/msg/sidr/0d99F1FOLGugyhM9JzmoDCE8KDA However, the errata in this case is not posed as a complaint about the failure to use the documentation cases. The errata says 666 is not a valid octet for an ipv4 address That is a true statement. Randy’s previous response was: 666 was not accidental. That is a true statement. But I believe a short note to explain the non-accidental use of 666 is something like: In some cultures, the number 666 is supposed to be the number of “the beast”, i.e. the devil, and therefore a sign of evil. The text chooses this number 666 in the prefix 10.0.666.0/24 with the intent to imply that the announcement is deliberately evil, disregarding the fact that 666 is not a legitimate ipv4 prefix octet. Of course, I’m not the author, so I could be wrong. —Sandy > On Mar 25, 2017, at 7:36 AM, Randy Bush <[email protected]> wrote: > >> I am marking this report as "Held for Document Update" [1], which >> means that the author might consider its merits for a future update. >> If the use of the "666" octet was intentional, then a short note >> explaining might be appropriate to avoid further confusion. > > problem is it's not a short note. > > In the current internet routing ecology, a /24 is the longest prefix > which has a good chance at global propagation. The prefix allocated > by RFC 5737, with much verbosity, are three non-contiguous /24s. > The result is that documents which want to discuss routable prefixes > which involve subnetting can not use space from RFC 5737. This is a > general problem which someone (else) should fix. > > In RFC 7115, the subject of this erratum, routeable and subnettable > examples were needed. So the well-known private network 10/8, see > RFC 1918, was used in the examples. To indicate that it was not > really intended to be used, an impossible octet, 666, was chosen. > > this was explained a number of times as this rfc went through the > original sausage factory. > > randy > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
