Re: [DNSOP] [Ext] QNAME minimization is bad

Paul, On Nov 10, 2023, at 11:06 PM, Paul Hoffman wrote: >> On Nov 10, 2023, at 11:55 AM, John Levine wrote: >>> DNSBLs have been around a lot longer than QNAME minimization. >> Not sure that’s relevant — I presume you’re not suggesting DNSBLs are a >> predominant use of the DNS. > DNSBLs are

Re: [DNSOP] QNAME minimization is bad

John, On Nov 10, 2023, at 11:55 AM, John Levine wrote: > DNSBLs have been around a lot longer than QNAME minimization. Not sure that’s relevant — I presume you’re not suggesting DNSBLs are a predominant use of the DNS. > They > work(ed) fine without minimization and I don't think it is

Re: [DNSOP] New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

On Oct 9, 2023, at 5:34 PM, Paul Wouters wrote: > On Oct 9, 2023, at 10:02, Ben Schwartz > wrote: >> >>  >> This is fun to think about, but it seems to me that these networks should >> avoid any reliance on the ICANN DNS tree. I doubt that any network

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

Joe, On Sep 19, 2023, at 2:45 PM, Joe Abley wrote: >>> Domain names existed before the DNS >> Well, hostnames did. Not sure domain names did, at least using that term. > All hostnames are domain names, right? Well yes, in the sense that domain names were a scalability extension of hostnames.

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

Joe, On Sep 19, 2023, at 8:32 AM, Joe Abley wrote: >> I think we need to clearly separate the definition of a domain name with >> the 'domain name space'. A domain name is just a sequence of labels, >> and is a concept that exists independent of the tree structured namespace >> of the global DNS

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

Mark, On Jul 17, 2023, at 4:23 PM, Mark Andrews wrote: >> Joe is (correctly, IMHO) pointing out that given there is a need to support >> TCP-based DNS queries (see RFC 7766), prudent engineering would suggest you >> need to prepare for attacks against that infrastructure. As such arguing >>

Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt

Paul, On Jul 17, 2023, at 12:52 PM, Paul Vixie wrote: >> If the stability of anybody's infrastructure depends on people choosing a >> particular transport, I would suggest they might have reason to be worried. >> Simply hoping that people don't start using TCP in a significant way is >>

Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps

Rob, 4 weeks for ICANN (which? Organization, Board, Community, all 3?) to provide feedback? (That feels sort of like the ITU asking "the IETF" for feedback on an IP-related protocol document in 4 weeks.) As I’m sure both Harald and Warren can attest, ICANN processes, particularly those for

Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

Hi, On Dec 14, 2022, at 9:33 AM, Jim Reid wrote: > If these principles apply, why is the IETF bothering with .alt at all? My impression has been the primary intent is to ensure .ALT is not allocated for DNS use and secondarily, to try to curtail future discussions of this topic. FWIW, if my

[DNSOP] "Moving .INT" (was Re: [Ext] root crud, Possible alt-tld last call?)

George, This is unrelated to alt-tld, but just as a point of clarification: On Oct 25, 2022, at 5:17 PM, George Michaelson wrote: > Just because we're punting ALT into their process, and moving .INT into their > process […] I presume you’re talking about

Re: [DNSOP] [Ext] Possible alt-tld last call?

Wes, Mumble. I said I wasn’t going to argue the politics further, but… On Oct 24, 2022, at 10:49 AM, Wes Hardaker wrote: > David Conrad writes: >>whether the IETF “reserving” a TLD is intruding on ICANN’s territory. > So, the > decision made at the time was: once the W

Re: [DNSOP] [Ext] Possible alt-tld last call?

