IETF Logo Mail Archive

Re: [dix] Re: [Ietf-http-auth] More requirements

"RL 'Bob' Morgan" <rlmorgan@washington.edu> Fri, 14 July 2006 15:42 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PoU-00027B-7Z; Fri, 14 Jul 2006 11:42:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1PoT-00026g-Cm for dix@ietf.org; Fri, 14 Jul 2006 11:42:45 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlP-0007Gs-MS for dix@ietf.org; Fri, 14 Jul 2006 10:35:31 -0400
Received: from mxout5.cac.washington.edu ([140.142.32.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1O4A-00063B-Ik for dix@ietf.org; Fri, 14 Jul 2006 09:50:52 -0400
Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.6+UW06.06/8.13.6+UW06.03) with ESMTP id k6EDolx3026073; Fri, 14 Jul 2006 06:50:47 -0700
X-Auth-Received: from h1065-net84db.lab.risq.net (h1065-net84db.lab.risq.net [132.219.16.101] (may be forged)) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k6EDohh5019412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Jul 2006 06:50:46 -0700
Date: Fri, 14 Jul 2006 09:51:11 -0400
From: RL 'Bob' Morgan <rlmorgan@washington.edu>
X-X-Sender: rlmorgan@perf.cac.washington.edu
To: Jeff Hodges <Jeff.Hodges@neustar.biz>
Subject: Re: [dix] Re: [Ietf-http-auth] More requirements
In-Reply-To: <44B79C5B.8070103@neustar.biz>
Message-ID: <Pine.LNX.4.64.0607140948080.32679@perf.cac.washington.edu>
References: <1b587cab0607131743g36c96314ta9b3a0a90aa871e0@mail.google.com> <86wtag5r75.fsf@delta.rtfm.com> <Pine.LNX.4.64.0607140835550.31752@perf.cac.washington.edu> <44B79C5B.8070103@neustar.biz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: Digital Identity Exchange <dix@ietf.org>, IETF HTTP Auth <ietf-http-auth@lists.osafoundation.org>
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Digital Identity Exchange <dix@ietf.org>
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Errors-To: dix-bounces@ietf.org

> Indeed, many of these are distinct "security properties". Note in the intro 
> to his note, ekr termed the content of his note as:
>
>  "a taxonomy of requirements/features and technical options"

Right, a problem we often have with stating requirements is 
differentiating between "X is required to be possible/negotiable" and "X 
is required to always be done"; where the first of these produces 
derivative requirements about the nature of the negotiation of and/or 
policy around the feature.

  - RL "Bob"

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

v2.23.0 | Report a Bug | By Email