Re: [BEHAVE] auth48 changes to draft-ietf-behave-dns64

["Dan Wing" <[e-mail]>]

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