RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)

Ned Freed <ned.freed@mrochek.com> Tue, 11 September 2007 19:30 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBRG-0003aS-Ur; Tue, 11 Sep 2007 15:30:22 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVBRF-0003Wo-4C for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:30:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBRE-0003UJ-PW for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:30:20 -0400
Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBRC-0004tA-33 for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:30:20 -0400
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8DYK2FIO00ALEH@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 12:30:15 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8D10E8SW003GRV@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 12:30:03 -0700 (PDT)
Message-id: <01ML8DYIHPJQ003GRV@mauve.mrochek.com>
Date: Tue, 11 Sep 2007 12:04:01 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
In-reply-to: "Your message dated Tue, 11 Sep 2007 12:19:22 +0100" <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
MIME-version: 1.0
References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110>
To: Debbie Garside <debbie@ictmarketing.co.uk>
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189539014; h=Date: From:Subject:MIME-version; b=Av7JmOtySlE3J9Cj6co1PPja1BeWUc1HXfz+gs 30B25RyRjKJdF+kLMhGUCLifVKQanIFTMUn5lO3mQRmM+dsQ==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' <iljitsch@muada.com>, ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, ietf-http-auth@osafoundation.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

> > `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> > `it means just what I choose it to mean -- neither more nor less.'

> There has been a discussion recently on LTRU as to whether a Terms and
> Definitions section should be introduced within RFCs - much like those
> within ISO Standards.

And my response to this suggestion is the same as it was for the "IANA
considerations" or "Internationalization considerations" section suggestions:
By all means have a "terms and definitions" section or whatever in the document
if there's a need for one, but don't make having one mandatory in all
documents.

We already have more than enough useless (from a technical content
perspective) boilerplate in our documents. We don't need any more, and
when such sections are always present but usually say "no such and such
are present" they aren't helping.

The last time this came up in the context of IANA considerations it was
asserted that having such sections act as a useful check to make sure there are
no needed definitions or considerations. The problem is people don't work this
way. If the section is mandatory they'll add it when the document is first
created. Sometimes they'll remember to keep it up to date and sometimes they
won't. But when someone reviews the document they'll see that section
and assume its presence means whatever has been checked. So the mandatory
section approach can actually result in more errors and omissions, not less.

It took me only a few minutes the last time we had one of these discussions
to find a documentt (in the RFE Editor's queue, as I recall) where
this had happened: A "there are no IANA considerations" section had been
added early on but when the document acquired IANA considerations it
wasn't updated. And nobody who reviewed the document caught it.

				Ned

P.S. I've read a lot of ISO and CCITT specifications and I have found
their terms and definitions material to be fairly hit or miss in terms of
utility.