On 30/05/2017 08:24, Alexey Melnikov wrote: > Hi Brian, > > On 29 May 2017, at 02:57, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > >>> 3.5.4.3. Discovery Procedures >>> >>> In 6th para: >>> >>> The cache mechanism MUST include a lifetime for each entry. The >>> lifetime is derived from a time-to-live (ttl) parameter in each >>> Discovery Response message. Cached entries MUST be ignored or >>> deleted after their lifetime expires. In some environments, >>> unplanned address renumbering might occur. In such cases, the >>> lifetime SHOULD be short compared to the typical address lifetime and >>> a mechanism to flush the discovery cache MUST be implemented. >>> >>> How can the discovery cache be flushed? >> >> I think that's completely implementation-dependent, so what can we say? >> (In the prototype, it's an API call.) > > I think you just demonstrated my point that some requirements are not very > clear whom they apply to. Passive voice is causing ambiguity here. > > I think I would like to see more text on what different possible alternatives > are and which entities need to implement the MUST.
In this case, I'm more inclined to simply delete the reference to flushing, because it's really part of a much more general problem: https://tools.ietf.org/html/rfc7010#section-7 . The previous comment about the cache lifetime is sufficient. [In fact, renumbering would be an interesting use case for autonomics, but that's a whole topic in itself.] Brian Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
