On Wed, Feb 22, 2012 at 2:23 PM, Vesna Manojlovic <BECHA@ripe.net> wrote:
Dear all,
https://labs.ripe.net/Members/**kistel/ripestat-demo-s2e02<https://labs.ripe.net/Members/kistel/ripestat-demo-s2e02> http://www.youtube.com/watch?**v=WnQyqtHB9t4&<http://www.youtube.com/watch?v=WnQyqtHB9t4&>
now that you had time to read the article and see the video, here are the questions I'd like to see answered:
1. Have you embedded one of our widgets on your web page? Which one? How is it performing? Please let us know. We would like to collect "success stories"
Not yet. Planning to use them to give a short overview of our resources as a control panel for not so technical users. These widgets will be included in the daily, early morning monitoring check by our team.
2. Which one of the new features would you like to see the most in the next, extended version of the "Reverse DNS" view? a) hosts (information from CAIDA about the hosts within this prefix); b) lameness (checking for the "lameness" of nameservers,) c) IPv6 RIPEness d) DNSSEC data
All of them are interesting and useful, but I find lameness something to be fixed ASAP, and so would like to see it implemented first. Embedded green/red widget for DNS lameness can be easily understood by non-technical users, and it certainly must be fixed from the technical point of view. Since you mentioned what we would like to see implemented, I'd like to share a couple of ideas: 1) Less common metadata on ASNs: is it a transtit, stub or multihomed AS? You can infer that from the data, but it'd be more convenient if it was already tagged in the database and could be used in statistical/research queries and visualizations 2) CIDR/BGP UPDATE report like data of ASNs: deaggregation factor, updates, updates/prefix...
3. Do you have feedback about our "special resources" list? https://stat.ripe.net/query/**widget?widget=global-networks<https://stat.ripe.net/query/widget?widget=global-networks>
Actually, I do. Look at this JSON sample output: { "desc": null, "name": "unallocated ASNs", "resources": "AS458752 - AS4294967294", "tags": "" }, { "desc": "This block is allocated to APNIC by IANA.", "name": "APNIC IPv4 Address Space", "resources": "1.0.0.0/8", "tags": "" }, Both prefixes and ASNs are special resources, but they are different special resources. Its perfectly usable right now, but maybe a "resource-type: ASN|prefix" could be handy for some users of the API.
4. (bonus question) What type of graphical representation / visualization of RIPE Database objects would you like to see?
I thought about this before too. How about the aut-num objects and their RPSL bits? This data lends itself to a graph plot with the info encoded in the nodes and edges. When iterating on RIPEStat development, you could build the same plot from actual BGP data and see if it matches. Right now you are telling us when our announced BGP prefixes are not registered in the database, via the prefix routing consistency check. I guess you do this to remind us we are not following "the best practice". Maybe you could extend that word of advice to the routing policy specification of each AS.
You can also find us as #ripestat on Twitter, to follow announcements or ask questions.
Thanks for your input!
Thanks for the tools!
We appreciate your feedback and we adjust RIPEstat tool based on your needs and comments. Your ideas will help us prioritise new features.
One last thing: still, some people find bgp.he.net more fast and efficient. I think if you want to grow your userbase, you could analyze how they represent their data (overall layout, which/how resources are ploted...) and what ideas you can take from it to improve RIPEStat. Currently RIPEStat is a flat website that may take a while to load for some users. We can see the difference in performance since RIPEStat left its original VM, but bgp.he.net offers a faster user experience. Be it because they serve static or cached content, but it _is_ faster. What if instead of loading all the widgets, you just loaded logical subsets of them, grouped under the same "tab" of the website. First tab, basic info we all need. Subsequent tabs, more specifics you chose to dig into. Browsing experience may improve due to shorter load times, and RIPE Access users may benefit from this by creating their own custom tabs/views. Oh I forgot... once RIPE Access is enabled, please allow us to bookmark specific queries! :-)
Regards, Vesna
Thanks for the effort you are putting into RIPEStat and Atlas, all the hard work is giving results already. Best,
-- Vesna Manojlovic BECHA@ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net