Some features have already been requested before, to better manage this, you can register on the Wiki and cast your vote there:
http://wiki.mikrotik.com/wiki/MikroTik_RouterOS/Feature_Requests
Of course, in addition, it would be great if you also posted a message here, explaining why you need that particular feature. And as usual - search before you post, maybe a topic exists already.
Features ? ROS got more than enough already for the Class it is in.
http://forum.mikrotik.com/t/mikrotik-ideabank-or-brainstorm/39636/1 feature request for feature request itself 
A super cool thing would be for the Mikrotik to detect what it’s lacking, based on how much fannying around the admin user is doing (and how often) and automatically send that info to MT so they can automatically include a new feature to do whatever the admin was doing all that time.
Auto feature request basically.
so your asking for A.I? Dont you have something better to do than troll a router manufactures forum?
Replace racoon with openswan. With racoon ipsec on mikrotik are poooooooor.
something better to do than troll a router manufactures forum?
Is there anything better ?
Maybe i need to get out more.
I’m not sure it’s the implementation. Some algorithms seem to perform poorly, though. Look at this: http://forum.mikrotik.com/t/mk-v5-rc1-bug-torch/40978/15
After DHCPv6 and finishing the other ipv6 features Mikrotik need to give IPSEC on their platform some serious love. Virtual Tunnel Interface PLEASE!!! We need this for meshed IPSEC tunnels with OSPF, it allows a true “shortest path” to the site the traffic is destined for, which is quite important for VoIP.
As an added bonus, it makes IPSEC much simpler as you do not need to have policies to encrypt the traffic, just create a route via the VTI and bingo the policy is automatically created.
This is the 3rd most popular feature request on http://wiki.mikrotik.com/wiki/MikroTik_RouterOS/Feature_Requests with 12 votes.
Also, as I have suggested before on the forums and via email to support (Ticket#2010072966000194), replacing VRRP with true High Availability (config sync, session failover) would be fantastic.
Normis,
Does this mean that Mikrotik will commit to implement the most x requested features or do we just filll in that page for fun ?
no, the list does not influence our priorities, just gives us ideas about what people want to see.
Hmm, isn’t this method quite hard to read ? what do you think of this : http://feedback.unity3d.com/forums/15792-unity , user can discuss the importance of such request, admin/mod can add status(under review, completed) of the feature, i think it just easy for mikrotik to use this as doesn’t need to cross references each discussion into 1 which will be big 1 thread, just quite hard to track imho,
user also locked at 10 points max for each account, and max 3 points vote for each feature request, sure it’s easy to create clone account but i think it’s possible to prevent this by verified customer before registration with specific mikrotik key or other verification method, just my opinion, regards.
The service provider for this feature is : http://uservoice.com
Heh, Next you’ll want a bug tracker like almost every other vendor out there has where we can submit bugs and have other users confirm it and have MT update us on it!
Hello,
Would it be possible to reset the counters individually in the Interface list?
The only way i can do this at the moment is to reboot the mikrotik device…
Thanks.
Here is what I just created under existing features:
Add configuration options to ping-watchdog to specify how many pings should be performed and how far apart before triggering a reboot. This can help avoid false positives when another node along the route reboots and doesn’t get routing back up in time to satisfy the ping watchdog, and will let people taylor the ping watchdog to their needs (reboot immediately if things look broke, or, wait a little while and see if things work out).
– xxiii 17:04, 26 October 2010 (UTC)
We have a lot of routers in remote locations, and use the ping watchdog to reboot them as a last resort in case we can’t mac-telnet to them from a neighbor or whatever, or a human can’t get to them in a reasonable time to figure out whats wrong, but we would prefer to be able to specify that they wait 10 or 15 minutes before rebooting themselves, or at least 4 minutes, so an upstream router can finish rebooting before triggering a cascade of reboots, or a reroute can occur whose detection and implementation didn’t quite occur fast enough for the current ping watchdog.
The current settings let you delay when the watchdog starts, but give you no control once its running.
We’d like something like:
wait 5 minutes.
send a burst of 3 pings, 2 seconds apart, if all lost, wait 5 minutes.
send another burst of 3 pings, if all lost, wait 5 minutes,
send another burst of 3 pings, if all lost, reboot.
Any successful ping response restarts from the beginning. (or perhaps if at least 2 of the 3 are successful or something like that).
Just added this to the wiki…
I would like to see some more options when dealing with ordered lists. Particularly when new rules pop up at the bottom of a firewall config which is several hundred items, it is extremely time consuming to position them where they need to be.
Would be good if there could be additional options (and hotkeys) for items in ordered lists such as: send to top, send to bottom, up one, down one, up page & down page
I have also put in a request to throttle MAC addresses making excessive PPPoE connection attempts to prevent the router or RADIUS server from being overloaded.
I am just saying , look back at this thread couple months from now on, it will filled with many post from many different kind of feature request, example post 11-20 discussing about feature request A, post 21-35 discussing about Feature request D, in the post 36 a new user starting again discussing about feature request A, won’t be a mess? hard to track which user talk which topic, sure won’t be problem for 1-5 point of feature request, what if the feature request growing into 30+ 
, could be 1 giant huge thread with 1000 post on it, imagine you haven’t visit mikrotik forum for couple months and spending time to thread 1000 post 
, search would be useful but it’s not helpful for non-narrative jumping feature request discussion, imho it just not efficient.
Or another solution would be make a sticky thread in this forum with links into specific feature request dicussion, i mean for each feature request it has it’s own thread but the thread will have a special tag like “[Feature-Request]Topic/Thread Name”, so in that thread it would have many links to the thread, and in the wiki of course mentioned about this indexing thread. The downside of this solution is atleast mikrotik forum moderator need spend time to edit the indexing thread and manage(merge,move,delete) the new user thread about feature request, while the uservoice or other service alike is all automatic, it’s a offshore hosting, separated from forum user database, the downside just user need to re-register on that uservoice.
No i don’t want that bugzilla like bug indexing, it just too complicated for me and so far mikrotik just works excellence in my simple setup but i don’t know about other expert/senior user who might need this. Easiest solution for tracking bug would like i’ve said above, special tagging or sub-forum , the downside still the same, need extra work from mod to manage new thread by lazy people who lazy to search.
I don’t think this particular post is meant to be a discussion on feature requests particular, but a notice of where people may find the place to go and submit requests (aka. the Wiki page).