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