On 13/11/17 21:52, Job Snijders wrote:
On Mon, Nov 13, 2017 at 12:16 PM, Mark Prior <mrp@mrp.net> wrote:
On 13/11/17 21:36, Job Snijders wrote:
On Mon, Nov 13, 2017 at 12:01 PM, Mark Prior <mrp@mrp.net> wrote:
In this particular case I would suggest that you do want the tool to complain rather than ignore the new rp-attribute.
Why would you break backwards compatibility?
It's only broken if you include a large community formatted string in your policy and your tool doesn't support it. In that case I would like the script to break rather than load a broken configuration to a router that potentially causes chaos.
OK, but what about the tools from other people/organisations that parse your autnum object?
I'm not sure why you ignore the recommendation "When changing the dictionary, full compatibility should be maintained." without offering any arguments on what the benefits for doing so are.
I am concerned about how a tool that doesn't understand them copes. If a clause using large communities is just ignored then it might change a restrictive export policy into an ANY without any warning. If that was likely I would prefer it to break so I would know and could fix the policy and/or tool. As for breaking other people's interpretation of your policy that is also probably a good thing for the same reason. I would be interested to know about a use case for people parsing other people's policy objects. Mark.