RFC Errata Update for Working Group Chairs

[RFC Editor <[e-mail]>]

WG chairs,

We have made some updates to the RFC errata system and would like to
inform you of the new features and explain how these features may
impact your working group.

1) We'd like to bring your attention to the improved search for RFC
errata on http://www.rfc-editor.org/errata.php. You can search by WG
acronym and other information.

Please contact your Area Director if you find errata reports that need
correction.  For example, the Type (Editorial/Technical) may be
incorrect.  Area Directors can log in to verify errata in RFCs
produced by the IETF stream, so if you want to to recommend that a
report be Verified/Rejected/Held, then please let the relevant AD
know. (For the meanings of Status and Type for RFC errata, please see
http://www.rfc-editor.org/status_type_desc.html.)

2) Previously, the initial report message was sent to the authors of
the RFC and the relevant WG chairs and ADs when the RFC was a product
of a WG.  The IESG has suggested that the WG mailing list be CC'ed on
these messages, and we have implemented this feature.  For example,
[e-mail] would now be CC'ed on the message below.  The idea is to
notify the WG of the new report and potentially initiate a discussion
of the validity of the report among those who are familiar with the
content.  This will allow the verifier to update the erratum so that
its Status and Notes capture the conclusion of any discussion.

Please distribute this information to your working groups as you see
fit, and let us know if you have any comments or concerns.

Thank you.

RFC Editor

>From: RFC Errata System <[e-mail]>
>Date: October 23, 2008 6:05:46 PM PDT
>To: [e-mail], [e-mail], [e-mail],
>[e-mail], [e-mail], [e-mail]
>Cc: [e-mail], [e-mail]
>Subject: [Technical Errata Reported] RFC4632 (1577)
>
>
>The following errata report has been submitted for RFC4632,
>"Classless Inter-domain Routing (CIDR): The Internet Address
>Assignment and Aggregation Plan".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errata_search.php?rfc=4632&eid=1577
>
>--------------------------------------
>Type: Technical
>Reported by: Tony Li <[e-mail]>
>
>Section: 3.1
>
>Original Text
>-------------
>   For example, the legacy "Class B" network 172.16.0.0, with an
>implied
>   network mask of 255.255.0.0, is defined as the prefix
>172.16.0.0/16,
>   the "/16" indicating that the mask to extract the network
>portion of
>   the prefix is a 32-bit value where the most significant 16 bits
are
>   ones and the least significant 16 bits are zeros.  Similarly, the
>   legacy "Class C" network number 192.168.99.0 is defined as the
>prefix
>   192.168.99.0/24; the most significant 24 bits are ones and the
>least
>   significant 8 bits are zeros.
>
>
>
>Corrected Text
>--------------
>   For example, the legacy "Class B" network 172.16.0.0, with an
>implied
>   network mask of 255.255.0.0, is defined as the prefix
>172.16.0.0/16,
>   the "/16" indicating that the mask to extract the network
>portion of
>   the prefix is a 32-bit value where the most significant 16 bits
are
>   ones and the least significant 16 bits are zeros.  Similarly, the
>   legacy "Class C" network number 192.168.99.0 is defined as the
>prefix
>   192.168.99.0/24; the most significant 24 bits are ones and the
>least
>   significant 8 bits are zeros.
>
>   In cases where a prefix has 1, 2, or 3 trailing insignificant
>   octets, it is permissible to elide the insignificant octets and
>   trailing '.' separators. Thus, 172.16.0.0/16 may also be
>represented
>   as 172.16/16, and 192.168.99.0/24 is equivalent to 192.168.99/24.
>
>
>
>
>Notes
>-----
>This adds some clarifying text and documents a common convention
>for displaying prefixes.  It was never the intention of the authors
>to exclude the alternative notation and it has since come into
>vogue.  It should be explicitly documented as being acceptable.
>
>Instructions:
>-------------
>This errata is currently posted as "Reported". If necessary, please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party (IESG)
>can log in to change the status and edit the report, if necessary.
>
>--------------------------------------
>RFC4632 (draft-ietf-grow-rfc1519bis-04)
>--------------------------------------
>Title               : Classless Inter-domain Routing (CIDR): The
>Internet Address Assignment and Aggregation Plan
>Publication Date    : August 2006
>Author(s)           : V. Fuller, T. Li
>Category            : BEST CURRENT PRACTICE
>Source              : Global Routing Operations
>Area                : Operations and Management
>Stream              : IETF
>Verifying Party     : IESG
>