Re: [Last-Call] [Ext] [DNSOP] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10

Warren Kumari <warren@kumari.net> Fri, 21 October 2022 18:54 UTC

Return-Path: <warren@kumari.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDD4C15AE3C for <last-call@ietfa.amsl.com>; Fri, 21 Oct 2022 11:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
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 mXkrxUx1k_7t for <last-call@ietfa.amsl.com>; Fri, 21 Oct 2022 11:54:41 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 4AEDAC159484 for <last-call@ietf.org>; Fri, 21 Oct 2022 11:54:37 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id b79so3083105iof.5 for <last-call@ietf.org>; Fri, 21 Oct 2022 11:54:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+WOjGjvmmETunSltxMjlYlrj3LUuWBp2ALChhsbyd1g=; b=EpI1kRJT0UVkC5TwFNU6qwMkDjh4pLVvDTP5210vjj5MnObpZRMcMoOTZLVU4XIQfT /EdT08+XgKkoOWC04TEupafwRD+TeAkyWwtyuO2Igz3g7VRtF1rSsDVDu9UvmgnTR8av xZ/o/cTJQqwlacPKqgSG2PZa0mUVqCHQ+iDNzGdUn2CNDonGCmBWZw83mBf81V6klO+p Ygw1PXGeQUw0JRc44JpN9x2MV+Qk0wvrEOEIHq+9YwRHLBgJikXK+hdMkvKP9GRqxhEf 7OGO07iN8LJnS1OqALMMvsdalM2A7q3bpNzsXe7j4AkskFY5jn7ccwLD7THGYVrfiMPp HVdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+WOjGjvmmETunSltxMjlYlrj3LUuWBp2ALChhsbyd1g=; b=k2nXYAjhX/EWevB/4xLacCnuNouPtIDErVn9cvELHIKUXKEgy4jpRRLEPsCdvC3A8d 66MLOjVIWAFsbxX+iPVKyMwhI2Q4BS3clhDPZZ3OVSWn8QvAohOLs8KpeWU/93VT1s83 bfSrd2NCLIAfD9gzW6WrHlFh0o/jsbNYIZTpfRI3YEGhOBcbJ4Tl7rafWTaOadAPexnV 0YfFpSImxUDa1o7uBUtb9QwvIlLBxErOWk0XbyNL/AVa4NIPuoeMCx+AF7mjKQjifne0 ZFyPgix1wXACaV9Wu34JLiKkrE4wmznHnfeaj1jTvbihewve73iLOp98GR2iEsdP2Fwl yWYQ==
X-Gm-Message-State: ACrzQf0OjnkaijNGPrX6yGE91w/wUMvWjq/ys2CCi9NcEzZNw7WayaS4 brC12SCmISYDzP9TDdzYkkrInIQF6A1EAc/KvRmFyw==
X-Google-Smtp-Source: AMsMyM5JoTt7nZyXTmnokZ02GGkFmnmjYmp5lgEfkvmtJVZ6LSqUJWhASLCGiCNjO8pD/Rd8zwHsOb6b5ady/R/41aI=
X-Received: by 2002:a05:6638:418b:b0:365:c4fd:3ffa with SMTP id az11-20020a056638418b00b00365c4fd3ffamr16003270jab.216.1666378475631; Fri, 21 Oct 2022 11:54:35 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Oct 2022 11:54:34 -0700
Mime-Version: 1.0
X-Mailer: Superhuman Desktop (2022-10-20T22:05:53Z)
X-Superhuman-Draft-ID: draft00c7bf9295170422
In-Reply-To: <CAHw9_iKmk3FBNnCV6P22fe8A6F2sYgn5bNniBtczfVu3qY-iZw@mail.gmail.com>
References: <166566129313.28471.9552612703046827117@ietfa.amsl.com> <147c2505-8b8e-e956-badf-ec633b030547@tcinet.ru> <CAHy0fzBcN9Vd9GRFB157W_23akhpy22yZa=9bV2_91hVdicYPA@mail.gmail.com> <BD832679-C3E6-4EB8-82B6-84D83A47B53D@icann.org> <CAHw9_iKmk3FBNnCV6P22fe8A6F2sYgn5bNniBtczfVu3qY-iZw@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
X-Superhuman-ID: l9iupfxw.8a1b958a-625e-4c3d-abb2-28042d076b16
Date: Fri, 21 Oct 2022 11:54:34 -0700
Message-ID: <CAHw9_iJKAhf_hs9--P9=1LW0iXFa0NK-qCREh-eukQBMLM5Jpg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Ron Even <ron.even.tlv@gmail.com>, gen-art@ietf.org, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-rfc5933-bis.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001a0d3b05eb8ff91b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/vkBGzvKlTAVQqLR1Gqr2BGRezfE>
Subject: Re: [Last-Call] [Ext] [DNSOP] Genart last call review of draft-ietf-dnsop-rfc5933-bis-10
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2022 18:54:45 -0000

