> On Jul 22, 2019, at 8:37 PM, Normen Kowalewski <[email protected]> wrote: > > While I agree that “add” today covers discussion around the case described in > here, but the reason that it covers it is because “add” acts as a "catch all > bucket" for “various DNS things not well defined”. > If we want to cover the case of an application acts as/embed a stub resolver, > we may want to define a term (and draft) that covers exactly that, instead of > using the much wider term. > > I wonder if something meant by "add" today, might have to drop from being > meant by “add” tomorrow after that feature becomes a well defined RFC? > Terminology would for me have to be less prone to change its meaning over > time. > > Thus I propose to remove “add” from the draft.
I agree with the suggestion to remove “ADD” from the draft. “ADD” seems different than the other ones and, in my mind, not *yet* in common-enough usage where its definition would be warranted. I also agree with Norman that the longevity of using “ADD” isn’t clear. I’m fine with the draft being adopted with the other terms. (We can then discuss more details about those specific terms.) My 2 cents, Dan _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
