I do not see that we need an erratum here. Section 3.1 of RFC 8929 is very clear that it adds options to EDAR/EDAC messages : ´ This specification allows the deployment of a 6LBR on the backbone where EDAR and EDAC messages coexist with classical ND. It also adds the capability to insert IPv6 ND options in the EDAR and EDAC messages. ´
What is missing is a representation that shows where it goes. There’s no much choice though. Same place as in for NS by RFC 4861. Still it would have been nice to show it. In the prefix registration draft we show EDAR and EDAC as the sum of all previous RFCs plus this. This is an occasion to show where the options go, and reciprocally not showing the options would be forgetting the changes in RFC 8929. A bientôt; Pascal > Le 30 juil. 2025 à 10:41, Eric Vyncke (evyncke) <[email protected]> a écrit : > > > Adnan, Pascal, and 6LO WG, > > To be honest, I am puzzled by this erratum: > Updating an existing RFC to fit no-yet-published draft does not respect the > process > Errata can only be verified *IF* it represents the consensus of the WG/IETF > at the time of publication, i.e., no after-thought can be added by the errata > system. > > Therefore, I intend to mark this erratum as “Hold for document update”, i.e., > for a potential rfc8929bis document if there is ever one. > > Happy to stand corrected on the above > > Regards > > -éric > > > From: Madison Church <[email protected]> > Date: Monday, 28 July 2025 at 18:06 > To: Eric Vyncke (evyncke) <[email protected]> > Cc: RFC Editor <[email protected]>, Adnan Rashid > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]> > Subject: Re: [6lo] [Editorial Errata Reported] RFC8929 (8520) > > Hi Éric, > > We are unable to verify this erratum that the submitter marked as editorial, > so we changed the Type to “Technical”. As Stream Approver, please review and > set the Status and Type accordingly (see the definitions at > https://www.rfc-editor.org/errata-definitions/). Please also see the > reporter’s email below for the corrected text. > > You may review the report at: https://www.rfc-editor.org/errata/eid8520. > > Information on how to verify errata reports can be found at: > https://www.rfc-editor.org/how-to-verify/. > > Further information on errata can be found at: > https://www.rfc-editor.org/errata.php. > > Thank you, > RFC Editor/mc > > > On Jul 27, 2025, at 9:49 AM, Adnan Rashid <[email protected]> wrote: > > > > Due to the 72-character restriction while filling in the Errata, I was > > unable to make the corrected text and format of EDAR. It should look like > > this > > > > > > Corrected Text: A 6BBR acting as a 6LR for the Registered Address can > > insert an SLLAO in the EDAR to the 6LBR in order to avoid causing a > > multicast NS(lookup) back. This enables the 6LBR to store the link-layer > > address associated with the Registered Address on a link and to serve as a > > mapping server as described in [UNICAST-LOOKUP]. This document updates the > > EDAR format, adding the Options field in Figure 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type |CodePfx|CodeSfx| Checksum | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |P=3| Reserved | TID | Registration Lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ... ROVR ... > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + Prefix + > > | | > > + (up to 120 bits, padded with 0s) + > > | | > > + +-+-+-+-+-+-+-+-+ > > | |r|Prefix Length| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Options > > +-+-+-+-+-+-+-+-+-+ > > Figure 1: EDAC Message Format > > > > On Sun, Jul 27, 2025 at 4:42 PM RFC Errata System > > <[email protected]> wrote: > > The following errata report has been submitted for RFC8929, > > "IPv6 Backbone Router". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid8520 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Adnan Rashid <[email protected]> > > > > Section: 3.1 > > > > Original Text > > ------------- > > insert an SLLAO in the EDAR to the 6LBR.... > > > > Corrected Text > > -------------- > > This document updates EDAR format, adding Options field. > > > > Notes > > ----- > > As per RFC8505, there is no room for Options in EDAR. The RFC8929 updates > > RFC8505 in Section 3.1, but does not specify the updated format of EDAR > > with the Option field. The said document must follow the latest format of > > EDAR as defined in the Prefix Registration draft > > (https://datatracker.ietf.org/doc/html/draft-ietf-6lo-prefix-registration-15) > > and update the Section. The Numbering of all other figures will be changed > > accordingly. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". (If it is spam, it > > will be removed shortly by the RFC Production Center.) Please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > will log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8929 (draft-ietf-6lo-backbone-router-20) > > -------------------------------------- > > Title : IPv6 Backbone Router > > Publication Date : November 2020 > > Author(s) : P. Thubert, Ed., C.E. Perkins, E. Levy-Abegnoli > > Category : PROPOSED STANDARD > > Source : IPv6 over Networks of Resource-constrained Nodes > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > 6lo mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > > > -- > > Regards, > > > > Adnan
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