Libor, On Oct 24, 2022, at 9:11 AM, libor.peltan wrote: >> The root of the DNS is a commons, supported by volunteers who are paying out >> of their own pocket to provision a global infrastructure. I’m personally not >> comfortable recommending techniques that can add undefined (could be >>

Re: [DNSOP] [Ext] Possible alt-tld last call?

Rob, On Oct 24, 2022, at 2:13 AM, Rob Wilton (rwilton) wrote: >> whether the IETF “reserving” a TLD is intruding on ICANN’s territory. > After WG LC, I propose that the WG chairs, ADs, IAB, and ICANN liaison > discuss this. My current expectation is that we probably will send ICANN a >

Re: [DNSOP] [Ext] Possible alt-tld last call?

Paul, On Oct 23, 2022, at 1:27 PM, Paul Hoffman wrote: >> 1) Ask the stupid question. > Again? It has already been answered many times in the negative. There are > even RFCs about it. Asking it again is a waste of people's time. I’m unaware. Could you point me to the ICANN Board resolution,

Re: [DNSOP] [Ext] Possible alt-tld last call?

Rob, On Oct 22, 2022, at 10:33 AM, Rob Wilton (rwilton) wrote: > As I read it, the partitioning of the domain name namespace is really to > achieve two aims: On this mailing list, I think there is a pretty good understanding of the intent of .alt and I don’t think there is much in the way of

Re: [DNSOP] [Ext] no regitry for you, Possible alt-tld last call?

Suzanne, On Oct 23, 2022, at 3:50 AM, Suzanne Woolf wrote: > We've been told repeatedly that no one wants to engage legal analysis or > liaison communications on a document that doesn't have WG consensus. This appears broken. In this specific case, the way forward appears to be predicated on

Re: [DNSOP] [Ext] Possible alt-tld last call?

Rob, On Oct 22, 2022, at 5:11 AM, Rob Wilton (rwilton) wrote: > If this was a MUST NOT, then at the point that the RFC is published, would > that not mean that all DNS stub (and maybe recursive) resolvers immediately > become non complaint with the new standard? The draft says

Re: [DNSOP] [Ext] Possible alt-tld last call?

Paul, On Oct 21, 2022, at 3:34 PM, Paul Hoffman wrote: >> If the intent here is that .alt names should never be looked up via the DNS, >> then MUST NOT is the expected behavior, no? > There is no such intent of the draft. Ah. Then I guess I don’t support the draft and the rest of my input is

Re: [DNSOP] [Ext] Possible alt-tld last call?

On Oct 21, 2022, at 3:48 PM, Tim Wicinski wrote: > Not putting any hat on, I do like Ben's https+alt:// URI suggestion. > As a chair, if we see enough interest in this, the WG should find consensus All the world is not a URI, e.g., % ping https://www.ietf.org ping: cannot resolve

Re: [DNSOP] [Ext] Possible alt-tld last call?

Paul, On Oct 21, 2022, at 1:46 PM, Paul Hoffman wrote: >> The document says domain names in .alt “should not” be looked up in a DNS >> context. The whole point of .alt is that it isn’t to be used in the DNS >> context. Why is this not RFC 2119 “MUST NOT”? > Because we cannot force

Re: [DNSOP] [Ext] Possible alt-tld last call?

Paul, > On Oct 21, 2022, at 10:34 AM, Paul Hoffman wrote: > Warren and I believe that the changes in draft-ietf-dnsop-alt-tld-18 meet all > of the concerns in the message that started this thread, and thus it is ready > for WG Last Call. I disagree that the document is ready for WG Last Call.

Re: [DNSOP] Speculations Re: [EXTERNAL] Possible alt-tld last call?

Suzanne, On Oct 18, 2022, at 6:50 AM, Suzanne Woolf wrote: > We don't know what ICANN considers an attempt to "wade into ICANN territory," > and there's nothing the WG can do to resolve this question. I’m unsure the protocols here, but the WG could request the IAB to have the IETF Liaison to

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

Hi, On Aug 23, 2022, at 4:18 AM, Schanzenbach, Martin wrote: >> IMHO, if you want to be in a carve-out of the domain name space, you still >> need to play by the domain name space's technical rules, in a way that's >> backwards compatible with systems that don't know about the carve-out and

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

