>>>>> On Wed, 11 Feb 2004 23:56:35 +0200 (EET),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
> AFAIK, we don't have real deployment experience of this. I don't
> think we know the full consequences resulting from EDNS0 use because
> it hasn't been widely used yet. Thus, I'm a bit hesitant to put
> wording as strong as SHOULD here.
If this is your main reason, I disagree.
First, as Rob pointed out, we have enough experience about the client
side of EDNS0 in DNS recursive servers, which I believe can be applied
to the deployment at stub resolvers.
Secondly, the node requirement document contains other SHOULDs of
which we have little real deployment experience:
Nodes that need to join multicast groups SHOULD implement MLDv2
[MLDv2].
(Section 4.6)
Hosts SHOULD support route optimization requirements for
correspondent nodes described in Section 8.2 of [MIPv6].
(Section 7)
With your logic, we'd also have to change these SHOULDs to MAYs
(perhaps you've already insisted this?). IMO, the deployment status
and experience about EDNS0 (the client side or even at stub resolvers)
is much more mature than that for these SHOULDs.
I personally do not think supporting EDNS0 at stub resolver is crucial
even with AAAA RRs (at least *without* DNSSEC RRs), BTW, because such
resolvers usually only need short sizes of packets; short enough to
meet the 512-byte requirement. In this sense, I would not oppose to
the SHOULD, but I'm not insisting a SHOULD.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
