Subject: DOC-BUG/TECH-OMISSION in -protocol: A vs AAAA

From: Peter Koch <[email-masked]>
Date: Mon, 06 Sep 2004 00:00:24 +0200

This is about subsections 4.3, 4.4 and 4.5 of draft-ietf-marid-protocol-02
and I'm not sure whether it's a doc-bug or the wording is deliberately chosen.

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?

o In 4.4 the draft now only talks about A tyep resolution when it comes to
  identifying the MX target. Not only is this inconsistent with 3.1, it
  also questions the conclusion for 4.3 above.

o NB: "if <ip> is one of the MX hosts" should be changed to something like
  "if <ip> is an IP address of one of the MX hosts", since <ip> is an address
  and cannot *be* the host.

o 4.5 :"This mechanism tests if <ip>'s name is within a particular domain"
  suggested rewording: "This mechanism tests if the DNS reverse mapping for
  <ip> exists and consistently points to a domain name within a particular
  domain".

o 4.5 "perform a PTR lookup against <ip>" suggests to look for a PTR RR for
  the address, which isn't meant. Rewording similar to the one above.

Nice DoS opportunity, btw.

-Peter

---

From: <[email-masked]>
Date: Sun, 5 Sep 2004 19:28:18 -0400

>   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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Sep 2004 09:16:23 +0200

On Mon, Sep 06, 2004 at 12:00:24AM +0200,
 Peter Koch <[email-masked]> wrote 
 a message of 27 lines which said:

> o In 4.3, although the mechanism is called "a", suggesting
> similarity to the IPv4 address RR type "A"

Unfortunately, yes, there is a potential for confusion, but this is
probably for historical reasons.

>  combined with the "Note" in 3.1 both A and AAAA RR types need to be
>  checked, don't they?

Yes.

> o In 4.4 the draft now only talks about A tyep resolution when it
> comes to identifying the MX target. Not only is this inconsistent
> with 3.1, it also questions the conclusion for 4.3 above.

Already reported:

http://www.imc.org/ietf-mxcomp/mail-archive/msg03518.html