On Aug 15, 2022, at 7:07 PM, Stephen Farrell wrote:On 16/08/2022 03:01, John Levine wrote: >> Right. If it's FCFS, I am sure I am not the only person who will be >> waiting at the gate with thousands of preemptive registrations. > Why? Because they believe (or are convinced) there is or will be

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On Aug 15, 2022, at 1:22 PM, Paul Wouters wrote: > I guess we could prevent draft--alt-name-cocacola if we consult the Trademark > Clearing House, https://tmsearch.uspto.gov/bin/showfield?f=doc=4806:y9m1tz.2.21 :) > but maybe

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On Aug 15, 2022, at 10:14 AM, Ray Bellis wrote: > STD 13 then effectively makes udp/53 and tcp/53 the de-facto wire protocols > for interrogating that system, mostly surplanting the use of host files. > > On that basis, I'm unable to separate the RFC 921 / 952 "Domain Name System" > namespace

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Eliot, On Aug 15, 2022, at 7:41 AM, Eliot Lear wrote: > What I like about .alt (or whatever we end up calling it) is that it requires > a single or small number of changes, not one change per name space. It creates a new namespace (*.alt), presumably one that is less contentious than the

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Stephen, On Aug 15, 2022, at 6:46 AM, Stephen Farrell wrote: > On 15/08/2022 06:09, Christian Huitema wrote: >> .onion is barely visible, with 0.01% of root traffic. > So that should be significant for the disposition of the GNU stuff, shouldn't > it? No. > My impression is that there'd be

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

On Aug 14, 2022, at 3:54 PM, Stephen Farrell wrote: > On 14/08/2022 23:37, David Conrad wrote: >> It seems to me that “the correct handling” of how an operating system or an >> application distinguishes what protocol to use for domain name lookup (other >> than DNS) is out

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Stephen, On Aug 14, 2022, at 1:42 PM, Stephen Farrell wrote: > On 14/08/2022 19:32, David Conrad wrote: >>> But, there are also what ought be almost purely technical parts, >> Sorry to be dense, but what exactly are those technical parts, >> specifically those th

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Stephen, On Aug 13, 2022, at 7:14 PM, Stephen Farrell wrote: > But, there are also what ought be almost purely technical parts, Sorry to be dense, but what exactly are those technical parts, specifically those that are relevant to DNSOP and/or the IETF? Thanks, -drc signature.asc

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Paul, On Aug 13, 2022, at 7:26 PM, Paul Vixie wrote: >> The problem is that every resolver implementation and deployment on the >> Internet, which assumes anything that looks like a domain name IS intended >> for the DNS, has to be modified to “do something different” when it sees >> that

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

Paul, On Aug 13, 2022, at 3:32 PM, Paul Vixie wrote: > i suggest that we adopt the technology "domain names (which is a concept that > precedes DNS itself)" whenever we are trying to talk about the name space as > distinct from the protocol. Sorry, which technology are you suggesting we

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

Martin, On Aug 4, 2022, at 12:01 PM, Schanzenbach, Martin wrote: > But the resolution protocol is technology-neutral. I invite you to re-read > the draft. We are not proposing a namespace. Right. If I understand correctly, you are proposing to use the existing domain name namespace, and

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-alt-tld

Hi, On Aug 2, 2022, at 8:00 AM, Geoff Huston wrote: >> I came to this group because of concerns that Warren raised, and because the >> draft sits before me. I have reviewed what discussion I could find in the >> logs relating to Warren's draft, which amounts to either (a) this is ICANN's >>

Re: [DNSOP] [Ext] Re: signing parent-side NS (was: Re: Updating RFC 7344 for cross-NS consistency)

Hi, On Jul 29, 2022, at 12:53 AM, Petr Špaček wrote: > By any chance, do you remember in what iteration the DO=1 in query was > introduced? Mid- to late 2000/early 2001, after the 2nd iteration (using Ed’s terminology), but before the third. > I wonder what sort of disruption was

