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

[Brian E Carpenter <[e-mail]>]

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 http://tools.ietf.org/html/rfc7221#section-2.2
		 	   		
Specifically, it's a higher bar than the combination of
   *  Does the document provide an acceptable platform for continued
      effort by the working group?
and
   *  What are the process or technical objections to adoption of the
      draft?

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.

    Brian