Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-dns64-06

From: "Dan Wing" <[email-masked]>
Date: Wed, 17 Feb 2010 10:28:01 -0800

** We need at least 5 reviewers to tell us this document is ready 
** for submission to IESG.  Please email [email-masked] 
** with a subject line containing the document name, and "ready 
** to submit to IESG" or "not ready to submit to IESG" in the 
** message body.  If not ready to submit, please propose new text.

This email starts the 2nd WGLC for draft-ietf-behave-dns64-06, ending
in one week (Wednesday, February 24).  For reference, the first 
WGLC was for draft-ietf-behave-v6v4-framework-05.  

Differences from -05 (first WGLC) and -06 (2nd WGLC),
http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-dns64-06.txt

-d

---

From: Dave Thaler <[email-masked]>
Date: Mon, 22 Feb 2010 19:35:21 +0000

Almost all of my comments from the 1st WGLC were addressed.
Below are typos in -06 I found, along with one or two that
still remain from my previous comments.

Section 5.1.5:
> authortiative server, by examining its own results.  If this new A RR
  ^^^^^^^^^^^^^
Fix spelling of authoritative

Section 5.2:
> 96.  If one or more Pref64::/n are configured in the DNS64
> through any means in the DNS64 (such as manually configured, or
                    ^^^^^^^^^^^^
Delete duplicate phrase

> Well-Know Prefix).  If no prefix is available, the algorithm
       ^^^^
s/Know/Known/

> MUST use the Well-Known prefix 64:FF9B::/96 defined in
                          ^
Capitalize for consistency with rest of doc.

Section 5.3.1:
I didn't see my question answered regarding this text:
> If the address prefix matches any Pref64::/n used
> in the site, either a NSP or the Well-Known Prefix (i.e. 64:
> FF9B::/96), then the DNS64 server MAY answer the query using locally-
> appropriate RDATA.                ^^^

Since MAY is defined as completely optional, what would the
alternative be if an implementation opted not to follow this
MAY?  Not answer the query?   I suspect a "MUST" was intended
instead of "MAY" but I can't tell for sure.

Section 5.3.3:
> If the DNS64 is in recursive resolver mode, then considerations
                               ^^^^^^^^

Section 2 defined "DNS64 in DNS recursive mode" (not
"recursive resolver mode".  Be consistent.

Section 5.5:
> 5.5.  DNSSEC processing: DNS64 in recursive server mode
                                              ^^^^^^
Same comment.

Section 7.1:
> A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
              ^
Lower-case t for consistency with rest of doc.
(2 occurrences)

Section 8:
>   section 3, section 5.5, and section 6.2. .
                                             ^
Delete extra period

Appendix A:
> Appendix A.  Motivations and Implications of synthesizing AAAA RR when
>            real AAAA RR exists

OLD: "RR when real AAAA RR exists"
NEW: "RRs when real AAAA RRs exist"

> The motivation for synthesizing AAAA RRs when a real AAAA RRs exist
                                                ^
s/a//

> The implication of including synthetic AAAA RR when real AAAA RR
s/RR/RRs/ (twice)

> In "An IPv6 network to the IPv4 Internet" scenario , the host will
    ^                                               ^
Insert "the"						Delete space

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dan Wing
> Sent: Wednesday, February 17, 2010 10:28 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-dns64-06
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Feb 2010 15:14:45 -0500

> still remain from my previous comments.

Thanks for these.  I didn't miss your previous comments (see my
response at
http://www.ietf.org/mail-archive/web/behave/current/msg08038.html -- I
never saw a response to those, so I assumed they were ok).

> instead of "MAY" but I can't tell for sure.

It's supposed to be MAY.  The paragraph starts "The first option" and
the next paragraph says "The other option".  The idea is that you can
do either, but you have to pick one.

We can't possibly make this MUST.  We can't get the DNS community to
agree that the reverse tree even needs to be maintained.  I tried at
one point to get a document through DNSOP on this topic, and it went
nowhere.

> "recursive resolver mode".  Be consistent.

Section 2 doesn't have the definitions, strictly; section 4 does.  I
added this to section 4 between -05 and -06:

   DNS64 recursor:  A recursive resolver that provides the DNS64
      functionality as part of its operation.  This is the same thing as
      "DNS64 in recursive resolver mode".

But obviously, the word "resolver" is missing in Section 2.  I missed
that and the word "server" in section 5.  Thanks for catching.

More generally, did the additions to the definitions section help?

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 23 Feb 2010 02:04:49 +0000

[...]
> More generally, did the additions to the definitions section help?

Absolutely.

Thanks,
-Dave