Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

In message <2761653.If01A9zrq2@linux-hs2j>, Paul Vixie writes: > On Monday, March 20, 2017 5:08:01 PM GMT Russ Housley wrote: > > There are other processes for adding names to the root zone. In my opinion, > > using the special-use TLD registry as a means of putting a name, even one > > that has

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

In message <61fd3ee3-3043-4ab1-9823-6a9d61b14...@vigilsec.com>, Russ Housley wr ites: > I have a big problem with Section 6 of draft-ietf-homenet-dot-03. If the > domain name is to be published in the root zone, then I do not think that > the special-use TLD registration is appropriate. That

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Hi, Thanks for Petr and Brian. Brian Hartvigsen 于2017年3月21日周二 上午3:34写道： >> For user privacy concern, we can revise ECS(114.240.0.0/24 >> ) => EIL (CHINA, BEIJING, UNICOM)，give a >> tradeoff between privacy and precise. > > Nice, this sounds like

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Paul Vixie wrote: > > Viktor Dukhovni wrote: >> ... >> >> What's attractive here, is that real resolvers (local to the same >> device) already have the requisite feature-set, and there's no need >> to augment stub resolvers with features already handled by local >> recursive resolvers. If a

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Viktor Dukhovni wrote: > ... > > What's attractive here, is that real resolvers (local to the same > device) already have the requisite feature-set, and there's no need > to augment stub resolvers with features already handled by local > recursive resolvers. If a device is too dumb to run a

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Hi, On Mon, Mar 20, 2017 at 01:14:25PM -0400, Ralph Droms wrote: > Russ - In my opinion, the special-use domain registry is not being > used to put the name in the root zone. The observation is that the > special-use definition of this TLD requires both an entry in the > special-use domain name

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, 20 Mar 2017, Andrew Sullivan wrote: On Mon, Mar 20, 2017 at 06:19:45PM -0400, Paul Wouters wrote: I am assuming that if stubs are validating, then they must also support excluding special queries from validation, such as mDNS, .onion and .homenet. What possible basis do you have for

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 10:15 PM, Viktor Dukhovni wrote: > When I say "local", I don't mean on a nearby node on the local > network, I mean the loopback interface, i.e. a process on the same > device. That would qualify as a stub resolver in the sense that we are talking

Re: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

On 3/20/17 8:15 AM, Warren Kumari wrote: > On Mon, Mar 20, 2017 at 12:55 AM, Paul Vixie wrote: >> on sunday march 12, chinese.apri...@gmail.com wrote as follows: >> >>> I'd be happy to see the document proceed under two conditions: 1) it >>> becomes a WG document, subject to IETF

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, Mar 20, 2017 at 09:06:40PM -0400, Ted Lemon wrote: > On Mar 20, 2017, at 8:48 PM, Viktor Dukhovni wrote: > > FWIW, when adding DANE support to Postfix, > > The homenet use case is completely different. Here we are talking about > devices that routinely roam

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, Mar 20, 2017 at 6:54 PM, Ted Lemon wrote: > On Mar 20, 2017, at 9:50 PM, Brian Dickson > wrote: > > This would require an update every time the KSK is rolled, or whenever the > RRSIG needs to be refreshed. 68 years is an inconvenient

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 9:50 PM, Brian Dickson wrote: > This would require an update every time the KSK is rolled, or whenever the > RRSIG needs to be refreshed. 68 years is an inconvenient interval, so maybe > 50 or 20 years? This is still a lot better than 1 week

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Just to follow through on my thought(s) on this... (thought in-line below). On Mon, Mar 20, 2017 at 6:25 PM, Ted Lemon wrote: > I'm curious what Russ and Steve think about this as an alternative. It > seems a bit byzantine to me, but I can't say that I object to it on >

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 9:37 PM, Steve Crocker wrote: > Before addressing the questions you've asked, let me about the rest of the > picture. How do names get assigned within the local homenet domain? Using either hybrid dnssd, or else stateful dnssd. So,

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Before addressing the questions you've asked, let me about the rest of the picture. How do names get assigned within the local homenet domain? Steve Sent from my iPhone > On Mar 20, 2017, at 9:25 PM, Ted Lemon wrote: > > I'm curious what Russ and Steve think about this as

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

