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

Boris Makarenko <bmakarenko@tcinet.ru> Wed, 19 October 2022 13:14 UTC

Return-Path: <bmakarenko@tcinet.ru>
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 A6632C14CE3F; Wed, 19 Oct 2022 06:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tcinet.ru
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 1yoNN3c5yrky; Wed, 19 Oct 2022 06:14:39 -0700 (PDT)
Received: from tcinet.ru (enki.tcinet.ru [212.193.119.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB739C14CE43; Wed, 19 Oct 2022 06:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=tcinet.ru; s=mail; bh=6/jvyQZyDcKv3BnJXmfj8bwd93JsdqVVikZy4kcvZz8=; h=In-Reply-To:Content-Language:References:Cc:To:Subject:From:MIME-Version: Date:Message-ID:Content-Type; b=ZxkT4HXpmi1n3eaOuI3ax4WPqJ3BFmx/c/xeBHdwshVZQ vF0p+m1gYoUKwwM9sTWXDcSls+1WoUGhVHCJkH8VqwOUbLt5Ymwdk6ORjqt3GBQo6PBKeTon/TaQw JPKyB41qKIeTh0S6jwsMLfEcm6UhyZIMVe4NneNJH7fNqt3ETJ7LkSAgsIQ/rI3XgIjwDTaVs7dGL g79MeJwRvqobncj8RNRl+9F59qUI9ZwWh60M9Bly1VzGchq1oy9ftlnRkup2Jr4rWix2H13HP9Zgg KCZQ0j5eKuVv8K7cTRci+zqYXE3CGHrcUBXLlWbygLkpEn512To/R4GzgobSbMDpyw==
Received: from [95.31.190.179] (account bmakarenko@tcinet.ru HELO [192.168.1.225]) by tcinet.ru (CommuniGate Pro SMTP 6.3.14e) with ESMTPSA id 5100967; Wed, 19 Oct 2022 16:14:29 +0300
Content-Type: multipart/alternative; boundary="------------9hGlNHUGCjcDCpHwSGrbMHuW"
Message-ID: <67ae8495-587f-91fc-39f2-81bc8a7a70f5@tcinet.ru>
Date: Wed, 19 Oct 2022 16:14:29 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
From: Boris Makarenko <bmakarenko@tcinet.ru>
To: Ron Even <ron.even.tlv@gmail.com>
Cc: gen-art@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-rfc5933-bis.all@ietf.org, last-call@ietf.org
References: <166566129313.28471.9552612703046827117@ietfa.amsl.com> <147c2505-8b8e-e956-badf-ec633b030547@tcinet.ru> <CAHy0fzBcN9Vd9GRFB157W_23akhpy22yZa=9bV2_91hVdicYPA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAHy0fzBcN9Vd9GRFB157W_23akhpy22yZa=9bV2_91hVdicYPA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/z7JuboLuqAAg_SUMhEN7s2VlZ9I>
Subject: Re: [Last-Call] 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: Wed, 19 Oct 2022 13:14:43 -0000

Hi!

Then, what should we do? If we change the intended status to standards 
track, will it be ok? Will it require more steps to get it approved?

Can we possibly get the draft approved as an informational RFC?

--

Boris

18.10.2022 17:58, Ron Even пишет:
> Hi, your response does not address my comments. 1. whis is this an  > informational RFC and not a standard track RFC. 2. What is requested 
 > from IANA. ths text you wrote and I copied is not a directive to > 
IANA that is clear Roni > > On Mon, Oct 17, 2022 at 2:44 PM Макаренко 
Борис > <bmakarenko@tcinet.ru <mailto:bmakarenko@tcinet.ru>> wrote: > > 
Hello, Roni! > > The old algorithms GOST R 34.11-94, GOST R 34.10-2001 
and GOST R > 34.11-2001 are considered obsolete. They are now replaced 
with GOST > R 34.10-2012 (digital signature) and GOST R 34.11-2012 (hash 
 > function). Basically, the use of GOST algorithms in DNSSEC remains > 
the same as described in RFC 5933, but it is necessary to replace > them 
with the new ones. Old algorithms should not be used anymore. > That's 
why we need to obsolete RFC 5933. > > The section "IANA Considerations" 
proposes to assign numbers for > GOST R 34.10-2012 and GOST R 34.11-2012 
in the IANA registries "DNS > Security Algorithm Numbers" > 
(https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml 
 > > 
<https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>)
> and "Delegation Signer (DS) Resource Record (RR) Type Digest  > Algorithms" > 
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml > 
<https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml>). > > 
Updates for RFC 8624 are described in the corresponding Section. > > -- 
Boris > > > 13.10.2022 14:41, Roni Even via Datatracker writes: >> 
Reviewer: Roni Even Review result: Almost Ready >> >> I am the assigned 
Gen-ART reviewer for this draft. The General >> Area Review Team 
(Gen-ART) reviews all IETF documents being >> processed by the IESG for 
the IETF Chair. Please treat these >> comments just like any other last 
call comments. >> >> For more information, please see the FAQ at >> >> 
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq> >> 
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> Document: 
draft-ietf-dnsop-rfc5933-bis-?? Reviewer: Roni Even >> Review Date: 
2022-10-13 IETF LC End Date: 2022-10-19 IESG Telechat >> date: Not 
scheduled for a telechat >> >> Summary: the document is almost ready for 
publication as some type >> of an RFC >> >> Major issues: The document 
is meant to be an informational RFC >> obsoleting RFC5933 a standard 
track RFC. why is this change. >> >> Minor issues: >> >> the directive 
in the IANA consideration "The entry for Value 3, >> GOST R 34.11-94 
should be updated to have its Status changed to >> '-'" is not clear. 
there is no status field in the table as I see >> in RFC8624 section 3.3 
 >> >> Nits/editorial comments: >> >> >> >> >