Re: [DNSOP] New terminology for root name service

2017-03-15 Thread william manning
do you have a pointer to the rssac document? /Wm On Wed, Mar 15, 2017 at 10:31 AM, Paul Hoffman wrote: > Greetings again. RSSAC has published a lexicon of terms that are commonly > used with respect to the root of the public DNS, but are not in RFC 7719. I > have opened

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

2017-03-15 Thread Doug Barton
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 close to mandatory to implement as possible

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

2017-03-15 Thread Yu Fu
Hi all, We have submitted a new draft as draft-pan-dnsop-edns-isp-location-00. This document is an improved solution for ECS(RFC7871), describes an EDNS ISP Location (EIL) extension to address the privacy problem of ECS, find the right balance between privacy improvement and user experience

[DNSOP] RFC6891 Section 7. Transport Considerations

2017-03-15 Thread Mark Andrews
These two paragraphs don't match reality. Lots of servers, incorrectly, just set the rcode to FORMERR, set QR to 1 and return the request message. If we want to distingish FORMERR from EDNS aware servers we need to provide a signal that works. The signaling described here doesn't.

[DNSOP] BCP 209, RFC 8109 on Initializing a DNS Resolver with Priming Queries

2017-03-15 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. BCP 209 RFC 8109 Title: Initializing a DNS Resolver with Priming Queries Author: P. Koch, M. Larson, P. Hoffman Status: Best

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Ted Lemon
On Mar 15, 2017, at 3:40 PM, Russ Housley wrote: > If you think that “on this topic” in the sentient refers only to the previous > sentence, then I am okay with that approach. However, I do not think that is > okay if “topic” refers to more than that. Yes, that's the

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Russ Housley
Ted: > On Mar 15, 2017, at 3:25 PM, Ted Lemon wrote: > > On Mar 15, 2017, at 3:22 PM, Russ Housley > wrote: >> I see that draft-ietf-dnsop-sutld-ps-03 still references >> I-D.lewis-domain-names, but I have not seen ant WG

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Ted Lemon
On Mar 15, 2017, at 3:22 PM, Russ Housley wrote: > I see that draft-ietf-dnsop-sutld-ps-03 still references > I-D.lewis-domain-names, but I have not seen ant WG Last Call for that > document. What is the plan? It's an informative reference. We're going to try to get Ed

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-03-15 Thread Russ Housley
> Will I-D.lewis-domain-names be published as an Informational RFC as well? If > not, then the Introduction needs to extract highlights from that document. I see that draft-ietf-dnsop-sutld-ps-03 still references I-D.lewis-domain-names, but I have not seen ant WG Last Call for that document.

[DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

2017-03-15 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : Reverse DNS in IPv6 for Internet Service Providers Author : Lee Howard Filename:

[DNSOP] New terminology for root name service

2017-03-15 Thread Paul Hoffman
Greetings again. RSSAC has published a lexicon of terms that are commonly used with respect to the root of the public DNS, but are not in RFC 7719. I have opened an issue for the terminology-bis document at https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/17 and would be

Re: [DNSOP] New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

2017-03-15 Thread Roy Arends
> On 15 Mar 2017, at 16:39, John Dickinson wrote: > > I like this simple short draft. I prefer its terminology. The only tiny > issue I have is with the wording "Must Not Implement". Since there is > no capability exchange you can not avoid talking with a peer that > happens

Re: [DNSOP] Fwd: New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

2017-03-15 Thread John Dickinson
On Tue, 2017-03-14 at 09:04 +0100, Jakob Schlyter wrote: > This draft should be of interest to this WG, providing an alternative > to  > draft-wouters-sury-dnsop-algorithm-update. > > jakob I like this simple short draft. I prefer its terminology. The only tiny issue I have is with the

Re: [DNSOP] Fwd: New Version Notification for draft-arends-dnsop-dnssec-algorithm-update-00.txt

2017-03-15 Thread Petr Špaček
Thank you for the draft. I have to say that from my perspective the draft-wouters-sury-dnsop-algorithm-update selected a better approach to the problem. IMHO it is important to distinguish consumers and producers of signatures as discussed in the original thread. While I agree that

Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

2017-03-15 Thread Paul Wouters
On Wed, 15 Mar 2017, Roy Arends wrote: I apologise for the tone. This went south quick and was due to my confrontational style of writing. The secspider-stats are indeed a good indicator, and convinced me that we shouldn’t make SHA1 related DNSKEY algorithms a "MUST NOT”. Thanks for

Re: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-03.txt

2017-03-15 Thread Petr Špaček
On 14.3.2017 12:28, Ralph Droms wrote: > draft-ietf-dnsop-sutld-ps-03 includes revised text to address issues raised > during the WG last call and other editorial improvements. The list of > issues, discussion and resolution are in GitHub: > https://github.com/Abhayakara/draft-tldr-sutld-ps >

Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

2017-03-15 Thread Roy Arends
Dear Paul (and wg) I apologise for the tone. This went south quick and was due to my confrontational style of writing. The secspider-stats are indeed a good indicator, and convinced me that we shouldn’t make SHA1 related DNSKEY algorithms a "MUST NOT”. In the spirit of being constructive, we