Hi Ketan and *authors, We will let you know once the authors have finished their current changes and our files have been updated.
*Authors, regarding the change in Section 11.10 (the update of “Transient Failure” to “Reserved” for value 1), we do see at least one potential mismatch in the running text. Please review and let us know if there are any other instances and how we may update for consistency. Section 5.1: A status of "Transient Failure" (see Section 11.10) is an indication that the P-DAO-REQ may be retried after a reasonable time that depends on the deployment. Best regards, Karen Moore RFC Production Center > On Mar 30, 2026, at 6:45 AM, Ketan Talaulikar <[email protected]> wrote: > > Hi Karen, > > I will wait for the authors to cross-check the IANA considerations sections > before approving. > > Thanks, > Ketan > > > On Mon, Mar 30, 2026 at 1:06 PM Ketan Talaulikar <[email protected]> > wrote: > Hi Karen, > > I was waiting for all the changes to be done and the final AUTH48 version to > stabilize before taking a look. Seems like we are not there yet. > > While most of the changes are text improvements and clarifications that are > editorial in nature (and there are a lot of them!), there are also some other > changes. > > Looking at IANA considerations, the change in section 11.12 was clearly a > miss, but then the unassigned bits have not been updated. However, I am not > sure if the changes in section 11.10 are consistent with the text. Can the > authors please cross-check? > > Please let me know once we are truly done ... as in done! > > Thanks, > Ketan > > > On Thu, Mar 26, 2026 at 12:47 AM Karen Moore <[email protected]> > wrote: > Hello Ines, Ketan, Pascal, and *Michael, > > Thank you for your comments. Please note that we will need Ketan to provide > approval of the sections listed below in addition to the changes being made > to the figures. We also await approval of the document from Michael. > > > *Ketan, please review the changes in the following sections and let us know > > if you approve. > > > > Section 2.4.5 > > Section 3.2 > > Section 3.6 > > Section 3.7.2.3 > > Section 3.7.2.4 > > Section 4.2 (added “MUST”) > > Section 5.2 (added “MUST”) > > Section 5.3 (added “MUST”) > > Section 6.4.1 (added “MUST”) > > Section 6.8 > > Section 10 > > > > Note that the following terms were updated throughout the text: > > DAO-ACK —> P-DAO-ACK > > PDR —> P-DAO-REQ > > PDRSequence —> PDAOReqSequence > > PAREO -> PREOF > > > *Michael, when you have finished making changes to the diagrams, please > attach an updated XML file to this email, and I will update our files > accordingly. > > Best regards, > > Karen Moore > RFC Production Center > > > > On Mar 25, 2026, at 12:02 PM, Michael Richardson <[email protected]> > > wrote: > > > > > > Pascal Thubert <[email protected]> wrote: > >> I’ll trust you on this Michael > > > > I'm not sure where we are. > > I am anticipating that Karen will update the diagrams in the XML, once she > > has returned to a desk. > > > > Shall I sen an updated Figure 19 with extra "o" then? > > > > -- > > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > On Mar 21, 2026, at 6:02 AM, Ines Robles <[email protected]> > > wrote: > > > > Dear all, > > > > Thank you very much to the authors and the RFC Production Center for the > > hard work on this. I agree with the changes, including the latest > > corrections such as those in Figures 18 and 19. The draft updates are > > mostly editorial and improve clarity, consistency, and RFC style without > > changing the technical substance. Overall, the edits look good and helpful, > > and they make the document easier to read and less ambiguous. > > > > Best Regards, > > Ines. > > > > On Sat, Mar 21, 2026 at 11:26 AM Pascal Thubert <[email protected]> > > wrote: > > Hello Michael > > > > The skew seems to be coming from tabs in my editor. > > I reviewed your changes and have no issue with them. > > > > I believe that we need to add a P before or above the DAO the figure 18 > > like below: > > > > 18 would become > > > > ------+--------- > > | Internet > > | > > +-----+ > > | | Border Router > > | | (RPL Root) > > +-----+ | P- ^ | > > | | DAO | P-DAO-ACK | > > o o o o | | | > > o o o o Ingress o o o | ^ | Projected . > > o o o o o \\ o o o | | P-DAO | Route . > > o o o o \\ o o o o | ^ | . > > o o o o o Egress o o v | P-DAO v . > > o o LLN o o o | > > o o o o o Loose Source Route Path | > > o o o o v > > > > > > figure 19 looked OK to me but maybe like below it is clearer? > > > > ------+--------- > > | Internet > > | > > +-----+ > > | | Border Router > > | | (RPL Root) > > +-----+ | P- ^ P-DAO-ACK > > | Track | DAO | > > o o o Ingress V | > > o o o o o o X o X Source- > > o o o o o o o X o o X Routed > > o o o o o o X o X Segment > > o o o o o o o o X X > > Egress > > o o o o o | > > Target > > o o LLN o > > o o o o > > all the best; > > > > Pascal > > Le sam. 21 mars 2026 à 02:50, Michael Richardson <[email protected]> a > > écrit : > > > > Michael Richardson <[email protected]> wrote: > > > I found though: > > > > > Figure 3 seems askew, the ^v route between S and D is hard to read. > > > Figure 4 is better, but might also be better aligned. > > > Figure 7 has skew and some other issues... like this line of ._- under > > > "Southbound API" > > > I checked .html and .txt to be sure it wasn't just the red/green > > markup. > > > Figure 18... not sure if there is a problem. > > > Figure 19, definitely a problem. > > > > Hi, I edited the XML slightly, and put it here: > > https://www.sandelman.ca/tmp/rfc9914-authors-fixed-figures.xml > > > > I think it fixes 3,4,19. > > I fixed some things on figure 7. > > I don't know if I got 18. > > > > -- > > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- > > Pascal > > > > On Mar 18, 2026, at 8:18 PM, Ketan Talaulikar <[email protected]> wrote: > > > > Hi Ines/Aris, > > > > Can you please take a look and share your perspective? > > > > Busy at IETF this week and this is non-trivial (for me at least) and so > > I'll get back by next week. > > > > Thanks, > > Ketan > > > > > > On Wed, Mar 18, 2026 at 12:20 AM Karen Moore <[email protected]> > > wrote: > > Dear Rahul and *Ketan (AD), > > > > Thank you for your reply. We have noted Rahul’s approval on the AUTH48 > > status page (https://www.rfc-editor.org/auth48/rfc9914). Note that > > "coma-separated Targets” was already updated to "comma-separated Targets” > > (Section 3.5, 5th paragraph). This is reflected in the diff file at > > <https://www.rfc-editor.org/authors/rfc9914-diff.html>. If there is a > > different instance we missed, please let us know. > > > > *Ketan, please review the changes in the following sections and let us know > > if you approve. > > > > Section 2.4.5 > > Section 3.2 > > Section 3.6 > > Section 3.7.2.3 > > Section 3.7.2.4 > > Section 4.2 (added “MUST”) > > Section 5.2 (added “MUST”) > > Section 5.3 (added “MUST”) > > Section 6.4.1 (added “MUST”) > > Section 6.8 > > Section 10 > > > > Note that the following terms were updated throughout the text: > > DAO-ACK —> P-DAO-ACK > > PDR —> P-DAO-REQ > > PDRSequence —> PDAOReqSequence > > PAREO -> PREOF > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