Re: [DNSOP] DNSSEC as a Best Current Practice

On Mar 21, 2022, at 1:01 AM, Masataka Ohta wrote: > Paul Wouters wrote: > >>>  Constructive thing to do to make DNS secure is to totally >>> abandon DNSSEC and rely on DNS cookie or something like that. > >> DNS cookies provide no data origin security, only a weak transport >> security

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

Hi, On Apr 28, 2021, at 5:38 AM, Jim Reid wrote: >> On 28 Apr 2021, at 13:24, Roy Arends wrote: >> The working group can (after a potential clarification from the ISO about >> the future status of code elements) decide if a subset suffices and if so, >> the composition of the subset. > > I

Re: [DNSOP] [Ext] on private use TLDS

On Nov 28, 2019, at 2:29 PM, Doug Barton wrote: > On 11/28/19 2:15 PM, Paul Hoffman wrote: >> On Nov 28, 2019, at 1:30 PM, Doug Barton wrote: >>> The IETF and ICANN share a sandbox on many topics, including the root zone. >>> (But of course you already knew that.) And if you don't think ICANN

Re: [DNSOP] on private use TLDS

[Sorry for the slow response — US holidays and a resolution not to look at my computer over said holidays got in the way] Doug, On Nov 27, 2019, at 8:39 PM, Doug Barton wrote: > I agree with Matt, Bill Woodcock, Steve Crocker, and others that have > expressed that we should stay out of ISO's

Re: [DNSOP] on private use TLDS

On Nov 26, 2019, at 12:52 PM, Ted Lemon wrote: > It might be worth clarifying what the actual scope of this proposal is. I > think that the idea is to say “look, if you want to use a private name, these > names are known to be safe.” It’s not to say “the IETF hereby declares that > the

Re: [DNSOP] On .ZZ

This whole discussion confuses me. As Roy and Jaap have pointed out, ISO 3166 has indicated the user defined codes won’t be allocated. They are for private use. Just as RFC 1918 has designated 10/8 for private use. To me, this means any of the user defined ISO codes are fair game for internal

Re: [DNSOP] [Add] new draft: draft-grover-add-policy-detection-00

On Jul 14, 2019, at 7:09 PM, Rob Sayre wrote: > Was DNS intentionally designed to be insecure? What’s your definition of “secure”? DNS had clear design elements for availability. DNSSEC added integrity. Confidentiality wasn’t a design goal. Regards, -drc signature.asc Description: Message

Re: [DNSOP] Proposal: Whois over DNS

Philip, On Jul 10, 2019, at 6:24 AM, Philip Homburg wrote: > With that in mind, it seems that this proposal doesn't address any technical > issues with whois. Maybe rate limiting by most (all?) whois servers? Regards, -drc signature.asc Description: Message signed with OpenPGP

Re: [DNSOP] Obsoleting DLV

I strongly support moving it to Historic. Regards, -drc > On Jul 2, 2019, at 11:12 AM, Matthijs Mekking wrote: > > Hi, > > > A while back I was asked why BIND 9 still had code to do DLV. Good > question, and we asked our users if they would mind if we remove the > code. Almost everyone was

Re: [DNSOP] [dbound] Related Domains By DNS (RDBD) Draft

Alexander, On Feb 27, 2019, at 4:32 PM, Brotman, Alexander wrote: > I'm supportive of doing this in other ways, but also understand that DNSSEC > is not widely deployed. There is a difference between not being deployed and not being turned on. My impression is that most DNS servers these

Re: [DNSOP] the root is not special, everybody please stop obsessing over it

Paul, On Feb 14, 2019, at 1:57 PM, Paul Vixie wrote: > 7706 is wrong headed on a number of levels, but its worst offense is to think > that the root zone is special. Operationally, the root zone actually is special. It is, after all, the starting point of the name space. As far as I can tell,

Re: [DNSOP] extension of DoH to authoritative servers

