That's easy to say for someone who knows absolutely 0 about someone, i don't drive a car and when i do its a 2001, i don't care what u have or what you're ripping, I'm not your free QA tester, if its not open source or if i cant read the code that it has under the hood and change it as i please or fork it and make my own version of it, i don't care what u have or what you're making or what you're even thinking of.
You can keep it to yourself.
Ownest question, then why so much effort to reply in this tread? I want to keep it possitive 
want to help people that wants help, you don`t need or want help, then fine, but leave us alone then. thank you.
Hell no that we will obfuscate, not our style! we where just making a feature for you guys ready, will be posting in seconds as the configurator is back online again. (Change went very smooth )
A roadmap you can vote on, and a form for requests
Two pages went live today, so you can see what is planned for the configurator and have a say in the order it gets built.
What is coming: https://extremehosting.nl/configurator/en/roadmap/
Fifteen items, ordered by votes. Click the arrow to vote. No account, no sign-up, nothing to install. One vote per browser and network, which is good enough to order a list and deliberately no better than that.
Three of them came straight out of this thread and are credited to whoever raised them:
- Provider presets (KPN, Ziggo, Odido, Telekom, Swisscom, Free): pick your ISP and the WAN VLAN tag, PPPoE quirks and IPTV settings are filled in for you. Planned, not built, so please do not expect it this week.
- Topology for multi-device sites: tell the tool which port faces which device instead of it assuming the first one. Asked for by roe1974 and Buckeye.
- Verify the Wi-Fi 7 band settings on real hardware: rextended's question about whether
band=5ghz-berestricts the radio to that standard is still open, and the answer decides what the tool ought to emit.
The rest are things like diffing against a running /export, generating a rollback script next to the config, choosing which RouterOS version to target, SwOS support, CHR and x86, and confirming the twenty models whose interface names have never been checked on real hardware. That last one needs people who own the boxes far more than it needs code.
Requests and reports: https://extremehosting.nl/configurator/en/feedback/
If your idea is not on the list, this is what puts it there, so other people can vote for it too. Same deal, no account.
Security issues do not go here. Use https://extremehosting.nl/en/melden / https://extremehosting.nl/melden so they reach the right people.
We keep answering here. The form is for anything you want tracked and voted on; this thread stays the place for discussion, and reports posted here get the same attention they always have.
P.s. we will be adding more to that list, so many ideas you guys have we also have and more!
It would be nice if the page for reporting security issues was available in English as well, i.e https://extremehosting.nl/melden
Just press EN in the top (Added the EN link to the post as well)
Okay, but that option (EN) seems to disappear when using Safari on iPhone 
lol, well that is going on the bug list.
There are some good ideas in the list. It seems that you have though about this in depth.
The one "Save a configuration as a file and open it again later" would be really useful, and would work along with some of the other items. It would also be able to save the password, and perhaps certs and users, that aren't preserved in the export.
Along with a network diagram and handover sheet (it wasn't clear what all would be included in the "handover sheet" and if a diagram would be part), it would make "resetting context" after a period of time a lot easier.
How do you plan to store the saved configuration? Will it be device specific, or generic? In other words if you had a saved site with an RB3011 and you wanted to replace with an RB4011 or RB5009, what would be the most straight forward way to do so? If there were some "intermediate language" like YAML that could be read and edited (vs a binary blob), which is used by the script generator, then you could regen when the "script generation" engine was updated, or you were targeting a different ROS version, or even a different device.
Another question. What is best way to model a device from another vendor (that you don't care to generated configurations for). For example a connection to a cisco switch or juniper router or even an OpenWrt router? Just have a stub "trunk port" that has no connection? Or just pick a MikroTik device with similar capabilities and use the generated script as "documentation". Here's another place where a "generic" description in something like YAML would possibly make it easier.
When searching for generic router config I found YANG (Openconfig). And this 2016 thread NETCONF / YANG that didn't seem to go anywhere.
Only another idea, as an option, adding somewhere in the wizard the possibility to make an Offbridge port:
Once and for all COMPLETE Offbridge Port setup
could be useful.
As seen in that thread, there are two main ways to achieve that, the first without making use of any VLAN (post #1) and one leveraging on VLAN (post #2)
I would go even further making a selection in Wizard, a checkbox choice like:
- This is the first time I am configuring a Mikrotik, please make it as foolproof as possible
- No worries, I (almost) know what I am doing, I have been already locked down n times and know how to avoid it.
Do you consider the list of interfaces per device to be protected by copyright?
The reason I ask is actually do publish open-source MikroTik RouterOS tools. I do not have use for the HTML or JS, but the one piece of data you have is a list of interfaces/radios per device. Perhaps this is generated from MikroTik's own catalog, IDK.
For example, if I copied your list of interfaces into my tikoci/rosetta project's own device catalog, would you sue me ?
e.g.
CCR2004-16G-2S+: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, ether9, ether10, ether11, ether12, ether13, ether14, ether15, ether16, sfp-sfpplus1, sfp-sfpplus2
...
L009UiGS-2HaxD-IN: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, sfp1, wifi1
L009UiGS-RM: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, sfp1
RB912R-2nD-LTm&EC200A-EU: ether1, wlan1
RB911G-2HPnD-12S: ether1, wlan1
RB1100x4: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, ether9, ether10, ether11, ether12, ether13
RB4011iGS+5HacQ2HnD-IN: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, ether9, ether10, sfp-sfpplus1, wlan1, wlan2
RB4011iGS+RM: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, ether9, ether10, sfp-sfpplus1
RB450Gx4: ether1, ether2, ether3, ether4, ether5
RB5009UG+S+IN: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, sfp-sfpplus1
RB5009UPr+S+IN: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, sfp-sfpplus1
RB5009UPr+S+OUT: ether1, ether2, ether3, ether4, ether5, ether6, ether7, ether8, sfp-sfpplus1
RDS2216-2XG-4S+4XS-2XQ: ether1, ether2, sfp-sfpplus1, sfp-sfpplus2, sfp-sfpplus3, sfp-sfpplus4, sfp28-1, sfp28-2, sfp28-3, sfp28-4, qsfp28-1-1, qsfp28-2-1
For AI tools and/or offline LSP server, this one detail that cannot be gleaned from docs, and/or be more work to collect the names of the default interfaces. So it actually be useful to have in rosetta's database, so it could surface as part of device's details (and then agent can know what value interface= could be without a live connection to actual router).
So would you object to the borrowing of this list?
IANAL, (thankfully) but I doubt that a list of interfaces is in any way different from a list of ingredients (and this is not protected nor protectable by copyright).
Amm0,
Thank you for the kind words about the configurator, and for being open about what you are building. I would like to be equally open with you, because I would much rather have this conversation properly now than have it become something unpleasant later.
Where the device data comes from
The catalogue behind the tool is not lifted from the MikroTik documentation, which is exactly why you could not find much of it there. It is the result of several of our engineers working with MikroTik hardware over a number of years. As a deliberate assignment, to make the tool something we could stand behind, they recorded what they found on real equipment as they went: which interface names a board actually presents, which switch chips need the switch menu rather than bridge VLAN filtering, how the radios are genuinely laid out, and which models we still will not vouch for, etc,etc,etc Those are judgements paid for in engineering hours, and a good number of them exist nowhere else.
That layer is the part we care about, and it is the part that makes the tool worth using.
About the automated retrieval
Our logs show the catalogue being pulled repeatedly by an automated client rather than by a browser. If that was you, I would simply ask you to ask us next time. We are not difficult to talk to and a short message would have been answered the same day. Taking it quietly is the one route that forces us to be formal about it, and I do not think either of us wants that.
What I would rather propose
We run several services where customers formally request a licence for data, and this is not normally one of them. I am going to make an exception, because I like what you are doing and I would rather see it built properly than watch it stall.
You are welcome to submit a request here:
https://extremehosting.nl/en/License-Request
Tell us what you need, what it is for, and how you intend to credit it. We will evaluate it seriously and come back to you.
One thing to be clear about in the meantime
Until a licence request is completed and approved, please do not build on data taken from our systems. If you assemble your own catalogue from the MikroTik documentation, or from hardware you own, that is entirely your work and we have no claim on it whatsoever. Data that came off our servers is a different matter, and we would treat that as a breach.
I would far rather send you an approval than file a takedown against your project. Put the request in and let us see what we can do. The other path involves your host and the platform you publish on, and I would much prefer not to go there.
@jaclaz See my reply above. Nobody is claiming the ingredients. Port counts and radio bands are published facts and anyone can go and read them.
What took years is the recipe. Twenty of the 136 models in that list carry a flag saying we could not confirm their interface names on real hardware, so the tool warns you. Ten are marked as needing the switch menu instead of bridge VLAN filtering, which is a judgement about switch chip families, not something you look up. The role each device is sorted into is our vocabulary, not MikroTik's. Several radio layouts are corrected against what we found on the bench.
None of that is in a datasheet. It is what makes the output paste cleanly instead of locking you out of your router, and it is the part that cost us the hours.
We invested a lot into this tool.
Which I don't doubt, I am doubting that - even if it costed long hours of work - the list of interfaces is protected or protectable by copyright laws.
Anyway it is clearly an SEP:
https://en.wikipedia.org/wiki/Somebody_else's_problem
sorry for the intermission.
It is the whole collection, and it came straight off our servers with curl. If he had gone to the help docs and built his own, I couldn't care less. That is not what happened here. He downloaded and extracted our data, and that is the part I mind. Ask first, then act. That is my motto. (It is also showing a little bit of respect, in an earlier post we already said it is not opensource, and then the extraction.....)
As noted, it's not actually copyrightable. I'm not sure fetching 3 times is abuse: https://extremehosting.nl/configurator/en/mikrotik/devices.json — which I checked against a list of I have of device data I already build and publish. I have not included the data anywhere – just seeing how complete and accurate the data was (and really only the interface and radio details). Given your objections, I don't plan to use your data.
But if you're claiming MikroTik data is your data to copyright. That's not right nor the law, or at least in United States where I live.
Here in the US, we have a some latin for this situation from US Supreme Court that long settled the issue here:
The sine qua non of copyright is originality. To qualify for copyright protection, a work must be original to the author. [...] It may seem unfair that much of the fruit of the compiler's labor may be used by others without compensation. As Justice Brennan has correctly observed, however, this is not "some unforeseen byproduct of a statutory scheme." It is, rather, "the essence of copyright," and a constitutional requirement. The primary objective of copyright is not to reward the labor of authors, but "[t]o promote the Progress of Science and useful Arts." Art. I, § 8, cl. 8. To this end, copyright assures authors the right to their original expression, but encourages others to build freely upon the ideas and information conveyed by a work.
— Feist Publications, Inc. v. Rural Tel. Serv. Co., 499 U.S. 340 (1991)
I want to be clear about our position, because I think it keeps getting missed.
We published this tool to help the community, not to start a legal dispute. That was never our intention, and it still is not.
I have put the tool into maintenance mode so we can reconsider whether we publish it at all, and if so, in what form. If we decide it is worth bringing back online, we will look carefully at how and why.
We would appreciate the same respect in this discussion that we have tried to show. We are disappointed that it came to this.
I was not picking a fight here. And thought this would clarify things:
I think your objection is silly, but I still respected it. And you're still welcome to use rosetta's DB which has a bunch of additional device details, like speed test and block diagrams. The only thing we don't catalog that you did/do was default-name of interfaces.