Re: [DNSOP] [Ext] Call for Adoption: draft-arends-dns-error-reporting
Hi all, Considering the support for adoption at the IETF 110 DNSOP meeting and support on the mailing list (one email, but no objections), draft-arends-dns-error-reporting is being adopted as a DNSOP WG document. This email closes the call for adoption. Thanks, -- Benno On 07/04/2021 03:59, Paul Hoffman wrote: On Apr 6, 2021, at 2:07 PM, Benno Overeinder wrote: With the IETF 110 DNSOP meeting, the draft DNS Error Reporting (draft-arends-dns-error-reporting) is presented by Roy Arends. In the session, the (virtual) room was asked for adoption of the document or raise objections. On the mic there was general support for adoption. Now we will start a period of two weeks for the call for adoption of draft-arends-dns-error-reporting on the mailing list. The draft is available here: https://datatracker.ietf.org/doc/draft-arends-dns-error-reporting/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 20 April 2021 I support the adoption of this document. Beyond the main use cases in the document (reporting DNSSEC problems), it is very likely we can use it in current DPRIVE work to report encrypted DNS problems. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New version of draft-ietf-dnsop-rfc7816bis after WG last call
We're looking for comments before Monday April 26th. I'm sorry. Better slightly late than never, I suppose. The whole text seems good to me, except for a small issue: In step (6) of the algorithm it might better be noted that in case xNAME is in ANSWER, the RCODE is irrelevant. Now the reading doesn't seem right e.g. if it returns a CNAME to an NXDOMAIN. * we use 1-1-1-3-3-.. label steps, which is not exactly what section 2.3 describes I consider that part of the draft as just an example how the number of queries could be reduced, so I can't see any problem. In the stub&forwarding section it might be worth noting the case of validating stub or forwarder. There the final query does not suffice regardless of (non-)minimization, so the QNAME minimization approach can be "coupled" with a root-to-leaf direction of discovering the trust chain. We've been using one simple approach from this class for years (as the only option for forwarding with validation). --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] dnsop - New Meeting Session Request for IETF 111
A new meeting session request has just been submitted by Tim Wicinski, a Chair of the dnsop working group. - Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: Chair Conflict: add maprg dprive dnssd homenet dhc Technology Overlap: regext intarea trans acme dmarc lamps People who must be present: Suzanne Woolf Warren "Ace" Kumari Tim Wicinski Benno Overeinder Resources Requested: Special Requests: Longer session first if possible - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
