From nobody Fri May 13 11:18:44 2022 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE402C183530; Fri, 13 May 2022 11:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6ZZ89m9cleS; Fri, 13 May 2022 11:18:37 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA1FC14792E; Fri, 13 May 2022 11:18:36 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id v4so11196716ljd.10; Fri, 13 May 2022 11:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U7O6gNBUQMVKvOhI2O4heAFoVttQFS4e5N2GuMqHV8M=; b=TLpCAebyul5rkJJjvr1M1h+ECB5cSteg7t4sdG/+ZcBlZ3neEZocdCkkbvEgq/XBxg p5eLieO8gonuqJrhbL598Q1AKkAm9wvRZufCoMpY3VgZYid3GE8j9vT2HqxMV7FVQ0fR 2tNdEketnw3aoNqkzr+dqmL/w1mPtbhd1qcf/jXxF2mLHhb1XU6Q5o798ZJwrt2d1LDK DeTWZBglpTjTX0FtLjIF6XFvOzZ8M9q8CGC7K4RvFGQzwo84+chdh2alPmFPoFcpu74e Uge35NwZXXuhdSb7uFGt8q7zZUqTarbQLYnRp4PFpIQufeU00ZLO7lndmm4dJoyy+MCk 9tuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U7O6gNBUQMVKvOhI2O4heAFoVttQFS4e5N2GuMqHV8M=; b=n/tU3IYbpMbaw6ofhSxFCygGtIDXlq6hAThCTfKmHBzFWKrBbDsAOaSLXkaoPhVvRh u2kVMhm6CZAG+lIXO8ZaNlnJPIhEz3H+cqXxm82AebsOX3bSkMu3peKL7e/5fjVz6TdB iXDvOJPC/0QGnyt/1WAz3ky2izpFdIKSryCCYyrEFeGXcccZb8Lpim3soqqQrOsEOjtF DHuI82XHWd81NtTYIVULpPXwkXvHpjYnSTz5XM7i2/+94j9OFWGduzxqBcLyrMnqQGv2 ww8OcsSZbAT5jIpCX2P1VvqfVzas2SbKimj7xMyZTBudY7bsyJOIGp53jRZeY9j6WneS 6tVw== X-Gm-Message-State: AOAM532cX4ghFKmd5+V7jL8Uy0Ak4j9t629RmjZc8iIykvcVYW0YfLwu sOpIrW5xyJUKXnM28dppR1k460iu3Et1YdG8jxQ= X-Google-Smtp-Source: ABdhPJyo2jBmNFqbiCZ49HOT+xraWujM6Rvv7yHuD8FtTJw0N5oZ0bmihmFrtpj2tOU1L9qRWqDddVg0/m2wNIvbx0c= X-Received: by 2002:a2e:a889:0:b0:24e:e9cd:dbe7 with SMTP id m9-20020a2ea889000000b0024ee9cddbe7mr3865582ljq.336.1652465914807; Fri, 13 May 2022 11:18:34 -0700 (PDT) MIME-Version: 1.0 References: <165234915463.59217.4764646487635997106@ietfa.amsl.com> In-Reply-To: <165234915463.59217.4764646487635997106@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 13 May 2022 14:18:23 -0400 Message-ID: To: Andrew Alston Cc: The IESG , draft-ietf-dnsop-nsec3-guidance@ietf.org, dnsop-chairs , "" , Tim Wicinski Content-Type: multipart/alternative; boundary="000000000000db0a2c05dee8b3a0" Archived-At: Subject: Re: [DNSOP] Andrew Alston's Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 18:18:40 -0000 --000000000000db0a2c05dee8b3a0 Content-Type: text/plain; charset="UTF-8" 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 d3e3e3@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 < noreply@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 > --000000000000db0a2c05dee8b3a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

If you want to claim that because of the recommend= ations in it, this document should be standards track instead of BCP, there= might=C2=A0be some merit to such a position, although personally I think i= t is fine as a BCP and I don't think the code point allocation has anyt= hing to do with this question. I did a quick survey of some DNS related BCP= s that request IANA registries or code points and list them below.

(The intent of the current IANA system=C2=A0is that,= to the extent possible, the entirety of the conditions for IANA assignment= be encoded into (or pointed to from) the registry. The assignment criterio= n for an "Extended DNS Error Code", the code point allocated by t= his draft, is First Come, First Served (FCFS). Unless I am missing somethin= g, it makes no difference to assigning such a code point what kind of docum= ent this is. It embodies a request, so IANA should grant a code point,=C2= =A0whether IANA receives the request via email or via the progressing of a = draft. That's all there is to the=C2=A0assignment. From the=C2=A0point = of view of code point allocation, it=C2=A0would be fine if this draft was t= argeted=C2=A0at Informational, or an April 1st draft, or some random non-IE= TF 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 futur= e authors, when applicable.)

Thanks,
Do= nald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-3= 33-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2= =A0d3e3e3@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 i= s changed, by the time the RFC is published, to say "IANA has establis= hed a registry..." or the like. This is less true for older RFCs.)

Some DNS BCP RFCs that create or modify IANA Registri= es:
RFC 8552, BCP 222
RFC 6895 (and predecessors), BCP = 42
RFC 6382, BCP 169
RFC 6303, BCP 163
RFC 31= 72, BCP 52

Some DNS BCP RFCs that assign entries i= n IANA Registries:
RFC 7793, BCP 163
RFC 4159, BCP 109<= /div>
RFC 3681, BCP 80
RFC 3152, BCP 49
RFC 2606, B= CP 32



On Thu, May 12, 2022 at 5:52 AM An= drew Alston via Datatracker <noreply= @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/dr= aft-ietf-dnsop-nsec3-guidance/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I've been sitting trying to work out in my mind if a BCP document shoul= d 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 n= ormative
language and require additional code points aren't better suited to a s= tandards
track document.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work put into this document.

Having read through the document, I would also like to support Paul's d= iscuss
since the document does seem to update RFC5155.=C2=A0 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 entitl= ed
"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
--000000000000db0a2c05dee8b3a0--