Hello!
I'm not sure if it is possible to parse something like:
hex(1234)
both as a function call and a special bytestring depending on the symbol
presense. I thought such bytestrings is needed to be defined in the lexer
as a single expression for the whole sequence, because if you pass it upper
to a parser as: HEX '(' <something> ')' - you'll have problem with how to
parse that <something>, because it should be context-dependent.
But I'm not that proficient with the parsing and I'm probably missing
something. So if you have any tips on how to do it, I will be glad if you
share them with me.
BTW that kw_sym workaround seems like it needs to contain much more
symbols. :)
On Mon, Jun 12, 2023 at 2:40 PM Maria Matejka <maria.mate...@nic.cz> wrote:
> Hello!
>
> I think using hex() and base64() with adding these two tokens to the
> "kw_sym:" non-terminal. This way, no current config should break.
>
> Also it may be handy for both hex() and base64() to accept any number of
> whitespace inside the argument, to enable configs like hex(de ad be ef) or
> other direct pastes from hexdumps or base64 encoders. We could then e.g.
> add the SSH keys for RPKI inline to the config file.
>
> I'd prefer keeping the IPv6 and bytestrings as they are now, possibly even
> deprecating the current bytestring format in future. (Weak opinion on this.)
>
> Maria
> On 6/12/23 14:24, Alexander Zubkov wrote:
>
> Hello, Maria!
>
> You suggestion for blob syntax seems good to me. I think I can try to
> prepare patches for that. Only one concern is that it could break some
> current configuration files, if they have functions with such names. Maybe
> it is better to use some other "brackets" to make it less possible to hit
> something? hex<deadbeef> or hex[deadbeef] maybe? Or even something exotic
> like hex|deadbeef| ?
>
> Would you like to keep my proposed changes for IPv6 and bytestrings too?
> Or just introduce the new syntax?
>
> On Mon, Jun 12, 2023 at 1:33 PM Maria Matejka <maria.mate...@nic.cz>
> wrote:
>
>> Hello!
>>
>> This looks like a clever solution for such a problem. Thank you for the
>> patch!
>>
>> Regarding the bytestring syntax, what about adding some syntax like
>> hex(deadbeef12345678) or even base64(...) where the user could write byte
>> blob of any length?
>>
>> Maria
>> On 6/12/23 13:08, Alexander Zubkov via Bird-users wrote:
>>
>> Hi,
>>
>> Currently one can use only a predefined set of advertised options in radv
>> protocol, that are supported by bird's configuration. It would be
>> convenient to be able to specify other possible options at least manually
>> as a blob so one should not wait until it is supported in the code,
>> released, etc.
>>
>> This idea is inspired by presentation by Ondřej Caletka at CSNOG, in
>> which he noticed the lack of either PREF64 option or possibility to add
>> custom options in various software.
>>
>> Attached patch [radv-custom.patch] makes it possible to define such
>> options with the syntax:
>>
>> other type <num> <bytestring>
>>
>> I can also prepare a patch for documentation if it is to be merged.
>>
>> But it does solve the question with PREF64 completely. Because currently
>> bytestring minimal length is 16 bytes, but for PREF64 we need to provide a
>> 14-byte blob. And for minimal RA option, it have to be as short as 6 bytes.
>>
>> So another patch [bytestring-short.patch] allows bytestrings to be as
>> short as 6 bytes, when colon-notation is used: "01:02:03:04:05:06". And I
>> kept the minimum size of 16 bytes without colons, because it can conflict
>> with some symbol names.
>>
>> The main concern is that a 6-byte bytestring conflicts with the MAC
>> address representation. Bird does not have the type for it currently, but
>> who knows, it might need it in the future. So we might need some new syntax
>> for bytestring in that case. Or it can be postponed to later time. In this
>> case introduction of MAC-address lexems would break configs that use 6-byte
>> bytestrings (if we want to care much about those).
>>
>> It is also not possible to define a 8-byte bytestring, because it
>> conflicts with IPv6 address, but we are introducing short bytestrings for
>> RA here, and 8-byte bytestrings are not strictly required for that, because
>> possible option sizes are 8, 16, ... with payloads 2 bytes less: 6, 14, ...
>> So if one needs a 8-byte payload, he can easily pad it with extra zeroes
>> ":00" with the same on-the-wire result. But still, this gives one more
>> reason for an additional syntax for bytestrings.
>>
>> There also was possbility to explicitly allow only 6, 7, 9 and greater
>> lengths of bytestrings. Or to move IPv6 regex definition before bytestring
>> definition to make it more preferrable. I choose the second variant, but
>> IPv6 regex is too loose now and match many things far from IPv6 notation.
>> So I decided to provide a more strict regex definition for IPv6 addresses.
>> Of course it is ugly, but I think it could be helpful anyway, because it
>> does not conflict with other similar lexems, including MAC addresses.
>>
>> As a downside for this, in case of some typo in IPv6 address, there will
>> not be a meaningful error about bad IPv6 address. So I added an additional
>> regex there, to catch lexems with hex digits and at least 2 colons to show
>> more meaningful error for that. But I'm not sure about it.
>>
>> If those changes for bytestrings are OK too, I also can prepare further
>> patch for documentation.
>>
>> Have a nice day,
>> Alexander Zubkov
>>
>> --
>> Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.
>>
>> --
> Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
>