I'm curious what Russ and Steve think about this as an alternative. It seems a bit byzantine to me, but I can't say that I object to it on principal. It does create a lot of extra work for ICANN, though, and it would be a bit more brittle than just doing an unsigned delegation: we now have

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, Mar 20, 2017 at 06:19:45PM -0400, Paul Wouters wrote: > I am assuming that if stubs are validating, then they must also support > excluding special queries from validation, such as mDNS, .onion and > .homenet. > What possible basis do you have for this? This is in effect a requirement

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 8:48 PM, Viktor Dukhovni wrote: > FWIW, when adding DANE support to Postfix, Viktor, forgive me, but this is such a completely different use case than what we are talking about. In this case, the Postfix mailer and the recursive validating resolver

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, Mar 20, 2017 at 05:44:27PM -0400, Steve Crocker wrote: > > You should bear in mind that homenet is assuming the Internet of maybe > > five years from now, more so than the Internet of now, although obviously > > we'd like to get done sooner than that. So you should assume that stub > >

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 6:19 PM, Paul Wouters wrote: > I am assuming that if stubs are validating, then they must also support > excluding special queries from validation, such as mDNS, .onion and > .homenet. I don't think this is a reasonable assumption. We don't, for example,

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 5:44 PM, Steve Crocker wrote: > If you assume the local environment is going to get complicated and that > signing of the local domain will become important in order to guard against > hijacking by errant devices inside the perimeter, it looks to me there

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, 20 Mar 2017, Steve Crocker wrote: If you assume the local environment is going to get complicated and that signing of the local domain will become important in order to guard against hijacking by errant devices inside the perimeter, it looks to me there will have to be a local trust

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

> Hi, > The INT Area Director who oversees the homenet WG, Terry Manderson, has > asked DNSOP participants to review > https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt, "Special Use Top > Level Domain '.homenet’”, with the following aspects in mind: > 1) in terms of RFC6761 > 2) in terms of

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Thanks for the quick response. > On Mar 20, 2017, at 5:14 PM, Ted Lemon wrote: > > On Mar 20, 2017, at 4:57 PM, Steve Crocker wrote: >> First, neither my opinion as an individual nor my opinion as an official of >> ICANN should be considered definitive,

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 4:57 PM, Steve Crocker wrote: > First, neither my opinion as an individual nor my opinion as an official of > ICANN should be considered definitive, normative or otherwise compelling > except and unless the substance of what I say makes sense I was being

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Ted, et al, I’ve been watching this dialog and staying silent, but since I’m referenced and quoted directly, let me offer some points. First, neither my opinion as an individual nor my opinion as an official of ICANN should be considered definitive, normative or otherwise compelling except

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 3:44 PM, Russ Housley wrote: > This document does not describe a collaborative approach. The document specifies what the working group needs to have happen in order for the specification to work. How the collaboration happens is out of scope for the

[DNSOP] Fwd: WG review of draft-ietf-homenet-dot-03

Ted: > There are other processes for adding names to the root zone. In my opinion, > using the special-use TLD registry as a means of putting a name, even one > that has a different scope and use case, is an end run around that process. > > So it seems to me that your position is not that

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

>> For user privacy concern, we can revise ECS(114.240.0.0/24 >> ) => EIL (CHINA, BEIJING, UNICOM)，give a >> tradeoff between privacy and precise. > > Nice, this sounds like appropriate tradeoff to me. > > > Side-effect of this is that it removes need to maintain copies

Re: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

On 3/20/17 7:15 AM, Warren Kumari wrote: > It appears that this may have been a process violation here - RFC5378 > Section 3.3. Right to Produce Derivative Works seems to say that the > IETF needs change control before a WG can formally adopt a document. I > believe that we missed the fact that

Re: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

On Monday, March 20, 2017 6:10:32 PM GMT Paul Wouters wrote: > Anyway, I said "request the authors". It is not a demand. I'm sure you > fully understand my opinion and concern by now. I'll leave it to you to > accomodate that with any or no textual modification. how about "This document describes

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Monday, March 20, 2017 5:08:01 PM GMT Russ Housley wrote: > There are other processes for adding names to the root zone. In my opinion, > using the special-use TLD registry as a means of putting a name, even one > that has a different scope and use case, is an end run around that process. as

Re: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

On Mon, 20 Mar 2017, Paul Vixie wrote: However, such a change of submission should not lead to any more substantive delays in publication. If this is not possible, then I will retract my objection to publishing this as a WG document, and would only request the authors update the initial

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

On Mon, 20 Mar 2017, Tony Finch wrote: Paul Wouters wrote: At section 4, item 3, it could give advise based on source-verified transport, so that ANY queries received over TCP or with DNS-COOKIES could include more data then potentially spoofed UDP packets. But perhaps that

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

Paul Wouters wrote: > > At section 4, item 3, it could give advise based on source-verified > transport, so that ANY queries received over TCP or with DNS-COOKIES > could include more data then potentially spoofed UDP packets. But perhaps > that is not worth it, because ANY

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 1:08 PM, Russ Housley wrote: > There are other processes for adding names to the root zone. In my opinion, > using the special-use TLD registry as a means of putting a name, even one > that has a different scope and use case, is an end run around that

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

> On Mar 20, 2017, at 1:08 PM, Russ Housley wrote: > > >> >>> We have a different view of the intended purpose of the special-use TLD >>> registry. Sadly, the RFC does not include language that resolves this >>> difference. >> >> I understand that we have different

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

