Variable address prefix length?

[banburybill]

• Section 7.5.3: It's very good that the BlockTables "ip-address" items
  can be truncated by prefix length, but we have actually run into cases
  that call for /variable/ truncation (i.e., more precision in some
  subnets than in others), especially true given that a single table holds
  both client and server address data. What would you think about
  representing addresses not as direct byte strings, but rather as
  variable-length arrays or maps—index 0 encoding the prefix as a byte
  string, and optional index 1 (when present) encoding a prefix-length
  override? Or, if the extra size per address is too much, at least
  allowing such representations via polymorphism (byte string for default
  prefix-length, array/map for non-default)?

https://mailarchive.ietf.org/arch/msg/dnsop/OADqnhAq-Q3GA9JVde1JDmvLNwo

[banburybill]

Extra size on each address is too much of a penalty on our main anticipated use cases.

Polymorphism is an interesting idea. It does (space-wise) penalise the prefix length override option, but if this is required feels a promising approach. The question is whether there is demand for this use case to justify the additional complexity. It could be implemented as a custom extension for closed systems.

So far we've not had other feedback on this suggestion following our comments on the list or the WG at IETF101. We've therefore not attempted to incorporate this into the latest draft.

[banburybill]

• This format in its present state can work for my organization, but the second gap in particular means we'll be manually hacking around those deficiencies by e.g. representing 192.0.2.0/24 as 192.0.2.0/32 in order to fully specify 198.51.100.42/32.

https://mailarchive.ietf.org/arch/msg/dnsop/in-7bC5T7NHkaMfWuUSQFoyQQCg