It’s not only that - however unbelievable it might seems, but we also have tests (and variable names) and I do believe the things should be consistent for future generations.
Ondrej -- Ondřej Surý ond...@isc.org > On 23 Mar 2018, at 12:08, George Michaelson <g...@algebras.org> wrote: > > isn't it a #define string? or passed in via environment from configure? > > -G > > On Fri, Mar 23, 2018 at 11:47 AM, Mark Andrews <ma...@isc.org> wrote: >> >>> On 23 Mar 2018, at 10:08 pm, Warren Kumari <war...@kumari.net> wrote: >>> >>> On Fri, Mar 23, 2018 at 10:07 AM, Mark Andrews <ma...@isc.org> wrote: >>>> Geoff you are wrong. Titles should tell you what you are about >>>> to read especially technical documents. There are WAY TOO MANY >>>> RFC TO READ EVERYONE ON THEM. >>> >>> ... you lack ambition :-P >>> >>>> >>>> If I had a TA for andrews.wattle.id.au the current title would >>>> indicate that I could test resolvers to see if there is a TA >>>> installed for it. >>>> >>>> The current draft *is not* generic. It is root TA specific. >>>> That needs to be reflected in the title. >>>> >>>> As for the label it can be used for more than rolling KSKs. >>>> It can be used to see what resolvers are supporting new TA >>>> *when you are not rolling keys*. The current name reflects >>>> *one* use, not all uses. >>> >>> True, it does reflect one use case, not all -- however, we have >>> already changed the name multiple times and implementers are >>> (understandably) becoming annoyed, and supporting N different labels >>> for the tester is also annoying [0]. >> >> As an implementer I say TOUGH! The job of the working group is to >> put out good specifications not to take short cuts just because >> something has been implemented based on a draft. This is the expected >> cost of implementing on a draft. I’ve re-written plenty of code to >> follow draft changes. >> >> I’ve got code to implement this. Some corner cases are currently >> undefined. Changing the label name will cause me to have to re-write >> parts of what I have already written. I know this but I’m still >> calling for the changes. Not only will the specific labels change >> but potentially configuration arguments and with that documentation. >> >>> How about a compromise - we update the draft name, but keep the label >>> the same - the only people who likely care about the label are >>> implementers and testers - once someone sees the name they will read >>> the doc and quickly discover how it can be used. >>> >>> W >>> >>> >>> >>>> >>>> Mark >>>> >>>>> On 23 Mar 2018, at 8:21 pm, Geoff Huston <g...@apnic.net> wrote: >>>>> >>>>> >>>>> >>>>>> On 23 Mar 2018, at 12:55 am, Mark Andrews <ma...@isc.org> wrote: >>>>>> >>>>>> This title of this document DOES NOT match reality. >>>>>> >>>>>> "A Sentinel for Detecting Trusted Keys in DNSSEC” should be >>>>>> replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. >>>>>> >>>>>> kskroll-sentinel-<what>-<id> really needs something other >>>>>> than “kskroll” as the first field. “root-key-sentinal-<what>-<id>” >>>>>> really more clearly matches what it does. >>>>>> >>>>>> Any other changes that follow from these two changes” >>>>>> >>>>> >>>>> I personally think this is getting into bike shedding at this point. >>>>> >>>>> The title of the document is an adequate description of the content >>>>> and folk who want to know more should read the document, not guess >>>>> from the title! >>>>> >>>>> The label is a piece of syntactic convenience and is entirely >>>>> arbitrary. We could start an almost infinite discussion thread >>>>> over which label is better, but in the end its just a label. >>>>> >>>>> >>>>> regards, >>>>> >>>>> Geoff >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> >>> >>> -- >>> I don't think the execution is relevant when it was obviously a bad >>> idea in the first place. >>> This is like putting rabid weasels in your pants, and later expressing >>> regret at having chosen those particular rabid weasels and that pair >>> of pants. >>> ---maf >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> >> _______________________________________________ >> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
