Dear Paul: Please let me know if the changes in GitHub pthubert/6lo-prefix-registration@dde1a90 <https://github.com/pthubert/6lo-prefix-registration/commit/dde1a903729546131610c7e18a838b2a3460e4e3> alleviate your concerns, and my reply to Roman on what the changes are.
many thanks! Pascal Le mer. 4 juin 2025 à 20:05, Paul Wouters <[email protected]> a écrit : > On Jun 4, 2025, at 04:06, Pascal Thubert <[email protected]> wrote: > > I share the concerns of Ketan and Mohamed regarding the normative use of an >> individual internet draft that has no IETF consensus. It would be better >> if >> > > This is not the case. The ref is informational and the needed text is > repeated locally, exactly to avoid the above, as follows: > > > But a person just going through linked "Updated by" RFCs wouldn't know > about how this one document treats the Update: flag differently from what > is normal at the IETF. > > i believe in general, the idea of Updated by means "there is text here > that is updated in this other doc that you MUST read". It specifically > excludes extensions which are a form of update but is an optional read and > needed only if you want to implement the extension. > > So even with -12 I see Updates: 6550, 6553, 9010 where as the Abstract > states that 6550, 6553 and 9010 are "extended". > (note also that anyway reading the abstract doesn't know about your > inlined later definition of "extends"). > > If someone implementing this RFC needs to modify behaviour specified > in 6550, 6553, 9010, then the Updates: is correct, > but the word "extends" should be "updates". If someone implementing this > RFC does not need to modify code in those three > RFCs (eg it is just a new registration in one of those RFCs defined > registries), then it should not Update: them, but you can use > the word "extends". > > The Update: tag also lists more RFCs than mentioned in the Abstract, so it >> seems something is still missing? >> > > Hum... I fail to understand that one as well. All 8 RFCs tagged as > "updated" are listed in the abstract. > > Yes this was my bad. > > >> I am not a topic expert on this, so I hope the next two questions make >> sense. >> But: >> >> In Figure 4, why is the F bit taken from the next 4 bytes, while there is >> still >> room in the Reserved space before that? >> >> > See my proposal to Ketan in this thread. > > > yes thanks for the answer and fix. > > > >> In Figure 5, what was taken up by the space of the F bit before this? It >> seems >> unlikely there was only a single unused bit there? >> >> The byte was reserved in EARO used in NS messages and used for a status > in the response in NA messages. > Now we use is in NA messages for one flag + 7-bits prefix length . > > > thanks for the clarification ! > > Paul > -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
