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@xxxxxxxx] On Behalf Of Stephen Farrell [stephen.farrell@xxxxxxxxx] 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.