Both perpass and RFC2804 are political reactions to the public environment.
To characterize either of them as technically motivated is disingenuous.
Neither outlines
a technical approach.
From RFC2804:
These questions are believed to be irrelevant to the policy outlined
in this memo.
See? policy.
From draft-farrell-perpass-attack-03:
The technical plenary of the November 2013 IETF meeting
[IETF88Plenary] discussed pervasive monitoring (or surveillance)
which requires the monitoring party to take actions that are
indistinguishable from an attack on Internet communications.
Participants at that meeting therefore expressed strong agreement
that this was an attack that should be mitigated where possible via
the design of protocols that make pervasive monitoring significantly
more expensive or infeasible. This Best Current Practice (BCP, see
[RFC2026] Section 5) formally documents that consensus.
again, policy, pure and simple.
The usual claim that the IETF is a technical organisation that doesn't do
politicics
is itself a disingenuous political position...
The public policy angle is the prime motivation for the existence of these
documents. It is not a side-effect.
Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Stephen Farrell
[stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Sent: 06 January 2014 22:45
To: John Curran; Phillip Hallam-Baker
Cc: IETF Discussion Mailing List
Subject: Re: Split the IANA functions?
On 01/06/2014 08:51 PM, John Curran wrote:
What happens when the IETF makes a decision that particular "public policy"
requirements
are _to be considered_ (perpass), or specifically _not to be considered_ (RFC
2804) in protocol
development?
I think that's a mis-characterisation. IMO both of those are cases
where there are sound technical reasons for the IETF to do, or not
do, work. Yes, those have impacts, but the public policy angle (if
that's the right term) is a side-effect and is not the reason for
the decision.
S.