Re: [dns-wg] Volunteer list for RIPE DNS working group chair
dave> If the working group feels strongly about encouraging new faces dave> perhaps we should amend the process such that new co-chairs may dave> servce onlky a single term? Maybe have the outgoing and existing chairs explicitly go out and encourage someone who hasn't served before to volunteer? And have the chairs available to mentor/counsel newbies? Doesn't need to be a rule/bylaw change, just an intention.
Re: [dns-wg] Volunteer list for RIPE DNS working group chair
dknight> I struggle to reconcile our efforts toward impartiality with dknight> the notion of having the chairs encouraging a preferred dknight> candidate. jim> It depends on what's meant by encouragement. I'm fairly sure Paul jim> means approaching someone (or more than one) and saying "Have you jim> ever thought of becoming a WG co-chair?". Yes. Sorry if that wasn't clear. The DNS community has a lot of folks who have been around and known each other for a very long time. That's a good thing but can make it very intimidating for someone "new" to volunteer. Being a bit more active in finding promising folks who haven't had a chance to contribute as much yet seems like a good thing. And I'm sure all the chairs have been and will be very supportive of anyone new. But also saying that to a potential volunteer explicitly also might make someone more comfortable about putting their hat in the ring.
Re: [dns-wg] Lower TTLs for NS and DS records in reverse DNS delegations
gregory> Maybe allow users to set TTL on "domain" object in RIPE gregory> database? Be nice if we could expand to a more sane/standard set of TTLs for NS/DS in TLD/SLDs, which makes this non-functional for a slew of such zones. gregory> Allowed values can be constrained to few common lengths of gregory> time? The default would be one decided here. I made this same comment during the recent DNS-OARC. There is value in a somewhat longer TTL for steady state, to weather temporary glitches in routing (though current values are way too long for even that). When doing provider changes and/or KSK rollovers, a shorter value makes more sense. I think with some testing and actual data, we can come up with a short list of useful values without having to allow unconstrained, random user-picked values that will just create support issues and not really improve the situation. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/dns-wg
