Re: [DNSOP] [Last-Call] [Ext] Last Call: (DNS Security Extensions (DNSSEC)) to Best Current Practice

--On Friday, September 23, 2022 19:25 + Amanda Baber wrote: > Hi, > > IANA uses the term "registry group" to refer to top-level > registries and "registry" to describe a set of registrations > (as opposed to a set of sets). There are logistical reasons > for this, but the use of the term

Re: [DNSOP] [Ext] Last Call: (DNS Terminology) to Best Current Practice

s the definitive definition and the term always applies to this case" but not nearly as good as the sort of enumeration you suggest. best, john --On Thursday, August 16, 2018 08:11 +0200 Patrik Fältström wrote: > On 15 Aug 2018, at 22:01, John C Klensin wrote: > >> In that regard,

Re: [DNSOP] [Ext] Re: Last Call: (DNS Terminology) to Best Current Practice

Paul, Thanks for the thorough response. A few additional comments below; I consider all of these to fall into the "things that should be considered as the document is evaluated" category, not anything resembling showstoppers. --On Monday, August 13, 2018 23:56 + Paul Hoffman wrote: >...

Re: [DNSOP] Last Call: (DNS Terminology) to Best Current Practice

IESG and others, Unfortunately and due to some other priorities, I have not been able to do a comprehensive review of this document. The following is based on reading through and trying to get an understanding of this rather long document and its many definitions, some of which are, as the docume

Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari wrote: > On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker > wrote: >> On 3/29/2018 1:45 PM, Warren Kumari wrote: >>> >>> I don't want to get into if this is the*right* behavior or >>> not, but it seems like worth mentioning in the draft as

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

hostnames into a long, drawn-0ut, debate.It is not, IMO, a really serious error in the context of this document, at least unless a explanatory statement made here is cited later as an authoritative definition. If no one else in the WG cares about it, so be it. john --On Monday, March 26,

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

--On Monday, March 26, 2018 17:18 +0200 Martin Hoffmann wrote: > John C Klensin wrote: >> >> From that point of view, namespaces are actually >> per-RRTYPE and the right way to design this document would be >> as a registry of "_"-introduced keywords,

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

--On Monday, March 26, 2018 09:44 +0100 "John R. Levine" wrote: >... >>> i have reproduced your entire second suggestion here, >>> because i think it's solid. rrset atomicity means you're >>> right, and that underbar'ed labels need only be unique >>> within an RRTYPE, and any registry of such

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

--On Monday, March 26, 2018 01:20 -0700 Paul Vixie wrote: > > > John C Klensin wrote: >> >> --On Monday, March 26, 2018 00:07 -0700 Paul Vixie >> wrote: >> >>>> ... My impression has been that, while there is nothing we >>>> c

Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

--On Monday, March 26, 2018 00:07 -0700 Paul Vixie wrote: > > > John C Klensin wrote: >> ... >> >> Two additional, possibly more important, thoughts after >> reading -05 more closely... >> >> (1) The introductory material in the I-D seems to imp

[DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

Taking another look at this now that the IETF dust has settled. First, when I wrote my earlier note on the 21st, I had just glanced through the spec, not studied it, and was under the impression that either the SRV entries and registry would not be affected or that all entries in the SRV registry

Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

--On Wednesday, March 21, 2018 06:05 -0700 Dave Crocker wrote: > On 3/21/2018 4:05 AM, John R. Levine wrote: >  Harmonization for the sake of harmonization is bad, and very little Internet System technology gets it. Just do new stuff better. >> >>> I agree completely. So please

Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

--On Friday, July 7, 2017 10:42 +1000 Mark Andrews wrote: >> The same subsection of RFC 3986 also uses the term "host >> subcomponent" for what you are referring to as a name and >> allows it to be a "registered name" (or ) that >> might not be a DNS name or reference at all -- whether it is >>

Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

--On Thursday, July 6, 2017 09:11 +1000 Mark Andrews wrote: >... > And the actual presentation limit for LDH with DNS is 253 > (encodes as 255 octets on the wire). Remember URI names do > not have a final period and the each label has length octet > when encoded as a DNS name and the name is t

Re: [DNSOP] new DNS classes

--On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker wrote: > There are changes to the DNS that are practical and those that > are not. For better or worse, I can't see any way that > teaching DNS to use new classes makes any sense at this point. > The only point at which it would have

Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

--On Wednesday, July 05, 2017 8:01 AM -0400 Suzanne Woolf wrote: > (not sure which hat. Probably doc shepherd.) >... >> This is a very good question. We weren't asked to answer >> that question, so we didn't. It is assumed throughout the >> document that various proponents of special use doma

Re: [DNSOP] new DNS classes

--On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid wrote: >> On 4 Jul 2017, at 18:49, Paul Vixie wrote: >> >> while IETF governs the protocol, ICANN only governs the IN >> class. i expect that there will be other classes some day, in >> order to avoid some aspect of ICANN. > > Attempts have

Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]

