-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Dmitry Anipko
Sent: Tuesday, March 29, 2011 8:07 PM
To: Jari Arkko; behave(_at_)ietf(_dot_)org
Cc: 'David Harrington'; behave-chairs(_at_)tools(_dot_)ietf(_dot_)org;
draft-ietf-
behave-dns64(_at_)tools(_dot_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: RE: [BEHAVE] auth48 changes to draft-ietf-behave-dns64
Hi,
I have a question about the particular part of the suggested diff. The
diff says:
Alternatively, *if configured to do so*, it MAY treat the answer
as...
Does the part marked with stars imply that an implementation must
support such configuration setting, or the support of such
configuration setting is also covered by the following MAY?
I would interpret as support of such configuration setting as
covered by the following MAY.
-d
Thank you,
Dmitry
-----Original Message-----
From: behave-bounces(_at_)ietf(_dot_)org
[mailto:behave-bounces(_at_)ietf(_dot_)org] On
Behalf Of Jari Arkko
Sent: Tuesday, March 29, 2011 6:29 AM
To: behave(_at_)ietf(_dot_)org
Cc: behave-chairs(_at_)tools(_dot_)ietf(_dot_)org; 'David Harrington';
ietf(_at_)ietf(_dot_)org;
draft-ietf-behave-dns64(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: [BEHAVE] auth48 changes to draft-ietf-behave-dns64
I'm OK with these changes.
Jari
Dan Wing kirjoitti:
During auth48 of draft-ietf-behave-dns64-11.txt, it was realized that
two sections were not consistent.
The text in Section 5.1.1 is clear:
If there is (non-excluded) AAAA data available, DNS64
SHOULD NOT include synthetic AAAA RRs in the response (see
Appendix A
for an analysis of the motivations for and the implications of not
complying with this recommendation). By default, DNS64
implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
exist
That is, SHOULD NOT in the general case, and MUST NOT as a default
case.
This represents WG consensus.
But then 5.1.4 says something slightly different:
If it receives an answer with at
least one AAAA record containing an address outside any of the
excluded range(s), then it MAY build an answer section for a
response
including only the AAAA record(s) that do not contain any of the
addresses inside the excluded ranges. That answer section is used
in
the assembly of a response as detailed in Section 5.4.
Alternatively, it MAY treat the answer as though it were an empty
answer, and proceed accordingly. It MUST NOT return the offending
AAAA records as part of a response.
It seems rather self-defeating to have excluded ranges and then
ignore those. Then the only issue is: if there are both an
excluded AAAA record and a non-excluded one, the above says you
can either return the good one, or not return any AAAA records.
The proposal is to change the "MAY build an answer section" in 5.1.4
to "by default MUST build an answer section", so it would read as
follows. The critical changes are highlighted with "^":
When the DNS64 performs its initial AAAA query, if it receives an
answer with only AAAA records containing addresses in the excluded
range(s), then it MUST treat the answer as though it were an empty
.....................^^^^
answer, and proceed accordingly. If it receives an answer with at
least one AAAA record containing an address outside any of the
excluded range(s), then it by default SHOULD build an answer
section
.................................^^^^^^^^^^^^^^
for a response including only the AAAA record(s) that do not
contain
any of the addresses inside the excluded ranges. That answer
section
is used in the assembly of a response as detailed in Section 5.4.
Alternatively, it MAY treat the answer as though it were an empty
answer, and proceed accordingly. It MUST NOT return the offending
AAAA records as part of a response.
We believe this is in line with the WG consensus in section 5.1.1.
The updated files are here:
http://www.rfc-editor.org/authors/rfc6147.txt
http://www.rfc-editor.org/authors/rfc6147.xml
http://www.rfc-editor.org/authors/rfc6147-diff.html
We are soliciting feedback for this change until noon (Prague time)
on Friday, April 1. Please send feedback to behave(_at_)ietf(_dot_)org.
-d
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Behave mailing list
Behave(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf