Hi Alan, Everything sounds good to me. Please share the diff or post the update or github PR link (whatever works best for you) once ready.
About the usage of "we" part, I just wanted to clarify that this was a minor comment and editorial in nature. Please leave as-is if my reasoning does not appeal to you :-) Thanks, Ketan On Tue, Jun 17, 2025 at 9:40 AM Alan DeKok <[email protected]> wrote: > On Jun 16, 2025, at 3:35 PM, Ketan Talaulikar <[email protected]> > wrote: > > KT> I understand. However, the "update" is often associated with the > RFC/draft metadata "update" tag. Since this document is experimental, it > cannot "update" the RFC5880. In any case, I think this is something best > left to the optimizing auth draft and there may not even be a need to cover > this aspect in this document? > > OK. I'll take a look. > > > > <minor> Please find all usage of "we" in this document and replace it > with > > > something more suitable for an RFC. E.g. use "this document". > > > > I think this is a stylistic choice. Personally, I find it difficult > to read neutral / non-personal text. > > > > KT> The comment wasn't about the style. When it comes to Technical > Specifications published by a standard's body like the IETF where the word > "we" is ambiguous - is that the authors, or the WG (since the document is > product of the WG), or of the entire IETF since it is coming through IETF > consensus? It is perfectly OK for a paper submission where "we" represents > the authors of that paper. > > There are many RFCs using "we", so I'm not sure why it's an issue for > this particular draft. There aren't a lot of uses of "we" in this draft, > so I'll take a look. > > > KT> In general, please see if you can reference the text and sections in > the optimizing auth draft about these switches back/forth and not try to > repeat or explain it in this document except for the ISAAC specific aspects > of those switches. > > OK. I'll take a look at that. > > > > > 541 Counter field is incremented, starting from zero (0). This > process > > > 542 may finish with a partial copy of the above structure, in which > case > > > 543 only a prefix of the structure is copied. > > > > > > <major> What is a "prefix of the structure"? Do you mean how much ever > part of > > > the structure that can be accomodated in what remains of that page? > > > > Yes, > > > > KT> OK. Can you please clarify that in the text? The word "prefix" here > is confusing and best left out. > > I've updated the text. > > > > <major> If My Discriminator is changed, then does that not result in > the > > > change of "Your Discriminator" for the other end? RFC5880 says the > > > implications of discriminator change are outside scope. Perhaps the > same can be > > > said here or better still make it a prerequisite that there is no > > > discriminator change while the session is in UP state (somewhat > similar to > > > what is indicated for the Seed a couple of paragraphs below)? > > > > The discriminators are controlled by the sending party. So if My > Descriminator changes, that has no impact on the Your Discriminator field. > There is no requirement in RFC5880 that the discriminators change at the > same time. > > > > KT> I meant looking at it holistically i.e. from the perspective of both > ends. When it is changed by one end, it does have an impact on the other > side. I was not referring to discriminators changing from both sides > together, but the impact of the change and when it is allowed given that it > is part of the "context" for the ISAAC at the other end. > > I've clarified the text. The discriminator is only used for the initial > seeding of ISAAC. After that, it can change without affecting the ISAAC > calculations. > > ISAAC is re-seeded only when the BFD state transitions into the Up > state. Since changing discriminators doesn't change BFD state, then ISAAC > isn't reseeded. > > That is the discriminator is not part of the ISAAC "context", it's part > of the seed. Once ISAAC is seeded, the "context" is the internal ISAAC > variables, which are mutated regularly. > > > The optimized authentication mode draft clarifies this issue (or > should). The BFD Authentication Type is not changing during this switch. > Instead, the Optimized Authentication Mode is changing. And then only > changing for a small number of packets. > > > > KT> I would really appreciate it if you could please review the > latest/updated version of that spec and suggest changes/updates in github. > I am sure the authors of that document would appreciate it. This would help > avoid overlap or repetition and ensure the text in the two documents > integrate well together without any gaps in the specifications. > > We'll take a look at better coordinating the specs. > > Alan DeKok. > >
