Subject: Re: I-D ACTION:draft-reid-ipv6ok-00.txt

From: Jim Reid <[email-masked]>
Date: Fri, 01 Nov 2002 05:57:34 -0800

>>>>> "Eric" == Eric A Hall <[email-masked]> writes:

    Eric> There isn't a lot of discussion on what the flag is supposed
    Eric> to cause to happen. Does it mean that whenever a server
    Eric> would normally return an A RR (either as answer or
    Eric> additional-data) that it should also return any available
    Eric> AAAA RRs for all of those names?

If the bit was set, yes.

    Eric> What if the size of the answer will overload the EDNS
    Eric> message? That will put us back into the original problem
    Eric> case. Should the server not return the AAAA data, should the
    Eric> server give a truncated response using the existing rules,
    Eric> or what.

Good point. We can fix that in the next version.

    Eric> On a broader note, include-AAAA-for-every-A implicitly
    Eric> updates several specifications which prescribe
    Eric> additional-data behavior. Even if this doesn't result in any
    Eric> significant problems, it may still be necessary to itemize
    Eric> (at the least) or discuss (at the worst) the impact of this
    Eric> change to those specifications. OTOH, if the intention is
    Eric> architecture -- facilitating standardized usage but not
    Eric> updating the default behavior for any existing
    Eric> specifications -- then that should be stated somewhere
    Eric> explicitly as well.

Good point. We'll address that too.

    Eric> | More explicitly, IPv6-aware nameservers MUST NOT insert
    Eric> | AAAA RRs in a response unless the IO bit was set on the
    Eric> I request.

    Eric> Should be "MUST NOT insert [unsolicited] AAAA RRs" if I
    Eric> understand the model correctly.

Yeah, though the next sentence in the draft does clarify this, albeit
not clearly enough.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>