On Feb 12, 2019, at 10:03 PM, zuop...@cnnic.cn wrote: > that's ture. but in my view, if the trust chain is built, we can ensure a > resolver(or a cache) is always talking to a identified server and the channel > is always secure, then the content could not be tampered. Your model of how the DNS

Re: [DNSOP] extension of DoH to authoritative servers

On Feb 12, 2019, at 3:03 PM, Paul Vixie wrote: > David Conrad wrote on 2019-02-12 14:58: >>> lack of an IETF-approved standard with planned implementation by a half >>> dozen tech giants, >> And that worked so well with NAT. > network operators had a choice whether

Re: [DNSOP] extension of DoH to authoritative servers

On Feb 12, 2019, at 2:18 PM, Paul Vixie wrote: > Ted Lemon wrote on 2019-02-12 14:08: >> On Feb 12, 2019, at 1:48 PM, Paul Vixie > > >> wrote: >>> DoH _specifically_ evades this, by looking as much as possible like

Re: [DNSOP] extension of DoH to authoritative servers

Paul, On Feb 12, 2019, at 8:32 AM, Paul Vixie wrote: > DoH is _dangerous_ because it's my network and i require all visitors, family > members, employees, and apps to use the control plane i have constructed, > which includes DNS surveillance and control. Why don’t you force folks on your

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Vittorio, On Aug 21, 2018, at 3:33 AM, Vittorio Bertola wrote: > If so, I can accept your use case: a smart user, knowing what he is doing, > does not want anyone else to sanitize his queries for him. But I don't see > why the best solution to your use case - which is quite a minority case,

Re: [DNSOP] zonemd/xhash versus nothing new

On Jul 30, 2018, at 5:03 PM, Wes Hardaker wrote: >> I think the use for non-root zones is quite a different use case, I don’t. >> so if >> I ignore that, we are looking at specifically the root zone only. > > Please don't ignore that. We really do ourselves a disservice when we > design a

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

On Jun 19, 2018, at 2:03 PM, Ray Bellis wrote: > AIUI, a large part of the supposed issue with SRV was the inertia of the > installed base of browsers that wouldn't know how to access them. I thought the more fundamental problem was the additional latency caused by the second lookup since SRV

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

On Nov 27, 2017, 11:47 AM -0800, Richard Barnes , wrote: > I don't think that it make sense to infer from the failure of RFC 8145 that > resolver/authoritative telemetry isn't possible Huh? RFC 8145 wasn’t a failure — it was stunningly successful. Within a few months of

Re: [DNSOP] Agenda for IETF100

Can confirm, as can anyone willing to go to an Adobe Connect archive. For the curious: https://participate.icann.org/p6u03rimy92/?launcher=false=true=normal The discussion on Ethereum by Leonard Tan, an Ethereum developer, starts at 00:31:00. Paul’s question is at 00:42:16. From the

Re: [DNSOP] new DNS classes

Mark, On Jul 6, 2017, 11:56 PM -0700, Mark Andrews , wrote: > > > Or you could stop trying to reinforce the myth that new RR types > > > are hard to deploy. They really aren't. Please stop trying to minimize the amount of work here. They really are. Not for you, but for the folks

Re: [DNSOP] new DNS classes

Paul, On Jul 4, 2017, 10:59 AM -0700, Paul Vixie , wrote: > > > On 4 Jul 2017, at 18:49, Paul Vixie wrote: > > > while IETF governs the protocol, ICANN only governs the IN class. Sorry, could you point me to anything that documents this?  My impression has

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

Paul, On Apr 6, 2017, 2:24 PM -1000, Paul Vixie , wrote: > the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or > non-experienced or non-protocol-geeks; 7706 doesn't recommend editing someone else's zone file, re-signing it, and figuring out how to

Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

On Apr 6, 2017, 2:32 AM -1000, Paul Vixie , wrote: > if you want to run yeti-style, there are some perl scripts that will > fetch and verify the root zone, edit the apex NS and DNSKEY RRsets, > re-sign with your local key, and give you a zone you can run on several > servers

