On 01/27/2016 07:10 AM, Harald Alvestrand wrote: > This one surprised me a bit. > > Asking for blockage of an ind-sub is a fairly unusual thing. > I kind of expected to find in the IESG review would explain the nature > of the conflict, but the totality of the review is: > > "The IESG has concluded that this document violates IETF procedures about > pervasive monitoring (RFC 7258) and should therefore not be published > without IETF review and IESG approval. This work is related to IETF work > done in the INTAREA WG." > > The procedures I could find described in RFC 7258 are these: > > 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?" > > In particular, architectural decisions, including which existing > technology is reused, may significantly impact the vulnerability of a > protocol to PM. Those developing IETF specifications therefore need > to consider mitigating PM when making architectural decisions. > Getting adequate, early review of architectural decisions including > whether appropriate mitigation of PM can be made is important. > Revisiting these architectural decisions late in the process is very > costly. > > The draft in question does have a "Pervasive Monitoring Considerations", > so the issue has certainly been considered by the authors. One may agree > or disagree with their conclusions, but one can't argue that they didn't > consider it. I agree with Harald. Besides, if this proposal is knocked down for including a host_id option (which, skimming through the I-D doesn't seem to be some global identifier) in flows that traverse a nat, then I wonder: What would be the take on deploying IPv6 on such network, since that would obviously reveal host identity even more than a host_id option? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492