Remi Locherer <[email protected]> wrote: > On Sun, Jan 12, 2020 at 04:18:26PM +0100, Claudio Jeker wrote: > > On Sun, Jan 12, 2020 at 03:46:15PM +0100, Remi Locherer wrote: > > > On Wed, Jan 08, 2020 at 01:13:45PM +0100, Denis Fondras wrote: > > > > On Wed, Jan 08, 2020 at 09:14:48AM +0100, Remi Locherer wrote: > > > > > > I have a diff to allow parameters after interface or area > > > > > > definition. > > > > > > Not sure if we want to do that though. > > > > > > > > > > I would appreciate that! ;-) > > > > > > > > > > > > > The ospfd diff needs some more work. Crypt authentication handling is > > > > not > > > > perfect. > > > > > > This works fine for me and the diff reads good. I tested ospfd and ospf6d. > > > Also the crypt options for ospfd worked fine. > > > > > > ok remi@ > > > > Currently all daemons behave the same way and inherit at the moment of > > creation. Having this behave different between daemons is confusing. > > At least ospfd and bgpd should behave the same. Not saying that the > > current behaviour is great. > > I think in the case of ospfd the way auth-md is handled by this diff is > > not comparable with the behaviour of the other settings. > > I agree. But that should not stop us improving one program before the > other ones. > > > > > area 0.0.0.0 { > > hello-interval 10 > > auth-md 1 foo > > > > interface em0 > > > > hello-interval 20 > > auth-md 1 bar > > auth-md 2 foofoo > > > > interface em1 { > > auth-md 3 barbar > > } > > > > hello-interval 30 > > auth-md 1 bay > > auth-md 2 foobar > > } > > > > What values for hello-interval and auth-md should be set on em0 and em1? > > > > To me it looks natural if the latest value per level is used. With your > example that would be: > > em0: > - auth-md 1 "bay" > - auth-md 2 "foobar" > - hello-interval 30 > > em1: > - auth-md 1 "bay" > - auth-md 2 "foobar" > - auth-md 3 "barbar" > - hello-interval 30 > > In my testing this is the result of the diff from Denis. (I modified > printconf.c to print the keys to see the results).
I think that is very dangerous. In some other daemons it could be disastrous. > Another option would be to make it an error specifying the same option > more than once at the same level. I think that will be the easier solution. The approach of "collect all the root info first, then apply to the children aftwards" will be difficult to apply to all our domain-specific-grammer-daemons.