Re: [DNSOP] .arpa

Hi, On Mar 26, 2017, 5:37 PM -0700, George Michaelson , wrote: > In no sense is the domain solely used or intended for PTR requests, Is anyone claiming this? If so, that'd be really silly given the contents of the .ARPA zone is: as112.arpa. e164.arpa. in-addr-servers.arpa.

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

Andre, On Dec 20, 2016, at 9:49 PM, ac wrote: > I once made a very cool tool, it improved the life of many people as it > allowed anyone to take over any pc running a certain operating system > with the sole and great purpose of helping more users. It too was > published, improved,

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

+1 Regards, -drc (speaking only for myself) > On Dec 20, 2016, at 4:02 PM, John Levine wrote: > >> "Not wanting to be recruited into a botnet" is another such consideration. >> Paul and Vernon invented a useful tool to help address it, and I'm >> in favor of documenting it. >

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Bill, On Dec 17, 2016, at 11:36 AM, william manning wrote: > Is there any public data to support the presumptions of excess capacity at > the roots and the impact of NSEC aggressive use on the DNS? Warren provided some interesting anecdotes at the last IEPG, but I'm

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

I presume NSEC Aggressive Use will significantly reduce the amount of crap hitting the root servers. Given how much capacity the root servers already have to provision to deal with that crap, I don't think a massive increase in legitimate (NSEC Aggressive Use-implementing) resolvers will move

Re: [DNSOP] A mention of draft-fujiwara-dnsop-resolver-update and draft-weaver-dnsext-comprehensive-resolver

Stephane, > On Dec 5, 2016, at 9:24 AM, Stephane Bortzmeyer wrote: > > https://blog.cloudflare.com/tld-glue-sticks-around-too-long/ > > "In this article, I explained what DNS glue is, and why I believe that > DNS TLD glue TTL values hardcoded at 48 hours are not helping with

Re: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

>> Local Host: "Hip and cool city trips. Totally not creepy and weird." > Shane is the sarcasm really helpful here? It rarely is. > localhost is already out of bounds for the gTLD processes at ICANN and you > well know that. > > As per the gTLD Applicant Guidebook, section 2.2.1.2.1 Reserved >

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

Hi, On October 3, 2016 at 5:14:24 PM, John Levine (jo...@taugh.com) wrote: ICANN (or perhaps some people within ICANN) are  asking whether they should delegate .corp, .home, and .mail and  presumably other toxic waste names, and want an authority they can  point to for the answer.  Just a

Re: [DNSOP] Mitigation of name collisions

Warren, On October 3, 2016 at 12:33:12 PM, Warren Kumari (war...@kumari.net) wrote: ... and just for the record, much much more could have been determined  (and users better warned / informed) if the address handed out was a  server which displayed an error / links to more information[0], I'm not

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

Mark, On September 28, 2016 at 5:08:05 PM, Mark Andrews (ma...@isc.org) wrote: > I've been telling people that if they need a fake private TLD for their local  > network they should use one of those since it is exceedingly unlikely  > ever to collide with a real DNS name. Am I right?  No. Just

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

On Apr 24, 2016, at 7:54 AM, Ted Lemon wrote: > Paul. I think actually that we need to start maintaining a list of things > that ought to be explicitly looked for when reviewing documents for > publication, and this sort of thing would be one such. I'll admit some surprise

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

Stephane, On Apr 23, 2016, at 1:07 PM, Stephane Bortzmeyer wrote: > Interesting RFC, which introduces officially the TLD .home, without > using the RFC 6761 framework. So, apparently, you can reserve TLDs > without going through the Special-Use Domain registry. I would agree

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

Stephane, On Apr 7, 2016, at 5:48 PM, Stephane Bortzmeyer wrote: > On Thu, Apr 07, 2016 at 04:15:36PM -0400, > Suzanne Woolf wrote > a message of 32 lines which said: > >> To be clear— I wouldn’t argue that “all identities *are not* subject >> to

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

