Re: Gen-ART review of draft-ietf-isms-dtls-tm-09
Wes Hardaker <wjhns1@hardakers.net> Wed, 14 April 2010 22:37 UTC
Return-Path: <wjhns1@hardakers.net>
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 1C3563A6861; Wed, 14 Apr 2010 15:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ADj36kgQNzX7; Wed, 14 Apr 2010 15:36:59 -0700 (PDT)
Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 015673A6828; Wed, 14 Apr 2010 15:36:59 -0700 (PDT)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 8FD5E981E5; Wed, 14 Apr 2010 15:36:52 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Spencer Dawkins <spencer@wonderhamster.org>
Subject: Re: Gen-ART review of draft-ietf-isms-dtls-tm-09
Organization: Sparta
References: <594A0DDD7F504FB8BD94B8951D0E12A5@china.huawei.com> <AD968DFBB28145488CAEBBDD7B3E3C46@china.huawei.com> <920496484254452EBCBB827073F9E9F6@china.huawei.com> <670F0BC6C6E8460D928B31623A463504@china.huawei.com> <sdzl15940q.fsf@wjh.hardakers.net> <85C72E6663B742FA92F90F0DFC755643@china.huawei.com>
Date: Wed, 14 Apr 2010 15:36:52 -0700
In-Reply-To: <85C72E6663B742FA92F90F0DFC755643@china.huawei.com> (Spencer Dawkins's message of "Wed, 14 Apr 2010 15:57:56 -0500")
Message-ID: <sdpr217jaz.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailman-Approved-At: Thu, 15 Apr 2010 11:31:49 -0700
Cc: draft-ietf-isms-dtls-tm.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, ietf@ietf.org, Wes Hardaker <wjhns1@hardakers.net>
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: Wed, 14 Apr 2010 22:37:00 -0000
>>>>> On Wed, 14 Apr 2010 15:57:56 -0500, "Spencer Dawkins" <spencer@wonderhamster.org> said: > 2 WONTDO 3.1.1. Threats > ~~~~~~~~~~~~~~~~~~~~~~~~~ SD> Oh, I agree that you shouldn't delete it, especially since you SD> confirmed that it's normative. I was hoping for something a little SD> more precise (like, naming a mandatory-to-implement non-NULL SD> encryption cipher suite :-) and I'm now wondering why it's not a SD> MUST/MUST unless X. But do the right thing ;-). The idea was to leave algorithm requirements up to the base-protocols. SNMP has a long history of not mandating encryption (for reasons that are historic and probably no longer valid), and we didn't want to change that. Hence the SHOULD. Anyway, I'll leave it as is and consider this "closed". Thanks! [similarly for the 2119 issue] > 6 DONE 2) continued: > ~~~~~~~~~~~~~~~~~~~~~ >> If the connection is being established for reasons >> other than configuration found in the SNMP-TARGET-MIB >> then configuration and procedures outside the scope of >> this document should be followed. Configuration SD> I'm easily confused, but isn't this sentence word-for-word what the SD> original text said? :D Um, whoops. Wrong copy/paste apparently. I should have quoted this: If the connection is being established from configuration based on SNMP-TARGET-MIB configuration, then the snmpTlstmAddrTable DESCRIPTION clause describes how the verification is done (using either a certificate fingerprint, or an identity authenticated via certification path validation). Which spells out more clearly "configuration based on" instead of "reasons". SD> If this is clear to those skilled in the art, no problem. I'm just SD> telling you I can't parse it! No, I'm sure it's confusing to anyone without a strong background in how the SNMP-TARGET-MIB works in SNMP. We've tried to make it clean but I'm more than certain to someone without knowledge of how the SNMP-TARGET-MIB works you'd get quickly lost. -- Wes Hardaker Cobham Analytic Solutions
- Gen-ART review of draft-freed-sieve-notary-07 Spencer Dawkins
- Re: Gen-ART review of draft-freed-sieve-notary-07 ned+ietf
- Gen-ART review of draft-ietf-isms-dtls-tm-09 Spencer Dawkins
- Re: Gen-ART review of draft-ietf-isms-dtls-tm-09 Spencer Dawkins
- Re: Gen-ART review of draft-ietf-isms-dtls-tm-09 Spencer Dawkins
- Re: Gen-ART review of draft-ietf-isms-dtls-tm-09 Wes Hardaker
- Re: Gen-ART review of draft-ietf-isms-dtls-tm-09 Wes Hardaker
- Re: Gen-ART review of draft-ietf-isms-dtls-tm-09 Wes Hardaker