Re: Revised Last Call: 'SSH Transport Layer Encryption Modes' to Proposed

Harald Tveit Alvestrand <harald@alvestrand.no> Thu, 25 August 2005 13:51 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8I8I-0007gL-FY; Thu, 25 Aug 2005 09:51:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8I8F-0007g8-W4 for ietf@megatron.ietf.org; Thu, 25 Aug 2005 09:51:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18229 for <ietf@ietf.org>; Thu, 25 Aug 2005 09:51:02 -0400 (EDT)
Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8I8k-0003qR-5T for ietf@ietf.org; Thu, 25 Aug 2005 09:51:37 -0400
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5256732008E; Thu, 25 Aug 2005 15:50:37 +0200 (CEST)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10983-03; Thu, 25 Aug 2005 15:50:33 +0200 (CEST)
Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 092AF32008A; Thu, 25 Aug 2005 15:50:31 +0200 (CEST)
Date: Wed, 24 Aug 2005 15:58:47 -0700
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org
Message-ID: <46C13E980BDB2E98F9AEC683@B50854F0A9192E8EC6CDA126>
In-Reply-To: <tsl4q9fxc2j.fsf@cz.mit.edu>
References: <E1E82S5-0007mc-Nz@newodin.ietf.org> <tsl4q9fxc2j.fsf@cz.mit.edu>
X-Mailer: Mulberry/4.0.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc:
Subject: Re: Revised Last Call: 'SSH Transport Layer Encryption Modes' to Proposed
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On 24. august 2005 17:24 -0400 Sam Hartman <hartmans-ietf@mit.edu> wrote:

>     iesg> It is customary to include normative references to
>     iesg> informational documents describing cryptographic algorithms.
>     iesg> However the procedures of RFC 3967 require that this
>     iesg> normative reference be called out in the IETF last call.
>
>
> For the record I'd like to say that RFc 3967 seems poorly considered
> and I don't think strikes a reasonable balance between efficiency and
> quality.
>
> In particular RFC 3967 does not allow classes of documents such as
> cryptographic algorithms to be exempted from last call notice, only
> single documents.

For the record, I'd like to say that I disagree.

I think that if we search for an "easiest possible way to implement" the 
RFC 3967 requirement, we will end up with a single web-maintained document 
of "documents that are OK to refer to". Doing explicit action to add each 
sensible crypto document to that list as it comes out doesn't strike me as 
onerous.

                  Harald



_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf