Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 05 June 2014 22:50 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF1F1A0305; Thu, 5 Jun 2014 15:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqsEJsgDNUuH; Thu, 5 Jun 2014 15:50:34 -0700 (PDT)
Received: from BLU004-OMC2S30.hotmail.com (blu004-omc2s30.hotmail.com [65.55.111.105]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA78C1A0301; Thu, 5 Jun 2014 15:50:33 -0700 (PDT)
Received: from BLU181-W63 ([65.55.111.72]) by BLU004-OMC2S30.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Thu, 5 Jun 2014 15:50:27 -0700
X-TMN: [2hjnQx5PyqNchoe+e8e8Ym2jjY/0Xp2/]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU181-W63C161BF283F81F845154C932D0@phx.gbl>
Content-Type: multipart/alternative; boundary="_d78546a1-20d0-4240-861f-245d4c3246a7_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Ted Lemon <ted.lemon@nominum.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Thu, 05 Jun 2014 15:50:26 -0700
Importance: Normal
In-Reply-To: <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com>
References: <E87B771635882B4BA20096B589152EF628724B2C@eusaamb107.ericsson.se>, <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie>, <5390D2F8.6000801@gmail.com>, <1B87ABE4-1CA1-450D-BA96-3018DF39F08D@nominum.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Jun 2014 22:50:27.0082 (UTC) FILETIME=[8B22FEA0:01CF8110]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/HYwHzUrfxzwcnIalMXOLKij4ppY
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 22:50:36 -0000

Ted said: 
"If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them.   So bringing up those flaws during the adoption process is crucial to the process."
[BA] I would agree that there should be an agreement to address the flaws prior to adoption, but in my experience that is often not enough.  If the flaws are major enough, sometimes the fixes end up being non-trivial, or even turn into an argument about the feasibility of fixing them at all.   More than once I have seen this turn into a "war of attribution" between the editors and the WG, where the editors assert that because the WG adopted the document, they effectively endorsed the approach, and the WG asserting that they never would have adopted the document with the knowledge that the flaws would remain. 
To prevent this kind of argument down the line, if there is a major flaw in a document, I now believe it is best to insist that it be addressed  *prior* to adoption.