if we are designing protocol and its operations, then policy might not be the best to codify in protocol specs. i am not persuaded that specifying terminology for every possible edge case is a great use of resources, particularly since there seems to be a significant blurring between defining terminology at the protocol level and terminology for implementation and policy. Is that concern important to the group?
manning bmann...@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 1May2015Friday, at 7:41, Edward Lewis <edward.le...@icann.org> wrote: > > > On 4/30/15, 10:35, "Andrew Sullivan" <a...@anvilwalrusden.com> wrote: > >>> Vice versa, once the parent removes >>> the NS set, the delegation is removed regardless of what the child >>> "thinks." >> >> Well, effectively maybe not. If a resolver "sticks" on the child, >> then the delegation won't move regardless. > > The context here is the definition of the term "delegation". > > In operations, it's expected that a parent could remove a delegation (in > the policy sense) and because of TTL's, the child's presence sticks in the > cache. This is a legitimate outcome of the use of caching. (It can be > abused, of course, but I'm just trying to stick to definitions of terms, > not operational issues.) > > In my personal judgement, the mere fact that there is a transitional state > of a half-baked delegation is not significant. Perhaps there's a need to > "name" this state (I can see trying to explain this to a customer). But > to me that doesn't mean the definition of delegation has to take this into > account. > > In "policy time" the delegation ends when the parent's zone serial is > incremented and the cut point is gone. In "real time" the delegation ends > in the eyes of a resolver when it discovers there is no cut point. Yes, > these are different, but to define "delegation" I would stick to the > perspective of the parent because it is the one legitimately holding the > cards. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
