Re: [DNSOP] Andrew Alston's Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)
Hi Andrew, If you want to claim that because of the recommendations in it, this document should be standards track instead of BCP, there might be some merit to such a position, although personally I think it is fine as a BCP and I don't think the code point allocation has anything to do with this question. I did a quick survey of some DNS related BCPs that request IANA registries or code points and list them below. (The intent of the current IANA system is that, to the extent possible, the entirety of the conditions for IANA assignment be encoded into (or pointed to from) the registry. The assignment criterion for an "Extended DNS Error Code", the code point allocated by this draft, is First Come, First Served (FCFS). Unless I am missing something, it makes no difference to assigning such a code point what kind of document this is. It embodies a request, so IANA should grant a code point, whether IANA receives the request via email or via the progressing of a draft. That's all there is to the assignment. >From the point of view of code point allocation, it would be fine if this draft was targeted at Informational, or an April 1st draft, or some random non-IETF document. The authors should have just asked IANA for the code point and put the value into the draft. I recommend such a course of action to future authors, when applicable.) Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com (Note that, by the time they are published as an RFC, IANA requests are usually re-worded to reflect that the request is now an accomplished fact. So, for example, a request to create a registry is changed, by the time the RFC is published, to say "IANA has established a registry..." or the like. This is less true for older RFCs.) Some DNS BCP RFCs that create or modify IANA Registries: RFC 8552, BCP 222 RFC 6895 (and predecessors), BCP 42 RFC 6382, BCP 169 RFC 6303, BCP 163 RFC 3172, BCP 52 Some DNS BCP RFCs that assign entries in IANA Registries: RFC 7793, BCP 163 RFC 4159, BCP 109 RFC 3681, BCP 80 RFC 3152, BCP 49 RFC 2606, BCP 32 On Thu, May 12, 2022 at 5:52 AM Andrew Alston via Datatracker < nore...@ietf.org> wrote: > Andrew Alston has entered the following ballot position for > draft-ietf-dnsop-nsec3-guidance-08: Discuss > > ... > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/ > > -- > DISCUSS: > -- > > I've been sitting trying to work out in my mind if a BCP document should be > requesting code points - and if I should change the position from a no > objection to a discuss - and the more I think about this - I feel that a > discuss here is probably the right option. > > I'd like to discuss if both the sections of the document that utilize > normative > language and require additional code points aren't better suited to a > standards > track document. > > > -- > COMMENT: > -- > > Thanks for the work put into this document. > > Having read through the document, I would also like to support Paul's > discuss > since the document does seem to update RFC5155. I also would like to > second > what Murray said about it seeming a little strange to see a BCP document > updating a standards track document. > > Finally - I was a little surprised to see IANA actions in a document > entitled > "guidance for" - not sure if anyone else agrees with me, but it seems > strange to see a BCP document requesting IANA actions > > > > ___ > 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
[DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2022-05-24
The Domain Name System Operations (dnsop) WG will hold a virtual interim meeting on 2022-05-24 from 19:00 to 20:00 Europe/Amsterdam (17:00 to 18:00 UTC). Agenda: Agenda * Chairs, Administrivia (10 min) * Ulrich Wisser and Shumon Huque, DNSSEC Automation (25 min) https://datatracker.ietf.org/doc/draft-wisser-dnssec-automation/ * Peter Thomassen and Nils Wisiol, Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator (25 min) https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=45d75893-b015-4b13-b835-204c9de2b003 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-validator-requirements-01.txt
Hi, Please find an updated version of our document. The intention of the document is to provide guidance for an operator to operate a DNSSEC resolver. Any feedback, comment is of course welcome. Yours, Daniel On Fri, May 13, 2022 at 12:41 PM wrote: > > 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 WG of the > IETF. > > Title : Recommendations for DNSSEC Resolvers Operators > Authors : Daniel Migault > Dan York > Filename: > draft-ietf-dnsop-dnssec-validator-requirements-01.txt > Pages : 23 > Date: 2022-05-13 > > Abstract: >The DNS Security Extensions (DNSSEC) define a process for validating >received data and assert them authentic and complete as opposed to >forged. > >This document clarifies the scope and responsibilities of DNSSEC >Resolver Operators (DRO) as well as operational recommendations that >DNSSEC validators operators SHOULD put in place in order to implement >sufficient trust that makes DNSSEC validation output accurate. The >recommendations described in this document include, provisioning >mechanisms as well as monitoring and management mechanisms. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/ > > There is also an htmlized version available at: > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-validator-requirements-01 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-validator-requirements-01 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-dnssec-validator-requirements-01.txt
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 WG of the IETF. Title : Recommendations for DNSSEC Resolvers Operators Authors : Daniel Migault Dan York Filename: draft-ietf-dnsop-dnssec-validator-requirements-01.txt Pages : 23 Date: 2022-05-13 Abstract: The DNS Security Extensions (DNSSEC) define a process for validating received data and assert them authentic and complete as opposed to forged. This document clarifies the scope and responsibilities of DNSSEC Resolver Operators (DRO) as well as operational recommendations that DNSSEC validators operators SHOULD put in place in order to implement sufficient trust that makes DNSSEC validation output accurate. The recommendations described in this document include, provisioning mechanisms as well as monitoring and management mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-validator-requirements/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-validator-requirements-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-validator-requirements-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Doodle poll for DNSOP WG interim on 24 or 25 May
All, The Doodle poll is closed and we have selected: Tuesday May 24, 17:00-18:00 UTC The details and agenda of the interim meeting will be shared in a separate email. -- Benno On 10/05/2022 00:08, Benno Overeinder wrote: Hi all, The following newly adopted DNSOP WG drafts are on the agenda for the interim meeting: - dnssec-automation, Ulrich Wisser and Shumon Huque - dnssec-bootstrapping, Peter Thomassen and Nils Wisiol We want to close the Doodle poll at the end of Wednesday, 11 May. Best regards, Suzanne, Tim and Benno On 29/04/2022 23:04, Benno Overeinder wrote: Dear DNSOP WG, We are planning our first DNSOP WG interim meeting for 2022 on May 24 or 25. The DNSOP WG chairs are contacting the authors of two drafts that can be put on the agenda. Details to follow. Please fill in the Doodle poll to settle on a day and time: - https://doodle.com/meeting/participate/id/e0RyVkXb The options for the time slots are CEST/EDT/PDT friendly. We will close the Doodle poll at the end of Thursday, 5 May. Best regards, Suzanne, Tim and Benno ___ 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] Lars Eggert's No Objection on draft-ietf-dnsop-nsec3-guidance-08: (with COMMENT)
Hi, On 2022-5-12, at 20:11, Wes Hardaker wrote: > Anyway, you're quoting how the tools produced the reference results with > their titles. I can't fix RFC4470. understood - that's why I have the blurb about false positives in there. Thanks, Lars signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