Suzanne, On Apr 7, 2016, at 2:49 PM, Suzanne Woolf wrote: > It is a matter of scope, to say nothing of opinion, that “all names are > subject to socio-economic pressures.” > [...] > Given that discussion of “special use names” is even more likely than most to > suffer

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

Suzanne, On Apr 7, 2016, at 2:39 PM, Suzanne Woolf wrote: >> On Apr 7, 2016, at 11:17 AM, Stephane Bortzmeyer wrote: >> >> Since we have this liaison, does anyone know if it was used to inform >> ICANN of this discussion (it seems the right thing to

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

Adrien, > I think we still need to answer the question about whether DNS namespace > should be polluted for non-DNS resolution. I believe your question is wrong. The "DNS namespace" can't be polluted for non-DNS resolution because the DNS namespace is, by definition, only comprised of names

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>> Also, it would make very difficult to DNS programmers to keep track of >> all these "special but not special" domain names. > > Personally, I consider naming systems developed outside the IETF a problem. > > There should be no register, because they should not exist. This appears to assume

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

Hi, > Some people > complained that it was difficult enough with RFC 6761 (because there > is no machine-readable version of the special-use registry) Last I looked http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml was XML and it's machine-readable. > but

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Suzanne, On Mar 29, 2016, at 5:23 PM, Suzanne Woolf wrote: > I’ve always seen people assume that an entry in the special use names > registry means that ICANN won’t delegate the same string in the DNS root. I thought putting a name onto the special use names registries

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

George, On Mar 28, 2016, at 6:58 PM, George Michaelson wrote: > Whats the process to understand how, and why a name gets added to the > list? Thats not an IETF question, understandably, but it would be nice > to understand it, even only in outline. As Suzanne mentioned,

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Andrew, On Mar 28, 2016, at 8:36 PM, Andrew Sullivan wrote: > But I think you're smuggling into your argument a claim that > they're potentially subject to the IPR and socio-economic issues that > have been a problem in the DNS root and TLD zones. That's in effect > an

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Andrew, On Mar 28, 2016, at 11:33 AM, Andrew Sullivan wrote: > I am pretty sure that > whatever could get registered under RFC 6761, it would not be an > ordinary name in the DNS. What do you mean by "ordinary"? In what way is ONION not "ordinary"? In what way are GNU,

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Ralph, On Mar 28, 2016, at 6:43 AM, Ralph Droms wrote: > First, I'll emphasize that the process of designating a name as "special use" > is separate from the mechanical process of actually adding a new name to the > Special-Use Names registry. Agreed. > RFC 6761

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Andrew, On Mar 25, 2016, at 7:16 PM, Andrew Sullivan wrote: > I think it is plain that a name that is actually somehow implicated in > the existing root policies (in which I would include names that are > excluded under some ICANN policy) are just not candidates for 6761

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Ralph, On Mar 25, 2016, at 8:33 AM, Ralph Droms wrote: > I'm responding here with none of my various hats on... Me too. > RD>> I think it's more correct to write that RFC 7686 defines ".onion" > as a Special-Use Domain Name, which takes it out of the Domain Name > space.

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

Suzanne, On Mar 18, 2016, at 3:51 PM, Suzanne Woolf wrote: > There's an argument to be made that "People considered carefully and don't > believe any amount of tinkering will make an idea that depends on CLASS > workable, so the option isn't available" will result in

Re: [DNSOP] RFC 7719 on DNS Terminology

+1 Very good work by all involved. Now, just need to have a similar document for the DNS protocol itself :) Regards, -drc > On Dec 15, 2015, at 5:06 PM, Tim Wicinski wrote: > > > I want to give a big thanks to the authors and the working group for the > painstaking

Re: [DNSOP] Some thoughts on special-use names, from an application standpoint

