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]