> >> We have a different view of the intended purpose of the special-use TLD >> registry. Sadly, the RFC does not include language that resolves this >> difference. > > I understand that we have different views. However, I am asking you > specifically to articulate _your_ view. > > You

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 12:47 PM, Russ Housley wrote: > We have a different view of the intended purpose of the special-use TLD > registry. Sadly, the RFC does not include language that resolves this > difference. I understand that we have different views. However, I am

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

> On 20 Mar 2017, at 04:06, George Michaelson wrote: > > Where's the measurement of existing use? I'll be happy to plough through the 2016 DITL dataset and count TLD strings of interest. What ones would the WG like me to count?

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Ted: >> I have a big problem with Section 6 of draft-ietf-homenet-dot-03. If the >> domain name is to be published in the root zone, then I do not think that >> the special-use TLD registration is appropriate. That said, if the >> requirement for publication in the root zone is removed, I do

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mar 20, 2017, at 11:43 AM, Russ Housley wrote: > I have a big problem with Section 6 of draft-ietf-homenet-dot-03. If the > domain name is to be published in the root zone, then I do not think that the > special-use TLD registration is appropriate. That said, if the

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

On 3/16/2017 3:16 AM, tjw ietf wrote: All We've had a lot of WG discussion on this, and it seems relevant to do a formal call for adoption. If there are outstanding issues raised during the CfA, time in Chicago will be set aside to have those discussions. This starts a Call for Adoption

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

On 3/16/2017 10:24 AM, william manning wrote: this is a useful and needed document. I support its adoption by the WG. As a note to the authors, there was a proposed alternate to what became RFC 5011 which addressed some of the same issues as the current draft. It might be useful to review

Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update

On 3/16/2017 12:38 AM, Doug Barton wrote: I can't help finding this discussion funny, as I proposed prior to the -bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for the simple reason that it was overwhelmingly likely that the root would be signed with the former, making it as

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

I have a big problem with Section 6 of draft-ietf-homenet-dot-03. If the domain name is to be published in the root zone, then I do not think that the special-use TLD registration is appropriate. That said, if the requirement for publication in the root zone is removed, I do not have a

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

On Mon, 20 Mar 2017, Jim Reid wrote: The traditional understanding of ANY == ALL is well ingrained in developers. [Citation needed.] draft-ietf-dnsop-refuse-any is about something completely different. In case you hadn't noticed, the draft's about a server-side issue. Funny, how in this

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

Stephane Bortzmeyer wrote: > > > "ANY Query" refers to a DNS meta-query > > meta-query is not defined in this document, in RFC 1034, 1035 or > 7719. Opinion: just "query". There's precedent for "metatype" - cf. RFC 2136 section 3.4.1.2 - "check the TYPE and if it is ANY, AXFR,

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

Petr Špaček wrote: > > I hope it clarifies that I have no objection to proposed behavior, just > to the way it is described. Thank you for understanding. No problem, your previous message explained your points very clearly. I was just startled that RRSIG queries might ever be

Re: [DNSOP] [dns-privacy] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Hello, On 20.3.2017 08:49, Lanlan Pan wrote: > Hi Barry, > > Thanks for your comments. > > Because the draft discussed the DNS privacy problem of ECS, and was first > presented in In NDSS 2017 DNS Privacy Workshop, so I cc the email to dprive > WG. > > > Barry Raveendran Greene

Re: [DNSOP] adoption mechanics and disclaimers wrt dns-rpz

On 19/03/2017 16:55, Paul Vixie wrote: > please chime in if you're for or against this proposed text It looks fine to me! Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

On 17.3.2017 20:54, Tony Finch wrote: > Petr Špaček wrote: >> >> The casse QTYPE=RRSIG should be made more prominent so it is understood >> and not misused as ANY. There are implementations like Knot Resolver >> which are work around missing RRSIG records in replies using >>

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

> On 17 Mar 2017, at 07:34, Doug Barton wrote: > > The traditional understanding of ANY == ALL is well ingrained in developers. [Citation needed.] For bonus points, provide actual examples of commonly used code that have this misconception and the real operational (but

Re: [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Hi Barry, Thanks for your comments. Because the draft discussed the DNS privacy problem of ECS, and was first presented in In NDSS 2017 DNS Privacy Workshop, so I cc the email to dprive WG. Barry Raveendran Greene 于2017年3月19日周日 上午2:22写道： Hello Yu Fu, I was not at the

Re: [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

On Monday, March 20, 2017 3:40:46 AM GMT Lanlan Pan wrote: > At NDSS there is a question that "why not directly use AS number" ? client > subnet can be maped into AS number, which is used for bgp route at network > topology. > > My answer was that AS4134 cover multiple provinces in china, from