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