--On Wednesday, June 7, 2017 12:48 +0100 Tony Finch wrote: > Stephane Bortzmeyer wrote: >> >> > The DNS model of master and slave servers, with the latter >> > initiating updates based on TTL values, >> >> The slaves don't use the TTL values, don't they? > > That section is a bit weird. >

Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]

Stephane, Thanks for reading the draft and for your comments. I will study them and see what I can do and will get back to you if I have questions. One general observation: I've tried, when mentioning possible alternate approaches, to provide a partial existence proof that alternatives are possi

Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard

--On Monday, July 20, 2015 13:50 -0400 Bob Harold wrote: > This thread has taught me more about the .onion names - thanks > for that. But I would have to agree with those that think this > bit of explanation is unnecessary to the RFC and should be > excluded, rather than attempting to clarify i

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

(Warning to DNSOP and IESG -- this response is going to descend quickly into SMTP esoterica and is probably safe to ignore from a DNS perspective) --On Friday, July 18, 2014 22:39 +0100 Tony Finch wrote: > John C Klensin wrote: > >> > MX target names should obey the LDH

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

--On Friday, July 18, 2014 20:39 +0100 Tony Finch wrote: > John C Klensin wrote: >> >> If a particular SMTP implementation is aware of and follows >> the spec, almost any consensus indicator that doesn't >> conflict with other things should be fine -- > &g

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

--On Friday, July 18, 2014 14:59 -0400 John R Levine wrote: >> Today's problem, IMO, is that, while there is little debate >> about "DNS-based solution", or even "DNS-based solution >> involving something special in the relevant MX record", I >> haven't seen a careful analysis by DNS experts on

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

(copying John Levine given his recent summary on the IETF list as well as his co-author role) --On Friday, July 18, 2014 10:36 -0400 Olafur Gudmundsson wrote: >> If this is a worry for the root server operators (but I >> thought they had said in the past that it doesn't pose a >> problem) then t

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

--On Friday, July 18, 2014 06:46 -0700 Paul Vixie wrote: >... >> There are no addresses associated with the root, so the mail >> server will immediately report a delivery error. RFC 5321 >> section 5.1 paragraph 2 final sentence. >> >> The SMTP server will not try to connect to the root name >>

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

--On Friday, July 18, 2014 23:18 +1000 Mark Andrews wrote: >> At least in the near term, some SMTP Server ("MTA") >> implementations will conform to that rule (many already use >> it) and some won't. For the latter, they will presumably do >> what the SMTP specs say to do. In summary, that i

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

Hi. I have a few questions that I don't want to clutter the IETF list about but about which I would hope DNS experts, especially DNS root operations experts, would step in if they have opinions. IESG copied only for the record. I want to stress that these are questions: I may know enough to ask

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

--On Thursday, July 03, 2014 12:03 -0700 The IESG wrote: > The IESG has received a request from the Applications Area > Working Group WG (appsawg) to consider the following document: > - 'A NULL MX Resource Record for Domains that Accept No Mail' >as Proposed Standard > > The IESG plans to

Re: [DNSOP] Re: getaddrinfo() and searching

--On Friday, 28 September, 2007 09:48 +1000 Mark Andrews <[EMAIL PROTECTED]> wrote: >... >> It's not. Even without IPv6, having search domains means you >> can get unexpected results. If that's not acceptable, don't >> complain, but put a period behind your FQDNs. > > Please state wer

[DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

--On Thursday, 27 September, 2007 18:45 -0700 Paul Hoffman <[EMAIL PROTECTED]> wrote: > The Security Considerations section for this document is much > too narrow. It ignores one of the main reasons that many > organizations purposely choose to provide recursive lookup to > the public, namely for