So, the presentation today has resulted in a very informative conversation with several people, which I would like to capture here. Others can contribute or make more accurate statements from my summation. This is my summation of what I learned today. I welcome feedback or corrections Firstly, its become clear we have a problem. post final /8, there is a larger set of people entering routing with a prefix, and not the AS holder. Since in the past most routed addresses came from AS holders, the 'both must authorise' rule tended to simplify to the same maintainer, and mnt-lower mechanisms worked as well. Now, there is no scoping of the prefix, its unrelated to the AS holder and we are back with two independent authorities needing to be seen. APNIC has a year more traction behind this trend, quite apart from a lower penetration of individual AS holding, but I suspect this problem will increase in the RIPE region over time. It is also clear that its far too early to walk to solutions. The ideas I presented in the WG meeting were premature, and have clear risks to the consumers of route:/route6: objects for creating their origination. It is possible in time, WHOIS tagging can help here, but thats future. Although there will continue to be circumstances where hostmasters have to user override authorities to make changes in WHOIS, there was no sense that a 'reply to block' permission model was acceptable. Wilfred sensed that this inverted many established practices, and was not consensual as he understood it. I do not think the hostmasters will feel comfortable with comments which go to good and bad actors in routing, so I don't expect we will be seeing some of the 'if address holders cannot get routed, change ISP' messages in the reply. Its coming between RIR members, its not a good fit for hostmaster communications. There is no harm, and much potential benefit, in encouraging address holders to make the ROA they need to represent this information. Since IRR tools exist which can consume ROA, it offers a chance to have filters raised, in a clean manner, respecting RPKI data 'first class' rather than via synthesised objects. There is no harm and considerable benefit in making people aware of newer IRR code, and encouraging uptake. filters could and should be defined from ROA and from IRR. Both are sources of information about origination. ROA have strong cryptography behind their assertion. I have also been reminded that synthesising objects risks creating some new information into a situation where absence of data can be either "permit all" or "permit none" and the implications of creating a specific object in this domain can change the outcome from "all is permitted" to "only this is permitted" without meaning to do that. I have been reminded that rfc2725 authorisation and authentication is not necessarily deployed outside of the RIR/NIR. We may need to remind people that IRR assertions made in the over 30 IRR deployed worldwide have different basis for justifying that routing assertion. Maybe we need a better understanding of how these systems work, singly and together. Finally, It has been observed that we might be exploring a misunderstanding. The question has been raised about "who uses public IRR to configure their route announcement?" -A sense that you risked more than just this problem, if you use public IRR to determine your origination. Most people are believed to use a private internal IRR to do this. It would be useful to understand the public route:/route6 objects, because it is possible we are confusing a requirement for the aut-num to authorise origination, and the use of public IRR to register filter rules. Same object, different IRR? I think the risk to people who configure origination is real. I don't want to expose that risk. I would love to understand better the 211,000 objects in RIPE, and the smaller set in APNIC, facing this problem. Are they actually being used to configure origination by anyone? Are they reflected into private IRR, or somehow used as input to filter over private IRR? I expect to take the discussion held in the meeting back to the APNIC hostmasters who asked me to explore this space. My sense right now, is that we don't have a community wide agreement of how to solve this problem, but we do have a problem. Its progress, small steps. When I was asked to raise this issue, there were two goals. One was to fix a problem for new entrants in address management. The other was to explore a re-engagement with the community. I can't fix the first problem, but its nice to feel we've got to a place with the second, and I hope the discussion is as useful for you list members, as it is for me. cheers -george