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
