Re: [DNSOP] rfc8499bis: lame
I would posit that the potential to view the word as offensive has increased as language usage has changed in the intervening years since it was first used in this context. As one who is a) a native English speaker and b) grew up in an environment which had an equestrian community element, ‘lame’ to me, implied a transient condition, which has seemed somewhat appropriate to use in our context. However, the change in language has resulted in a change of the primary meaning to many people, and it may now be found offensive by some. As such, I believe it’s time to look at changing. Bob > On Jun 8, 2023, at 19:48, Wes Hardaker wrote: > > Paul Wouters writes: > >> That was one of my suggestions, don't define it or declare it obsolete. >> It will ofcourse take time for people to stop using it. > > There were a number of us in favor of this option, I think. But the > consensus was certainly not there to stop using the term. Maybe the > tide is shifting, as it seems like more are in favor of defining new > terms now than the previous discussion round. > -- > Wes Hardaker > USC/ISI > > ___ > 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
Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)
I’m all for addressing our past mistakes if we have consensus. > On Dec 1, 2021, at 19:56, Paul Hoffman wrote: > > On Dec 1, 2021, at 4:02 PM, Warren Kumari wrote: >> I think that enough time has now passed that we might be strong enough to >> address this whole topic again and start fixing the identified issues as >> well as tackling the larger "what is a namespace, and how do multiple >> resolution systems co-exist?!" topic. >> >> Who's with me? > > If we have the support of the Area Director to work on and finish this work, > I'm definitely up for it, particularly if it doesn't bork the current queue > of work in DNSOP. > > --Paul Hoffman___ > 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
Re: [DNSOP] Deprecating infrastructure .INT domains
Kim, I concur with Joe on this. It would be good practice to tidy up these appendages. I too would be happy to contribute text as appropriate. Bob > On Nov 11, 2021, at 11:56, Joe Abley wrote: > > Hi Kim, > > I like the idea of cleaning this up. > > Choosing nsap.int as an example, I think it would be useful to either update > RFC 1706 to make it clear that the advice in section 6 of that document no > longer applies, and that no reverse mapping for NSAP is provided in the DNS. > I don't think this is a great operational necessity since I imagine the > number of people who expect this to work is approximately zero but it seems > good to be tidy. > > [I'd suggest reclassifying 1706 to historic but that'd also affect the > specification for the NSAP RRType; maybe that's a good idea too, but it seems > outside the scope of what you are trying to achieve, and I don't know how we > would confirm that it's a good idea.] > > Similar comment for other domains where there's similar existing advice. > > Happy to offer actual text if that seems useful. > > > Joe > >> On 11 Nov 2021, at 11:38, Kim Davies wrote: >> >> Colleagues, >> >> I wanted to draw your attention to an Internet Draft we’ve developed, >> its goal is to formally deprecate a number of historic “.int” >> domains that were designated for Internet infrastructure purposes >> decades ago and appear for all intents and purposes obsolete. After some >> limited consultation on developing the approach so far, it would be >> useful to get some additional eyes on it so we have greater confidence >> there is nothing we’ve missed. >> >> Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/ >> >> It’s a short document, but at its heart we’ve identified the >> following domains that are referenced in places but seem to be obsolete: >> >>atma.int, ip4.int, nsap.int, rdi.int, reg.int, tpc.int >> >> Most of these are not delegated in the int zone any longer, but there >> are lingering references to them. >> >> Thanks in advance for any insight, and apologies if you get this message >> in duplicate, >> >> kim >> >> ___ >> 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
Re: [DNSOP] what's in .alt, was Last Call: (The .onion Special-Use Domain Name) to Proposed Standard
On Jul 18, 2015, at 22:50, John R Levine wrote: > > For the most part, I expect that people will look in the registry (or > registries) to see what's already in use and pick names that don't collide, > since life is easier that way. But if they do collide, I'd rather know the > bad news up front rather than depending on folklore to know which of the > names in the registry work and which ones collide with things you have to > find out about somewhere else. > > In case it's not obvious, FCFS does require some minimal level of info so > people can find out more, but the harder we make it to register, the more > likely people are to distribute software and not tell us about it. By this logic, using a FCFS 'registry' model implies at least enough information (if not a requirement) for some of tracking the registrant to confirm continued use, transfer, release or abandonment at the very least, no? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Requesting adoption of draft-wkumari-dnsop-root-loopback
+1 > On Nov 13, 2014, at 23:32, David Conrad wrote: > >> On Nov 13, 2014, at 11:20 AM, Warren Kumari wrote: >> >> Dear DNSOP Chairs, >> >> We are requesting a call for adoption of draft-wkumari-dnsop-root-loopback. > > Support. > > Regards, > -drc > > ___ > 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
