On 21/11/2018 14:43, Suresh Krishnan wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: No Objection
>
Thanks for the review.
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> * 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.
We already specify IPv4 and IPv6 addresses with a size:
IPv4Address = bstr .size 4
IPv6Address = bstr .size 16
so we think that similarly emphasising the constraints on the address
prefix lengths would be consistent. Rather than .size, we think a range
more appropriate, i.e.:
OLD: "? client-address-prefix-ipv4 => uint,
? client-address-prefix-ipv6 => uint,
? server-address-prefix-ipv4 => uint,
? server-address-prefix-ipv6 => uint,"
NEW: "IPv4PrefixLength = 1..32
IPv6PrefixLength = 1..128"
"? client-address-prefix-ipv4 => IPv4PrefixLength,
? client-address-prefix-ipv6 => IPv6PrefixLength,
? server-address-prefix-ipv4 => IPv4PrefixLength,
? server-address-prefix-ipv6 => IPv6PrefixLength,"
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.
--
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
