On June 1, 2022 at 4:45:15 AM, Luigi Iannone wrote: > > On 1 Jun 2022, at 05:29, Donald Eastlake wrote: > > > > ... > > > > > SECURITY > > > > > This draft appears to completely ignore the issue of Map Version > > > > > Number advancing so far so quickly that an old version number is > > > > > encountered that appears to be newer than or equal to the current > > > > > version number. Why can't this happen? Or if it can, why doesn't that > > > > > hurt? > > > > > > > This is more of an operational point. If you update a mapping, the best > > > would be to give sufficient time so that everybody updates and there is > > > no such a risk. > > > What about adding in section 7 “dealing with Map-Version Numbers” the > > > following sentence. > > > > > > It is an operational question to make sure that Map-Version numbers are > > > not updated so frequently as to create the risk that very old version > > > numbers appear newer (because of the circular space). > > > > > > Would that address your issue? > > > > Not really. (1) I think the document needs to say what happens if the > > numbers wrap around and overlap. (2) Assuming the answer to 1 is as bad as > > I think, then it is not "an operational question" to avoid this but rather > > "an operational requirement". That is, there should be a statement > > something like "Map Version Number incrementing and TTL MUST be managed so > > that an old Version Numbers will not be confused as a new Version Number. > > > > This last sentence is great. I will put it in section 7. Nice sentence, but what does it mean? What action should the implementation take to satisfy "MUST be managed"? From Luigi's initial response (above), it sounds like the time between changes (TTL ?) has to be long enough... Please spell some of this out. Thanks! Alvaro. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
