odd that your response to a request for a technical problem statement is a request to form a private clique and a pre-made value judgement on the meaning that nobody excspt clique groupies will want to join. imiho, very few social problems have technical solutions, and vice versa.
i've had some dealings with various readers of the nanog mailing list which have taught me quite a bit about the quality of lurker we get here (and for that matter the quality of active participant). don't blame me for throwing a party but also checking credentials at the door. there are people now reading these words who are not exactly polite members of internet society.
do i correctly glean that you are want peering agreements to require that peers not allow packets with spoofed source addresses? this would not seem too socially unreasonable as long as we know that it is not technically unreasonable.
i think you're assuming a lot. it's not socially reasonable. there are US network owners whose peering policies are set based on fear of the justice department rather than on any solid economic or engineering basis. expecting these people to refuse to peer with anyone for reasons similar to "you're not technically capable of operating a network that doesn't emit spoofage" is actually the crux of this whole matter, and is my real interest in holding discussions about it.
to test the latter, could we please enumerate o the technical means for a peer to achieve this, e.g. i suspect that 2827 is one piece o how thoroughly we think they could achieve this o how we can test that it has been achieved
my simple-minded approach to thinking about this is about interface ingress filtering. an interface or subinterface or link or whatever you want to call it on one of your routers is ingressing one of three kinds of traffic: 1. from a customer (not your network) 2. from a peer (not your network) 3. from some other router you own if all your routers handle #1 and #2 consistently and well, then #3 doesn't matter. (filtering by trusted proxy.) if you limit each #1 to a specific set of source addresses (which limits performance but CAN be done, even on very slow, or very fast, and/or very dense connections), and if by peering agreement you limit #2 (back to filtering by trusted proxy) then you're DONE implementing it (randy's first point, above). making #2 transitive is the big problem. let's say that woody's got some really old peering agreement in place with some provider who doesn't mind leaving the session up but would almost certainly not be willing/able to set it up afresh starting today. will woody drop peering with that provider if they refuse to agree to limit spoofage? Certainly Not. probably some very large/old networks could simply drag their feet about agreeing to limit their spoofage, and thus transitively make all "upgraded" peering agreements thereby toothless. (would i drop peering with woody just because he refused to drop it with some old/large network who refused to control their spoofage emission? Probably Not.) the angry teenager with a $300 openbsd machine apparently has nothing to fear from us. but let's discuss it. privately, where the various angry and bored twentysomethings with $3000 openbsd machines don't get to listen. (though if i can get a signed pgp key from some of them, that could be worth something.)