As you have seen by now, the status for this erratum is ‘hold for document update’.
I am still unclear about the -16 changing the technical content of prefix delegation though... Regards -éric From: Adnan Rashid <[email protected]> Date: Wednesday, 30 July 2025 at 20:25 To: Michael Richardson <[email protected]> Cc: Eric Vyncke (evyncke) <[email protected]>, [email protected] <[email protected]>, Pascal Thubert <[email protected]> Subject: Re: [6lo] Re: [Editorial Errata Reported] RFC8929 (8520) Yes Michael, the errata system has text limit. That's why I explained it on the email also on the other thread where IESG approved the Prefix Registration Draft. Lets concise, the OPTION field in EDAR/EDAC was not defined in the figure of RFC 8929. Pascal already fixed this issue in Approved Prefix Registration Draft version 16. I am not sure to make another draft or not, but yes it is an interoperability issue as for as my understanding. But on the other hand text of the RFC8929 clearly state about OPTION field. Regards, AR On Wed, Jul 30, 2025, 19:33 Michael Richardson <[email protected]<mailto:mcr%[email protected]>> wrote: trimming to 6lo and interested parties. Eric Vyncke \(evyncke\) <[email protected]<mailto:[email protected]>> wrote: > To be honest, I am puzzled by this erratum: I am even more. > 1. Updating an existing RFC to fit no-yet-published draft does not > respect the process 2. 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. First, I think we have a communication issue because Adnan says that the errata forms didn't let him provide accurate corrected text. But, I can't figure out what text he is correcting. That diagram is not in RFC8929. The text is in RFC8929, in section 3.1, paragraph "three" What I see is that it inserts that diagram. I don't think that it changes any behaviour, just clarifies what the packet format is. As diagrams are not supposed to be normative on their own, the errata ought to explain all the fields too. > Therefore, I intend to mark this erratum as “Hold for document update”, > i.e., for a potential rfc8929bis document if there is ever one. I think that's probably the only answer anyway. If Adnan thinks that this is likely (or already has!) caused an inteoperability issue, then an Updates: document might be in order. At least, an I-D to discuss. In general, the entire 6lo(wpan) document sets needs a consolidated -bis set. I find I have to wander forward and back through many documents to remember everything. I also don't think anyone has time/energy to do that work now. -- Michael Richardson <[email protected]<mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