On Wed, Oct 19, 2022 at 12:41 PM, Warren Kumari <warren@kumari.net> wrote:

> On Wed, Oct 19, 2022 at 7:22 AM, Paul Hoffman <paul.hoffman@icann.org>
> wrote:
>
>> On Oct 18, 2022, at 7:58 AM, Ron Even <ron.even.tlv@gmail.com> wrote:
>>
>> 1. whis is this an informational RFC and not a standard track RFC.
>>
>> That's a reasonable question with a simple answer: because the WG changed
>> its mind on what the status of this protocol should be. RFC 5933 describes
>> a national standard that is thinly deployed. At the time, it was necessary
>> to have the protocol on standards track; now it no longer is required.
>>
>> 2. What is requested from IANA. ths text you wrote and I copied is not a
>> directive to IANA that is clear
>>
>> You are correct that the IANA Considerations section is quite unclear,
>> and needs to be clarified before the IESG considers it.
>>
>
>
> That is a good point.
>
> The document says:
> ---
> This document updates the RFC IANA registry "Delegation Signer
> (DS) Resource Record (RR) Type Digest Algorithms" by adding an entry for
> the GOST R 34.11-2012 algorithm:
>
>       Value   Algorithm
>       TBA2    GOST R 34.11-2012
>
>    The entry for Value 3, GOST R 34.11-94 should be updated to have its
> Status changed to '-'.
> ----
>
> The IANA registry being referenced "DNSSEC Delegation Signer (DS) Resource
> Record (RR) Type Digest Algorithms" is here: https://www.iana.org/
> assignments/ds-rr-types/ds-rr-types.xhtml
>
> Setting this to '-' does seem incorrect, and from the text I think that it
> should be either "MUST NOT" or, better yet (for clarity) "DEPRECATED" .
>
> In addition, the IANA has a question:
> ------
> "Third, in the DNSSEC Delegation Signer (DS) Resource Record (RR) Type
> Digest Algorithms registry located at:
>
> https://www.iana.org/assignments/ds-rr-types/
>
> a new registration will be made as follows:
>
> Value: [ TBD-at-Registration ]
> Description: GOST R 34.11-2012
> Status:
> Reference: [ RFC-to-be ]
>
> IANA Question --> What should the entry for "Status" be for this new
> registration?"
> --------
>
>
>
>
> I believe that it is clear (e.g: "6.  Implementation Considerations
>    The support of this cryptographic suite in DNSSEC-aware systems is
>    OPTIONAL.") that it can only be OPTIONAL, but we need to clearly state
> that.
>
> So, I think a new version should be submitted saying:
> ----
> This document updates the RFC IANA registry "Delegation Signer (DS)
>    Resource Record (RR) Type Digest Algorithms" by adding an entry for
>    the GOST R 34.11-2012 algorithm:
>
>       Value:   TBA2
>       Description: GOST R 34.11-2012
>       Status: OPTIONAL
>       Reference: [ RFC-to-be ]
>
>    The entry for Value 3, GOST R 34.11-94 should be updated to have its
>    Status changed to 'DEPRECATED'.
>

A new version was submitted (-11), but still says:
"   The entry for Value 3, GOST R 34.11-94 should be updated to have its
   Status changed to '-'."

The registry is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

'-' to me implies that the codepoint hasn't  been used, but I don't
actually know if that's true. I think "DEPRECATED" is better, but perhaps
I'm wrong (anyone seeing '-' will presumably do read the referenced RFC,
so…_)

I will ask the IANA which they think is best / clearest…

W



> W
>
>
>> --Paul Hoffman
>>
>