<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">
<div>
<div>Hi Tomek, once again thanks for the quick reply. Sadly no, the identifier must be both the circuit-id and remote-id. Like I said before, circuit-ids can be equal when sent from different relays (remote-ids), I the pair <remote-id, circuit-id> to identify
the device. <br>
<br>
</div>
Best Regards,<br>
</div>
Rui<br>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="width:auto;height:20px;font-size:0px"> </td>
</tr>
<tr>
<td style="width:auto">
<div style="line-height:0"><a href="https://about.me/rpcaldeira?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links" style="text-decoration:none;display:inline-block" target="_blank">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="width:107px;line-height:1;vertical-align:top" valign="top" align="left">
<img alt="--" style="display:block;width:0;height:0;overflow:hidden" width="0" height="0">
<div><img src="https://aboutme.imgix.net/background/users/r/p/c/rpcaldeira_outlook.com_1455023098_86.jpg?w=105&q=90&dpr=1&auto=format,redeye&rect=0,14,756,504" alt="" style="margin:0;padding:0;display:block;border:1px solid #eeeeee" width="105" height="70">
</div>
</td>
<td style="width:10px;font-size:0px"> </td>
<td style="width:auto;line-height:1;padding:0px;padding-bottom:3px;vertical-align:bottom" valign="bottom" align="left">
<div style="margin:0;font-size:18px;font-weight:bold;color:#333333;font-family:proxima-nova-1,Proxima-Nova,Helvetica,Arial,Sans-Serif">
Rui Pedro Caldeira</div>
<div style="margin:0;margin-top:1px;font-size:12px;color:#2b82ad;font-family:proxima-nova-1,Proxima-Nova,Helvetica,Arial,Sans-Serif">
<img alt="https://" style="display:block;width:0;height:0;overflow:hidden" width="0" height="0">about.me/rpcaldeira</div>
</td>
</tr>
</tbody>
</table>
</a></div>
</td>
</tr>
<tr>
<td style="width:auto;height:20px;font-size:0px"><img src="https://about.me/t/sig?u=rpcaldeira" style="border:0;margin:0;padding:0;width:1;height:1;overflow:hidden" width="1" height="1"></td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Wed, Feb 1, 2017 at 9:01 PM, Tomek Mrugalski <span dir="ltr">
<<a href="mailto:tomasz@isc.org" target="_blank">tomasz@isc.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
W dniu 01.02.2017 o 11:37, Rui Pedro Caldeira pisze:<br>
<span class="">> Hello Tomek, I would like to thank your openness for my need of this<br>
> capability and I need it badly.<br>
> Since circuit-ids can be equal even when sent from different relays<br>
> (different remote-ids), I need the remote-id to disambiguate the<br>
> circuit-ids. Therefore, I need to specify the remote-id in the config<br>
> file next to the circuit-id, like in the following example:<br>
><br>
> "reservations": [<br>
> {<br>
> "remote-id": "<Remote ID Here>",<br>
> "circuit-id": "02:0A:00:01:06:07:00:00:00:<wbr>00:00:00",<br>
> "ip-address": "192.168.168.66"<br>
> }<br>
> ],<br>
</span>> "subnet": "<a href="http://192.168.168.0/24" rel="noreferrer" target="_blank">192.168.168.0/24</a> <<a href="http://192.168.168.0/24" rel="noreferrer" target="_blank">http://192.168.168.0/24</a>>"<br>
> },<br>
This kind of definition is not something I had in mind. The problem with<br>
your proposal are two identifiers used: remote-id and circuit-id.<br>
This would be impossible to store in Kea reservation tables. Kea stores<br>
reservations in MySQL and PostgreSQL in a table that has the following<br>
columns: identifier-type, identifier, ip-address. There are several<br>
other columns, but they're not important for this problem.<br>
<br>
The remote-id value is unique on its own, right? So you could use the<br>
remote-id only to distinguish between clients, right?<br>
<br>
We currently support several identifier-types. When we add remote-id, we<br>
will simply enable additional value to be specified there. This way we<br>
can continue adding new identifiers without requiring every deployment<br>
that stores them in SQL database to change the schema.<br>
<br>
So it would look more like this:<br>
<span class="">"reservations": [<br>
{<br>
"remote-id": "<Remote ID Here>",<br>
</span> "ip-address": "192.168.168.66"<br>
}<br>
],<br>
"subnet": "<a href="http://192.168.168.0/24" rel="noreferrer" target="_blank">192.168.168.0/24</a> <<a href="http://192.168.168.0/24" rel="noreferrer" target="_blank">http://192.168.168.0/24</a>>"<br>
},<br>
<br>
Would something like that work for you?<br>
<span class=""><br>
> I would like to ask how fast a patch to v1.1.0 could become available.<br>
</span>Adding new identifier type is maybe 2 weeks of work. We need to<br>
implement the ability to find reservations by new identifier (that's<br>
very simple), but we also need to update all reservation storages<br>
(config file, MySQL and PostgreSQL) to store them. Finally, we need to<br>
develop some tests that verify they are working. At the very minimum<br>
those would have to be unit-tests, but preferably we should also have<br>
system tests. That's what needs to be done from the engineering perspective.<br>
<br>
Sadly, that doesn't mean you'll get it by mid February. We are currently<br>
working on our 1.2 milestone and remote-id was not part of that work.<br>
<span class=""><br>
> Otherwise, do you have any tips as to how can I resolve this issue?<br>
</span>There are couple options. First, ISC sets the roadmap in a way to<br>
accommodate requests from support customers, if possible. If such a<br>
request came from a customer, we would do our best to implement it<br>
promptly. Second, ISC offers custom development contracts. Sometimes we<br>
are asked to develop certain feature with specific deadline and agreed<br>
functionality. Depending on the agreed schedule, the code is then<br>
released in the upcoming release (sometimes we do an engineering drop<br>
earlier if the customer cannot wait for a release that is couple months<br>
away). Both of those options require some financial commitment.<br>
<br>
Another option would be to develop a patch yourself (or find someone who<br>
will develop it for you) and send us a patch. I must honestly say that<br>
we recently received quite a few patches that we still haven't reviewed.<br>
So it's not an instant process by any means, but having a patch<br>
definitely speed things up.<br>
<br>
Finally, there's the "convince us" option. There are lots of missing<br>
features in Kea and our resources are limited. Therefore we try to pick<br>
those features for implementation that are most frequently requested,<br>
would be useful for large number of users or give us a prospect for<br>
improving financial stability of Kea.<br>
<br>
These are basically your options. You are not the first one to ask for<br>
remote-id reservations, so there's non-trivial chance that we'll decide<br>
to put it on our plan for 1.3. 1.3 doesn't have any scope or release<br>
date defined, but I could speculate it would be release some time in the<br>
autumn.<br>
<br>
Hope that helps. Sorry if that's not exactly what you were hoping for.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tomek<br>
<br>
</font></span></blockquote>
</div>
<br>
</div>
</body>
</html>