On Mon, 06 Sep 2004 00:00:24 +0200, Peter Koch
<pk(_at_)techfak(_dot_)uni-bielefeld(_dot_)de> wrote:
o In 4.3, although the mechanism is called "a", suggesting similarity to
the IPv4 address RR type "A" combined with the "Note" in 3.1 both A and
AAAA RR types need to be checked, don't they?
Interesting. Now that you've pointed it out, I think there might be
an ambiguity. In particular, I always assumed that, for example,
"a/24" meant check IPv4, while "a//64" meant check IPv6, and just "a"
meant check both (same as "a/32//128").
But I guess it might be possible to interpret "a/24" as equivalent to
"a/24//128" and "a//64" as equivalent to "a/32//128". In fact,
reading section 4 pedantically, I think that may be the more exact
interpretation. This is slightly annoying, because it would have been
nice to have a mechanism to restrict a particular use of the mechanism
to IPv4 or IPv6.
In fact, while we are nitpicking, the capitalization of "cidr-length"
is not consistent. Section 4 uses CIDR-length, while 4.6 uses
"cidr-length". Moreover, that term is never formally defined.
Therefore, in addition to fixing the ambiguity above, I also propose
the following change to section 4.6. Change:
If the cidr-length is omitted, the ip4-cidr-length is taken to be
"/32" and the ip6-cidr-length is taken to be "/128".
To:
If ip4-cidr-length is omitted, it is taken to be "/32". If
ip6-cidr-length is omitted, it is taken to be "/128".
In fact, it's probably too late for this, but I wonder if for
consistency the grammar shouldn't have been:
IP6 = "ip6" ":" ip6-network [ "/" ip6-cidr-length ]
and the default "//128".
David