Re: [BEHAVE] [Technical Errata Reported] RFC6147 (3236)

While this may be a valid criticism, based on the rules
for errata processing, I think the only feasible option
we have is to reject it for now.

http://www.ietf.org/iesg/statement/errata-processing.html
says:
Changes that are clearly modifications to the intended consensus, or
involve large textual changes, should be Rejected.

HOWEVER, it seems to me that if there was consensus
around some new text that was simple to plop into that
section, then the "Corrected Text" field could be
updated with that, and we could make it a "Hold for
Document Update" rather than rejecting it.

Thoughts?

On 5/30/2012 8:48 PM, RFC Errata System wrote:
> 
> The following errata report has been submitted for RFC6147,
> "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6147&eid=3236
> 
> --------------------------------------
> Type: Technical
> Reported by: Mark Andrews <marka@isc.org>
> 
> Section: 5.5
> 
> Original Text
> -------------
> An application that wants to perform validation on its own should use the CD bit.
> 
> Corrected Text
> --------------
> Section 5.5 needs to be completely re analysed,
> 
> Notes
> -----
> Section 5.5 is written around the assumption that a validating stub resolver will be setting CD=1 as well as DO=1.  There is no such requirement RFC 4035 and in fact setting both CD=1 and DO=1 leaves the stub resolver vulnerable to answers from authoritative servers for the zone that are serving a stale copy of the zone and spoofed answers being sent to the DNS64 server.
> 
> Non CD=1 queries result in the DNS64 server in its recursive roll, filtering out, cryptographically bad answers.
> 
> DO=1 alone should disable synthesis.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC6147 (draft-ietf-behave-dns64-11)
> --------------------------------------
> Title               : DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
> Publication Date    : April 2011
> Author(s)           : M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum
> Category            : PROPOSED STANDARD
> Source              : Behavior Engineering for Hindrance Avoidance
> Area                : Transport
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
> 
> 

-- 
Wes Eddy
MTI Systems