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

Brian E Carpenter <> Thu, 05 June 2014 23:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5F58C1A02CC; Thu, 5 Jun 2014 16:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mOoFBcgFntLA; Thu, 5 Jun 2014 16:10:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7330C1A025B; Thu, 5 Jun 2014 16:10:20 -0700 (PDT)
Received: by with SMTP id ma3so1754534pbc.37 for <multiple recipients>; Thu, 05 Jun 2014 16:10:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aU+WvhzGjA961ToEp8Gf0JmyKKk+nSprBolXtUeVNP8=; b=YVr5ytbcx1/1/FEg6vaLdXJcD7TuTmQ69HK38c18G98D9CYRK2aXnmF4mBiluzih4A 47zbXcloRBlRY4Nw8+266FXFGScUT1hC/dsdk78IvLpMu7Y+FfFc08XRuMbnU4UAbGTt w118wwZ2SimRbh6QkjHglDTzGhqxkVK1zOwLxBu5y4jZtKkcNJWAXS7REQAt48if/guJ GF8ByLynYPl/YkNYzLkpNZ4mMaJXS6/VbXj0lFZGmZojFLaX715vWWKZ/Hn+DJsAkxxN BfiZXWr5h4sTTeLwUop8aYdHPUQuTxCAh/PMVK3u0c2B0W3A032BItGlkkFCwVbacEXC 1+gw==
X-Received: by with SMTP id vw5mr1236708pbc.113.1402009813963; Thu, 05 Jun 2014 16:10:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id io8sm27615127pbc.96.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 16:10:13 -0700 (PDT)
Message-ID: <>
Date: Fri, 06 Jun 2014 11:10:20 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Bernard Aboba <>
References: <>, <> <>, <>, <> <BLU181-W63C161BF283F81F845154C932D0@phx.gbl>
In-Reply-To: <BLU181-W63C161BF283F81F845154C932D0@phx.gbl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 06 Jun 2014 08:11:56 -0700
Cc: "" <>, "" <>, Ted Lemon <>
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jun 2014 23:10:22 -0000

One more response and then I will shut up on this issue:

On 06/06/2014 10:50, Bernard Aboba wrote:
> 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.  

That seems to me to be going one step further than the criteria
suggested in RFC7221 (only Informational, but recently approved by
the IESG) at
Specifically, it's a higher bar than the combination of
   *  Does the document provide an acceptable platform for continued
      effort by the working group?
   *  What are the process or technical objections to adoption of the

If the draft is an acceptable base and the technical objections
are understood, there's no reason not to proceed. And to repeat,
I agree with the technical objections in this case, and with the
suggestion of how to fix them.