Re: draft-ietf-dnsext-dnssec-gost

Phillip Hallam-baker <hallam@gmail.com> Mon, 15 February 2010 18:09 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208A73A7BA8 for <ietf@core3.amsl.com>; Mon, 15 Feb 2010 10:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn56YZL7u20b for <ietf@core3.amsl.com>; Mon, 15 Feb 2010 10:09:01 -0800 (PST)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id EC4083A7B73 for <ietf@ietf.org>; Mon, 15 Feb 2010 10:09:00 -0800 (PST)
Received: by qw-out-2122.google.com with SMTP id 9so73544qwb.31 for <ietf@ietf.org>; Mon, 15 Feb 2010 10:10:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:x-mailer :mime-version:subject:date:cc; bh=J/HdcreMgiVpAmuQyqL7p7A4x89xgOj5qTARVDiSRKM=; b=KwuNKr8tDMbrbxDppy9RjIgnnG5ZI5ceqOwNUBu4dhS9V7hqWDTLO/lRjkpdrNnEQj Gg7//TF3pypCsSO2cmbZRYXE6PnIFiw6AqKnPGBwyIbcy+XIQFE4emAxVbcQ15j4lOJR 0AvS2CwH1y054emA/R4PKYpVvjV9sgQnybP3U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:x-mailer:mime-version:subject:date:cc; b=lZKnat6/8GKwlNSbJmRIiKX4MkFKkqmcYZXGUOoJpI8xGLr6WKShcxH5ud7p8J7LR3 BmykOoObgPpXZMT2wezkKnfWqVVvY6c9invaCm5zY9kxT5c+mwGtY16rMrIo67pfQ8oA 5FCN7mjr9WgBYNB1YTGYn71RG7BtVYS7P1ql0=
Received: by 10.224.59.96 with SMTP id k32mr142208qah.261.1266257427113; Mon, 15 Feb 2010 10:10:27 -0800 (PST)
Received: from ?10.176.72.107? ([32.140.251.115]) by mx.google.com with ESMTPS id 21sm4425249qyk.4.2010.02.15.10.10.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Feb 2010 10:10:25 -0800 (PST)
References: <201002151420.o1FEKCMx024227@fs4113.wdf.sap.corp> <8E06CA9085DD4D0E906BD6178C495AFE@china.huawei.com>
Message-Id: <EDE164C5-EC1B-4DD1-93B5-903FE222F74B@gmail.com>
From: Phillip Hallam-baker <hallam@gmail.com>
To: Spencer Dawkins <spencer@wonderhamster.org>
In-Reply-To: <8E06CA9085DD4D0E906BD6178C495AFE@china.huawei.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (5H11)
Mime-Version: 1.0 (iPhone Mail 5H11)
Subject: Re: draft-ietf-dnsext-dnssec-gost
Date: Mon, 15 Feb 2010 13:09:56 -0500
X-Mailman-Approved-At: Tue, 16 Feb 2010 08:09:52 -0800
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2010 18:09:02 -0000

One point that seems to be ambiguous here is what the role of an rfc  
is with respect to defacto standards status

In theory informational rfc do not establish or modify standards. In  
practice the broken process that stops anything being a standard and  
makes those we do have obsolete means that this is not obvious

In my view a should or must in an informational rfc only has scope to  
the document itself. So the gost draft should use MUST or Should in my  
view

But I can see how this could confuse


Sent from my iPhone

On Feb 15, 2010, at 9:52 AM, "Spencer Dawkins" <spencer@wonderhamster.org 
 > wrote:

> On one point in this discussion...
>
> I'm not saying that everyone will SEE it, but there actually is an  
> errata process for RFCs, and the omission of the year-version suffix  
> in RFC 4357 seems like something that would be really helpful to  
> submit an errata for.
>
> Submission page is at http://www.rfc-editor.org/errata.php.
>
> The errata link does show up on many hyperlinked versions of RFCs,  
> so things aren't as bleak as they were ten years ago, to pick an  
> interval.
>
> Thanks,
>
> Spencer
>
> ----- Original Message ----- From: "Martin Rex" <mrex@sap.com>
> To: "Basil Dolmatov" <dol@cryptocom.ru>
> Cc: <ietf@ietf.org>
> Sent: Monday, February 15, 2010 8:20 AM
> Subject: Re: draft-ietf-dnsext-dnssec-gost
>
>> > IMHO, rfc4357 should have been completely stripped from GOST  
>> R34.10-1994
>> > before publication if what you describes really applies to this >  
>> algorithm.
>>
>> I think that is a question to authors of RFC4357 and I think that
>> corrections should be issued.
>
> There is no correction process for RFCs.
>
> Preferably the new document about GOST R34.10 signature algorithms
> should be merged with rfc4357 into rfc4357bis, and this time the
> GOST R34.10-1994 algorithm should only be mentioned in the Security
> Considerations as having been completely retired/phased out in 2004.
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf