> -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Dmitry Anipko > Sent: Tuesday, March 29, 2011 8:07 PM > To: Jari Arkko; behave@xxxxxxxx > Cc: 'David Harrington'; behave-chairs@xxxxxxxxxxxxxx; draft-ietf- > behave-dns64@xxxxxxxxxxxxxx; ietf@xxxxxxxx > 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@xxxxxxxx [mailto:behave-bounces@xxxxxxxx] On > Behalf Of Jari Arkko > Sent: Tuesday, March 29, 2011 6:29 AM > To: behave@xxxxxxxx > Cc: behave-chairs@xxxxxxxxxxxxxx; 'David Harrington'; ietf@xxxxxxxx; > draft-ietf-behave-dns64@xxxxxxxxxxxxxx > 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@xxxxxxxxx > > > > -d > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > Behave mailing list > Behave@xxxxxxxx > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf