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

[Joe Touch <[e-mail]>]

On 6/11/2014 8:09 AM, Stephen Farrell wrote:
>
>
> On 11/06/14 15:54, Joe Touch wrote:
>>
>>
>> On 6/7/2014 6:20 AM, Stephen Farrell wrote:
>>> Yes, source addresses leak information that affects privacy. But
>>> we do not have a practical way to mitigate that. So therefore
>>> BCP188 does not call for doing stupid stuff, nor for new laws of
>>> physics (unlike -04 of the draft we're discussing;-)
>>
>> Again, BCP188 does not *call* for doing anything. There are no SHOULD-
>> or MUST- level requirements in that doc. Let's please not wave it in the
>> air as if there are.
>
> I don't buy that argument at all and didn't wave anything anywhere.
>
> BCP188 very clearly says:
>
>     Pervasive monitoring is a technical attack that should be mitigated
>     in the design of IETF protocols, where possible.
>
> and
>
>     Those developing IETF specifications need to be able to describe how
>     they have considered PM, and, if the attack is relevant to the work
>     to be published, be able to justify related design decisions.  This
>     does not mean a new "pervasive monitoring considerations" section is
>     needed in IETF documentation.  It means that, if asked, there needs
>     to be a good answer to the question "Is pervasive monitoring relevant
>     to this work and if so, how has it been considered?"
>
> Reverting to RFC2119-keyword-lawyering is not IMO credible here.

That's what RFC2119 is for and how we interpret BCPs.

The doc goes out of its way - as you note - to include wiggle phrases 
like "where possible" and by not requiring a new considerations section.

Yes, it's fine to discuss it here, and I've already outlined a way 
forward - with the caveat that my view is "do no harm", not necessarily 
"fix the lack of privacy already inherent in the Internet" - at least in 
this doc.

Joe