Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On 30 Apr 2015, at 16:40, George Michaelson wrote: > economy and economycode is a useful concept sometimes. it avoids the CN/TW > issue. and encompasses HK. > > state or territory can be useful. covers some of the intermediate things. > eg much of the CIS is a 'transitional state' according to th

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On 30 Apr 2015, at 18:34, Kim Davies wrote: > If an allusion to the purpose is useful, then: > > "A TLD that is allocated for use based on an entry in the ISO 3166-1 > standard [ISO 3166-1]. The ISO 3166 standard provides codings of > countries and their subdivisions." A TLD that is allocated for

Re: [DNSOP] Interim Meeting on Special Names and RFC 6761

On 30 Apr 2015, at 19:10, Alain Durand wrote: > On 4/30/15, 11:23 AM, "Warren Kumari" wrote: > > >> The RIPE staff has been very nice and made a room available at RIPE-70 >> : >> >> Meerman I/II for ~30 people on Tuesday 12 May 18:00- 20:00 Amsterdam >> >> Jaap >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On Thu, 30 Apr 2015 15:35:31 +0100, Andrew Sullivan wrote: > > On Wed, Apr 29, 2015 at 07:28:21PM +, Edward Lewis wrote: > > > Vice versa, once the parent removes > > the NS set, the delegation is removed regardless of what the child > > "thinks." > > Well, effectively maybe not. If a resol

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On Thu, 30 Apr 2015 15:35:31 +0100, Andrew Sullivan wrote: > > On Wed, Apr 29, 2015 at 07:28:21PM +, Edward Lewis wrote: > > > Vice versa, once the parent removes > > the NS set, the delegation is removed regardless of what the child > > "thinks." > > Well, effectively maybe not. If a resol

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On 1 May 2015, at 08:31, Patrik Fältström wrote: > Also note that there are ccTLDs allocated for codes that are not registered > in ISO3166 (UK, EU etc). IIUC these two are on the 3166 list as exceptionally reserved codes. > Suggested new text: > > ccTLD -- A TLD that is allocated to distinct

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On 1 May 2015, at 12:00, Jim Reid wrote: > On 1 May 2015, at 08:31, Patrik Fältström wrote: > >> Also note that there are ccTLDs allocated for codes that are not registered >> in ISO3166 (UK, EU etc). > > IIUC these two are on the 3166 list as exceptionally reserved codes. Yes, but not REGISTER

Re: [DNSOP] Terminology: forwarding and forwarder

Paul Hoffman wrote: > >Forwarder -- Section 1 of [RFC2308] describes a forwarder as "a >nameserver used to resolve queries instead of directly using the >authoritative nameserver chain". [RFC2308] further says "The >forwarder typically either has better access to the internet, or

Re: [DNSOP] Terminology: primary, secondary, master, slave

Paul Hoffman wrote: > Greetings again. Based on Casey's proposal, I would like to make the > following changes. Thoughts? I'm not entirely sure, because it loses the RFC 2136 concept of "primary master" which is the root of the zone transfer / update forwarding graph, and I think demoting "prima

Re: [DNSOP] Terminology: policy-implementing resolver

Paul Hoffman wrote: > > Good question, and no. "Policy-based" and "policy-implementing" are > those kind of terms we hear bandied about in operator circles but not > written about in RFCs because it is supposedly outside the purview of > the IETF. If someone has a reasonable reference we can point

Re: [DNSOP] draft-ietf-dnsop-edns-client-subnet-00 Birthday Attack

