-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/2013 17:17, Marek Vavrusa wrote: Hi Marek, I don't any problem here. I think enforcing quotes for strings is a good thing. If the config parser find unquoted strings, it should generate an error and fail to parse the config. Ok, thanks :) I don't think there's any urgency in fixing it, because this bug is only triggered in the rare case of reconfiguring and changing the NSID. Usually, the NSID, once set, is static. In our case, it will even be just "nsid on;". So a fix in the next minor release will be fine. Regards, Anand

Hi Marek, Dne 6.8.2013 17:17, Marek Vavrusa napsal(a): Do you mean that config file should look like this? ---cut--- remotes { "slave0" { address 203.0.113.1@53; } "slave1" { address 198.51.100.1@53; } } zones { "example.com" { file "/etc/knot/example.com.zone"; xfr-out "slave0", "slave1"; notify-out "slave0", "slave1"; } } ---cut--- In that case, I would vote for keeping unquoted strings allowed. However, if quoting would be required only in possibly ambiguos fields, I would have no problem with that. Cheers, Ondřej Caletka

That has a simple solution - keep unquoted strings where you use strings as identifiers/tokens and use quoted strings if it's a value. Ondřej Surý

I would say that IP addresses are also identifier and I would let them unquoted. The only problem I could think of is when you create token in form of IP address, e.g. interface { 10.0.0.1 { address 10.0.0.1; } } remotes { 10.0.0.10 { address 10.0.0.10; via 10.0.0.1; } } Is is even possible to do so? O. On 8. 8. 2013, at 11:20, Marek Vavruša <marek.vavrusa(a)nic.cz> wrote: -- Ondřej Surý -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------

On Aug 8, 2013, at 12:56 , Marek Vavruša wrote: So I agree this seems like a reasonable compromise. However, as we're discussing parsing the conf file I have two more observations: 1. If I declare a TISG key without the quotes: keys { foo. hmac-sha256 secret; } Then checkconf claims that the config is valid, but starting the server will lead to a segmentation fault when trying to do the TSIG protected zone transfer. I'm aware that I should use quotes, but checkconf didn't catch that (and regardless of format, segmentation faults are not cool). 2. I'm a bit confused regarding the syntax for "lists": remotes { foo { address ...; port ...; } bar { address ...; port ...; } } To me, the {...} after "foo" is a list. The elements of this list are terminated by a ";". This is all fine and a standard notation known from many other places. However, what about the {...} after "remotes", isn't that also a list (of remotes)? If so, why are the elements not terminated by a ";"? And it gets worse, see groups: groups { self { me, myself } } I think that the {...} after "self" is a list, but now we have a third notation: comma as a separator, instead of semicolon as a terminator, (or space as a separator, as in the "remotes" case). Am I missing anything here or is this really a bit inconsistent? Regards, Johan

Hi Marek, On Aug 9, 2013, at 10:51 , Marek Vavruša wrote: Exactly. And having spent some time on figuring out the problem I had to beat myself up to find that it was exactly the issue that we were at the same time discussing by email, i.e. pros and cons of explicit quotation of strings. Well, it is that because you parse it that way, not because it has to be. And looking at this from the perspective of the user, 99 out of 100 users will look at it as a list. I fully agree with this. I do understand the backwards compatibility issue. But the way I look at it, Knot-DNS right now has a user base of N... your expectation and hope is of course that in two years time the user base will be 100 x N, or something like that. Given that I think it is very important to sort out and fix any inconsistencies in the config language as quickly as possible, because the longer you wait, the more users you'll confuse. Good start. I couldn't add to that page so I'll continue to comment here. You have thought more about this than I have ;-) I'll ponder my experiences for a bit to see if I can come up with anything more that I find inconsistent, but I think you got most of it. Well, as we're really trying to find stuff... the keys declaration: keys { foo.key hmac-sha256 "secret"; bar.foo hmac-md5 "turkey"; } while structurally a list (good!) with ";" terminators (good!) is still syntactically different from the other constructs, like remotes, etc. Perhaps keys { foo.key { hmac-sha256; "secret"; } bar.foo { hmac-md5; "turkey"; } } or even (assuming a future conversion to ";"-terminated lists: keys { foo.key { hmac-sha256; "secret"; }; bar.foo { hmac-md5; "turkey"; }; } while slightly more characters, would still be more consistent with the rest. I.e. I'm basically ok with the keys as they are, except that the notation for keys is once again different from other constructs. I.e. there are a few different alternatives for list syntax here: "Full-blown": remotes { peter { address ...; port ...; }; pan { address ...; port ...; }; } "Current remotes" style: remotes { peter { address ...; port ...; } pan { address ...; port ...; } } "Key" style: remotes { peter address ... port ...; pan address ... port ...; } "Groups" style: remotes { peter { ... , ... } pan { ... , ... } } I really don't like the "groups" style. "Key" style is compact and easy to type, but harder to write the parser for. "remotes" style is not really a list. "Full-blown" does have the benefit of supporting recursion, i.e. having a list as an element in a list works fine. And the parser is simpler. I agree 1.4 is not the place, nor is a patch release. Let's take some time to think through as many config corners as possible so that you can try fixing them all in one go. You're welcome. Johan