On 22/11/2018 12:53, Jim Hague wrote:
> On 21/11/2018 14:43, Suresh Krishnan wrote:
>> * Section 7.4.1.1.
>>
>> Looks like you can limit the
{client,server}-address-prefix-{ipv4,ipv6} fields
>> to one byte to restrict the range. e.g.
>>
>> client-address-prefix-ipv6 => uint .size 1
>>
>> Similar restrictions can be used for port (2) and TTL/hop limit (1)
fields.
>[....]
>
> As to whether there is value in applying size or range restrictions
> throughout the rest of the fields, we're not so sure. As well as port
> and hoplimit, many of the DNS items (e.g. opcode, rcode) could also be
> allocated a maximum size. Or possibly we should only put a range on
> user-specified items such as VLAN IDs or opcodes to capture.
>
> We'll ask the CBOR WG mailing list if there is a preferred CDDL style
> for these cases.
The CBOR WG report there is as yet no received style, or in this case
right answer.
In the context of C-DNS, I am inclined to express ranges where values
stored are generated by the C-DNS application, but not for values of DNS
traffic items. C-DNS is storing traffic collected by one means or
another, and I think it should be storing what's reported. Expressing
validity ranges moves towards C-DNS being required to validate the
traffic. We intend C-DNS to be a storage mechanism, not a validation one.
So I suggest we specify validity ranges only for the following
configuration items:
StorageParameters:
* IPv6 prefix length. 1..32.
* IPv4 prefix length. 1..128.
* OPCODE (in list of OPCODEs to collect). 0..15.
* RR TYPE (in list of RR TYPEs to collect). 0..65535 or uint .size 2.
CollectionParameters:
* Promiscuous mode. Make this a boolean, holding CBOR true or false.
* VLAN ID (in list of VLAN IDs to collect). 1..0xffe.
--
Jim Hague - j...@sinodun.com Never trust a computer you can't lift.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
