<div dir="ltr"><div>Hello!</div><div><br></div><div>I'm not sure if it is possible to parse something like:</div><div><br></div><div>hex(1234)</div><div><br></div><div>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.<br><br>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.</div><div><br></div><div>BTW that kw_sym workaround seems like it needs to contain much more symbols. :)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 12, 2023 at 2:40 PM Maria Matejka <<a href="mailto:maria.matejka@nic.cz" target="_blank">maria.matejka@nic.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><font face="Gentium">Hello!</font></p>
<p><font face="Gentium">I think using hex() and base64() with adding
these two tokens to the "kw_sym:" non-terminal. This way, no
current config should break.</font></p>
<p><font face="Gentium">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.<br>
</font></p>
<p><font face="Gentium">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.)</font></p>
<p><font face="Gentium">Maria</font><br>
</p>
<div>On 6/12/23 14:24, Alexander Zubkov
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hello, Maria!</div>
<div><br>
</div>
<div>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<<font face="Gentium">deadbeef</font>> or hex[<font face="Gentium">deadbeef</font>] maybe? Or even something
exotic like hex|<font face="Gentium">deadbeef</font>| ?<br>
</div>
<div><br>
</div>
<div>Would you like to keep my proposed changes for IPv6 and
bytestrings too? Or just introduce the new syntax?<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jun 12, 2023 at
1:33 PM Maria Matejka <<a href="mailto:maria.matejka@nic.cz" target="_blank">maria.matejka@nic.cz</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><font face="Gentium">Hello!</font></p>
<p><font face="Gentium">This looks like a clever solution
for such a problem. Thank you for the patch!<br>
</font></p>
<p><font face="Gentium">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?</font></p>
<p><font face="Gentium">Maria</font><br>
</p>
<div>On 6/12/23 13:08, Alexander Zubkov via Bird-users
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Attached patch [radv-custom.patch] makes it
possible to define such options with the syntax:</div>
<div><br>
</div>
<div>other type <num> <bytestring></div>
<div><br>
</div>
<div>I can also prepare a patch for documentation if it
is to be merged.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>If those changes for bytestrings are OK too, I also
can prepare further patch for documentation.</div>
<div><br>
</div>
<div>Have a nice day,</div>
<div>Alexander Zubkov<br>
</div>
</div>
</blockquote>
<pre cols="72">--
Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</div>
</blockquote>
</div>
</blockquote>
<pre cols="72">--
Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
</div>
</blockquote></div>