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