Mark, > What is the actual harm, discounting aesthetics? For one thing, names not supported by the underlying infrastructure will _always_ leak. In the bad old days, when an application got a string ending in .UUCP, .BITNET, .CSNET, etc., it had to know that those strings had to be treated

Re: [DNSOP] Expiration impending:

Hi, > On Oct 8, 2015, at 9:40 AM, Andrew Sullivan wrote: > > On Mon, Oct 05, 2015 at 09:39:06AM -0400, Paul Hoffman wrote: >> Fully agree. That is why this should not be an IETF document, and instead it >> should be written and published by the organization that is

Re: [DNSOP] Expiration impending:

Suzanne, > (Jonne Soininen is the current liaison manager, cc'd). Jonne's email address looks suspiciously like Andrew's :) > This sounds like you'd be OK with publishing the document as an Informational > RFC, Yes. > mod making sure it's accurate as a current description, Most important

Re: [DNSOP] Expiration impending:

Hi, On Oct 2, 2015, at 9:10 AM, Suzanne Woolf wrote: Preempting a WGLC, I support the document. It states its aim of documenting existing practices, and it does so clearly. >>> >>> I agree completely. I am actually confused as to why it is not already >>> an

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

> On Oct 1, 2015, at 10:45 AM, John Levine wrote: > >>> Uh, no. The *only* loopback address is ::1. The rest of ::/8 is >>> reserved. >> >> Anything is a loopback address if you alias it on your loopback interface. >> >> ::2 was only intended as an example (that's why

Re: [DNSOP] Expiration impending:

On Sep 29, 2015, at 2:53 AM, Shane Kerr wrote: >> On Mon, Sep 28, 2015 at 07:59:00AM -0400, Joe Abley wrote: >>> This document describes existing practice, and provides guidance for >>> people who need to bootstrap a validator using the mechanisms provided >>> by ICANN

Re: [DNSOP] Warren's DNSSEC root update draft

Mike, On Jul 21, 2015, at 9:07 AM, Michael StJohns m...@nthpermutation.com wrote: The decision with respect to clients ... would see some benefit... has to be based on what the servers know. Yes, and the information provided by the mechanism described by Warren's draft would provide at

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

David, On Jul 20, 2015, at 5:53 AM, David Cake d...@difference.com.au wrote: Of course, ICANN has already determined that .corp does pose a security issue of sufficient significance that .corp will not be delegated. For clarity, I believe ICANN has placed the delegation of .CORP on hold

Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

Paul, On Jul 19, 2015, at 6:01 AM, Paul Vixie p...@redbarn.org wrote: there are no hoops here. people will register if they want to, and people will check the registry if they want to. For the people who want to register, an exclusive registry explicitly creates a discussion for everyone but

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

Hugo, On Jul 17, 2015, at 4:03 PM, Hugo Maxwell Connery h...@env.dtu.dk wrote: The goal here from the non-DNS people seems to be to have DNS type labels (thus URI's) which are known to the recursive and authoritative resolvers to be outside of DNS. That appears to be the goal of some

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

Stephane, On Jul 17, 2015, at 4:17 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Well, even worse, what happens if name-your-next-OS-vendor decides to create a new dns-like protocol that uses .foo, does that mean that we should automatically block it? No need to speculate about what

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

Paul, On Jul 17, 2015, at 9:51 AM, Paul Vixie p...@redbarn.org wrote: yes, but not with .ALT, which is a politically desirable gTLD name, and which allows the connotation of alternate DNS. i suggested .EXTERNAL because nobody will ever want it as a gTLD and because its connotation is

[DNSOP] namespace control (was Re: Last Call: draft-ietf-dnsop-onion-tld-00.txt ...)

Stephane, On Jul 17, 2015, at 4:23 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote: I agree on the need for less friction, hence my interest in trying to find objective criteria. Lack of objective criteria pretty much guarantees the same sort of discussion and 'heavy process' you're

  1   2   3   >