On Tue, Dec 1, 2015 at 2:59 PM, Warren Turkal <[email protected]> wrote:
> Was it proper to classify this at technical errata? I wasn't sure about > that. > Seems reasonable. --dmm > > Thanks, > wt > > On Tue, Dec 1, 2015 at 2:56 PM, David Meyer <[email protected]> wrote: > >> Definitely a good catch. --dmm >> >> On Tue, Dec 1, 2015 at 2:12 PM, RFC Errata System < >> [email protected]> wrote: >> >>> The following errata report has been submitted for RFC4384, >>> "BGP Communities for Data Collection". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4384&eid=4550 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Warren Turkal <[email protected]> >>> >>> Section: 4.1 >>> >>> Original Text >>> ------------- >>> The chart at the bottom of 4.1: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 0x00 | 0x0008 | 0x2A7C | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 0x00 | 0x00 | 0x10F2 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Corrected Text >>> -------------- >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 0x00 | 0x08 | 0x2A7C | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | 0x00 | 0x00 | 0x10F2 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Notes >>> ----- >>> The second group has a hex value that looks like two octets: >>> \\"0x0008\\". If I am interpreting the chart, extended community RFCs, and >>> the extended community IANA registry correctly, the second group should be >>> a single octet (i.e. \\"0x08\\"). >>> >>> Also, the same error is in the Section 4.2 chart as well. >>> >>> Instructions: >>> ------------- >>> This erratum 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. >>> >>> -------------------------------------- >>> RFC4384 (draft-ietf-grow-collection-communities-06) >>> -------------------------------------- >>> Title : BGP Communities for Data Collection >>> Publication Date : February 2006 >>> Author(s) : D. Meyer >>> Category : BEST CURRENT PRACTICE >>> Source : Global Routing Operations >>> Area : Operations and Management >>> Stream : IETF >>> Verifying Party : IESG >>> >>> >> >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
