One work around for this would be define a custom option:

"Dhcp4":
{
    :
  "option-def": [
        {
            "name": "newtextstring",
            "code": 222,
            "type": "string"
        } ]
   :
   :
   "subnet4": [{
        "subnet": "175.16.1.0/24",
        "pools": [ { "pool": "175.16.1.100 - 175.16.1.200" } ],
         "option-data": [
            {  "name": "newtextstring",  "data": "internal server pool" }
               :
            ]
        :
   
Maybe not that pretty but you could do it.  The option wouldn't get sent
to clients unless they asked for it.  The bigger question is what you
want to do with this value?

Regards,

Thomas Markwalder
ISC Software Engineering

On 8/18/17 9:02 AM, James Sumners wrote:
>
> That’s definitely a strong argument for a strict parser. Maybe adding
> support for a “comment” property would be a good compromise. The
> property could be any valued (i.e. string, object, array, whatever).
>
> With such a property allowed it would be possible to write completely
> valid JSON such that editors and can work with it.
>
>
>
>
> From: Francis Dupont <fdup...@isc.org> <mailto:fdup...@isc.org>
> Date: August 18, 2017 at 8:11:00 AM
> To: James Sumners <jamessumn...@clayton.edu>
> <mailto:jamessumn...@clayton.edu>
> Cc: kea-users@lists.isc.org <kea-users@lists.isc.org>
> <mailto:kea-users@lists.isc.org>, itay cohen <icohen9...@gmail.com>
> <mailto:icohen9...@gmail.com>
> Subject: Re: [Kea-users] free text parameter under each subnet
>
>> James Sumners writes:
>> > Unfortunately the parser doesn't ignore unknown properties.
>>
>> => not unfortunately: it is by design and I am sure you'd like the
>> parser to catch a trivial spelling error than to silently ignore it.
>>
>> Regards
>>
>> Francis Dupont <fdup...@isc.org>
>>
>> PS: as you expect to add a new subnet property you need to patch the
>> parser. Note in pools you have the user-context property which can be
>> used
>> for the same goal and can be extended (i.e., post a request) to subnets
>> or other syntax elements (only host reservations will be complex because
>> of external host databases).
>
>
> _______________________________________________
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users


_______________________________________________
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Reply via email to