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.