Hello, I was just pointed at this message. On 22 April 2015 at 12:49, Yuri Schaeffer wrote: >> Replies coming from servers not supporting edns-client-subnet or >> otherwise not containing an edns-client-subnet option SHOULD be >> considered as containing a SCOPE NETMASK of 0 (e.g., cache the >>

Re: [DNSOP] Yet another thought on draft-ietf-dnsop-dns-terminology

Edward Lewis wrote: > I'd been forgetting to mention this outside my head. > > I suggest a section describing names give to messages. Yes, I have had the same thought, and I think this could help with the iteration / recursion / server role question. I have some text in the works. Tony. -- f.a

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

Eric Brunner-Williams wrote: > i'd like to think of it as a sequence of bits having having no infix dots and > having no semantics, e.g., directionality, arising externally to itself. Dots are allowed in labels but have to be escaped in the presentation format. RFC 1035 section 5.1: \X

Re: [DNSOP] Terminology: country

They are country-code TLDs because they use the country codes from ISO 3166. "Country codes" is the title of part 1 of ISO 3166. http://www.iso.org/iso/country_codes.htm There are also the IDN ccTLDs which do not use country codes but which are allocated based on the ISO 3166 eligibility criteria.

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

Warren Kumari wrote: > > NXDOMAIN -- A colloquial expression for RCODE 3, also commonly written > as 'NXDomain' or 'Non-Existent Domain' NXDOMAIN etc. are not colloquialisms, they come from the 4.3BSD resolver API. (Spelling them in lower case is weird if not wrong.) Tony. -- f.anthony.n.finch

Re: [DNSOP] Terminology: country

On Thu, Apr 30, 2015 at 2:18 PM, Bill Woodcock wrote: > ... > >> If we changed this to say, "A TLD that is allocated using the UN > >> country list using the the two-letter code from the ISO 3166-1 alpha-2 > >> standard [ISO3166]," would that address your concern? > > > > I would be fine with tha

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

Tony Finch wrote: > Warren Kumari wrote: >> NXDOMAIN -- A colloquial expression for RCODE 3, also commonly written >> as 'NXDomain' or 'Non-Existent Domain' > > NXDOMAIN etc. are not colloquialisms, they come from the 4.3BSD resolver > API. (Spelling them in lower case is weird if not wrong.) a

[DNSOP] Delegation - Re: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On 4/30/15, 10:35, "Andrew Sullivan" wrote: >> Vice versa, once the parent removes >> the NS set, the delegation is removed regardless of what the child >> "thinks." > >Well, effectively maybe not. If a resolver "sticks" on the child, >then the delegation won't move regardless. The context he

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

On 5/1/15, 8:20, "Tony Finch" wrote: >Eric Brunner-Williams wrote: > >> i'd like to think of it as a sequence of bits having having no infix >>dots and >> having no semantics, e.g., directionality, arising externally to itself. > >Dots are allowed in labels but have to be escaped in the presenta

Re: [DNSOP] Terminology: forwarding and forwarder

On Fri, May 1, 2015 at 6:39 AM, Tony Finch wrote: > Paul Hoffman wrote: > > > >Forwarder -- Section 1 of [RFC2308] describes a forwarder as "a > >nameserver used to resolve queries instead of directly using the > >authoritative nameserver chain". [RFC2308] further says "The > >f

Re: [DNSOP] Terminology: forwarding and forwarder

Shumon Huque wrote: > > In light of the self contradictory text in RFC 2308, I don't think it is self-contradictory; it just has a slightly weird definition. (Maybe this draft should note that where RFC 2308 says "forwarder" it actually means "recursive server used by a forwarder". The "forwarder

Re: [DNSOP] Terminology: primary, secondary, master, slave

On Fri, May 1, 2015 at 6:52 AM, Tony Finch wrote: > Paul Hoffman wrote: > > > Greetings again. Based on Casey's proposal, I would like to make the > > following changes. Thoughts? > > I'm not entirely sure, because it loses the RFC 2136 concept of "primary > master" which is the root of the zone

Re: [DNSOP] Terminology: country

Tony Finch writes: > They are country-code TLDs because they use the country codes from ISO > 3166. "Country codes" is the title of part 1 of ISO 3166. > http://www.iso.org/iso/country_codes.htm > > There are also the IDN ccTLDs which do not use country codes but which > are allocated base

Re: [DNSOP] draft-livingood-dnsop-negative-trust-anch...@tools.ietf.org

At Fri, 24 Apr 2015 23:59:22 -0400, Warren Kumari wrote: > So, I have gone back through previous mail and it seems that this was > the only email that got missed. > Anyway, it seems that other folk also made similar comments, and so, > by -03, we had addressed almost all of them. > Apologies aga

Re: [DNSOP] Terminology: primary, secondary, master, slave

Are y'all looking at the -01 draft? Because it defines "primary server" and "primary master", both using quotes from RFCs. Are those quotes not correct? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

On Wed, Apr 29, 2015 at 03:39:15PM -0700, Paul Hoffman wrote a message of 12 lines which said: > What do others think? I regret that draft-ietf-dnsop-dns-terminology-01 keeps using a wrong definition for "RRset", which is contradictory with the definitions proposed in this thread for "label":

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On Fri, May 01, 2015 at 09:31:11AM +0200, Patrik Fältström wrote a message of 189 lines which said: > Suggested new text: > > ccTLD -- A TLD that is allocated to distinct economies. > Historically, these were two-letter TLDs, and were allocated to > economies using the two letter code for the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

> Le 2015-05-01 à 14:47, Stephane Bortzmeyer a écrit : > > On Fri, May 01, 2015 at 09:31:11AM +0200, > Patrik Fältström wrote > a message of 189 lines which said: > >> Suggested new text: >> >> ccTLD -- A TLD that is allocated to distinct economies. >> Historically, these were two-letter TLD

Re: [DNSOP] Terminology: forwarding and forwarder

On Fri, May 01, 2015 at 05:42:28PM +0100, Tony Finch wrote a message of 25 lines which said: > Maybe this draft should note that where RFC 2308 says "forwarder" it > actually means "recursive server used by a forwarder". No, it means "forwarder" and it has always been used that way (for insta

Re: [DNSOP] Draft on censorship, and DNS

On Fri, Nov 07, 2014 at 08:39:31AM -0800, Stephane Bortzmeyer wrote a message of 14 lines which said: > There is an Internet-Draft "A Survey of Worldwide Censorship > Techniques" draft-hall-censorship-tech-00 which is on the agenda of > the Security Area Open Meeting next week at IETF 91 Honol

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

On May 1, 2015, at 11:56 AM, Marc Blanchet wrote: >>> From the point of view of the DNS, there is no difference between a >> ccTLD and a gTLD. This distinction is relevant only for policies. > > right. I completly agree and I was going to write almost the same thing. > > suggest to remove ccTLD/

Re: [DNSOP] draft-ietf-dnsop-dns-terminology needs to define "label"?

On May 1, 2015, at 11:50 AM, Stephane Bortzmeyer wrote: > > I regret that draft-ietf-dnsop-dns-terminology-01 keeps using a wrong > definition for "RRset", which is contradictory with the definitions > proposed in this thread for "label": > > A set of resource records with the same label, class

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-terminology-01.txt

> Le 2015-05-01 à 15:27, Paul Hoffman a écrit : > > On May 1, 2015, at 11:56 AM, Marc Blanchet wrote: From the point of view of the DNS, there is no difference between a >>> ccTLD and a gTLD. This distinction is relevant only for policies. >> >> right. I completly agree and I was going to

[DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01

Greetings, The current DNS Cookies document (draft-ietf-dnsop-cookies-01) has two similar but distinct protocols described in it: the DNS Cookie option as designed by Donald Eastlake, and the Simple DNS Cookie option designed by Mark Andrews and experimentally implemented (under the name Server Id

Re: [DNSOP] Seeking discussion of draft-ietf-dnsop-cookies-01

> On May 1, 2015, at 4:21 PM, Evan Hunt wrote: > > Speaking for myself, I agree with Mark: the benefits of including error > codes in the option are slim and other mechanisms such as FORMERR work > just as well in almost every scenario, so it doesn't justify the cost in > additional complexity.