Re: [Gen-art] 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: gen-art@core3.amsl.com
Delivered-To: gen-art@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>
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: Wed, 14 Apr 2010 15:43:00 -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>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-isms-dtls-tm-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-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