Subject: [BEHAVE] AD Review: draft-ietf-dns64-09

From: "David Harrington" <[email-masked]>
Date: Sat, 29 May 2010 10:45:12 -0400

Hi,

I am glad to see Magnus's concerns were addressed.
I have a few comments - none of which are blocking. 

-- advice --
I plan to start IETF Last Call within days. If you can fix these
first, that could reduce the number of Last call comments on the same
issues, so if you have time, submit a -10-.
You can let me know if you plan to do this, and I'll wait. Otherwise I
will IETF Last Call whichever version is available when I process the
Last Call requests. 
--

1) The document has some non-normative dependencies on
internet-drafts. if those I-Ds are not published as RFCs when DBNS64
is approved, this could slow publication of dns64, and possibly other
drafts that depend on dns64. Please make sure they are needed. 
I recommend removing mention of the mcast46 draft in section 5, since
it is just one approach.
savolainen-mif-dns-server-selection has not been adopted as a MIF WG
item yet; While that might be a valuable reference, I would hate to
hold up the behave documents for this pointer.

2) section 5.1.7 - educate me ;-)
"Under this specification, DNS64 for any CLASS other than 1 is
undefined."
What would/should a receiver do if a received AAAA has a CLASS field
other than 1?
Is that already covered someplace?

3) 5.2 s/MUST the/MUST be/

4) section 7 is non-normative, but it still should be highly readable.
I found this section difficult. The main problem is that the scenarios
are very similar, but the text to describe them varies a lot,
unnecessarily. I strongly recommend that this section be rewritten to
be more succinct and easier to read. Here are some editorial
suggestions:
a) address-format is already normative. Reference the definitions
provided there that describe the scenarios, rather than describing the
scenarios here verbosely.
b) some of the assumptions apply to all or most of the scenarios. It
might be helpful to keep as much common text in the section 7
introduction and out of the processing steps.
c) in the processing steps in 7.1, 7.2, and 7.3, use exactly yhe same
wording as much as possible. Think of running a diff on these
sections; it would be much easier for readers to see the differences
in processing if most of the text was exactly the same. The way you
have it now makes the reader hunt to find the real differences amidst
all the unnecessary differences in text.
d) The figures use "NAT64", while the text uses "IPv6/IPv4
Translator". I spent a few extra seconds checking to see that these
would be the same thing. If you used NAT64 in the text, the reader
wouldn't need to do their own manual mapping between the two.
e) In 7.1 and 7.2, your figure just says "IPv4 Network", not "IPV4
Internet"
f) in 7.3 bullet 3., it explicltly mentions checking policy. Is this
only applicable to the 7.3 scenario, or does it also apply to 7.1 and
7.2? Is mentioning it here really relevant to the example?

5) in 7.2, s/address T 203.0.113.1/address 203.0.113.1/  (extraneous
character?)
   in 7.3, s/address X 192.0.2.1/address X 192.0.2.1/    (extraneous
character?)
(is 203.0.x.x in the approved example address range?)

6) miscellaneous editorial suggestions:
a) number your figures
b) in 7.1, s/96 bits then/96 bits plus/
c) in 7.3, s/and so on//
d) in 7.3, s/This is so because in principle it/It/
e) in 8, s/DNS functions/DNS operates/ (I thought "functions" was a
noun and had to go back to re-parse the sentence to figure out you
were using it as a verb. "operates" avoids that problem.)
f) in 8, s/by its very function//
g) appendix A, s/also running/running/ (you already have an also)
h) appendix A, s/as a result// (you already have a hence)
i) appendix A, s/internet/Internet/
j) appendix A, s/In any case, the/The/
k) appendix A, s/but thsi requires effort on the part of the site
operator//

7) appendix A "So this option introduces problems"
are these **problems**, as in "I can't reach the address provided"?
or inefficiencies, as in "we routed through DNS64 unnecessarily"?
If these are real problems, then more should be said here that
discusses the problems, or you should reference the section in the
document that discusses the problem further.
Isn't the conclusion drawn in this section already explained in the
previous three paragraphs? So is this text and the following bullets
redundant?

Thanks,

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 31 May 2010 15:24:36 +0200

Hi David,

thanks for the review.

replies below...

> will IETF Last Call whichever version is available when I process the
As you said, these are merely examples and additional discussion, i will 
remvoe those unless someone esle argues otherwise.

> Is that already covered someplace?

 From i understood from Andrew, classes other than I are not used so 
they are usually not considered.
> 3) 5.2 s/MUST the/MUST be/

done
> scenarios here verbosely.
mmm, i understand you mean that the scenarios are already defined in the 
framework document, right?
I have removed the description of the scenarios in the introductory 
section and referred to the framework document. The result is the following:

<section title="Deployment scenarios and examples" anchor="examples">

<t>In this section, we walk through some sample scenarios that are 
expected to be common deployment cases.
                     It should be noted that this is provided for 
illustrative purposes and this section is not normative.
                     The normative definition of DNS64 is provided in 
<xref target="normative" />  and the normative definition
                     of the address transformation algorithm is provided 
in <xref target="I-D.ietf-behave-address-format" />.</t>
<t>In this section we illustrate how the DNS64 behaves in different 
scenarios
                     that are expected to be common. In particular we 
will consider the following scenarios defined in
<xref target="I-D.ietf-behave-v6v4-framework"/>:
                      the an-IPv6-network-to-IPv4-Internet scenario 
(both with DNS64 in DNS server mode and
                      in stub-resolver mode)  and the 
IPv6-Internet-to-an-IPv4-network setup
                      (with DNS64 in DNS server mode only). </t>

> introduction and out of the processing steps.

AFAICT, the assumptions that is repeated in all 3 cases is about the 
DNS64 being able to talk v4 with v4 only nodes and v6 with v6 only nodes 
and that there is a nat64 connecting the v6 network and the v4 network 
and that the prefix used by the dns64 is learnt through manual 
configuration.
I have included the following text the introductory section as you suggest.

<t>In all the examples below, there is a IPv6/IPv4 translator connecting the
  IPv6 domain to the IPv4 one. Also there is a name server
  that is a dual-stack node, so it can communicate with IPv6 hosts using
  IPv6 and with IPv4 nodes using IPv4. In addition, we assume that in 
the examples,
  the DNS64 function learns which IPv6 prefix it needs to use to map the 
IPv4
  address space through manual configuration.</t>

I have removed the corresponding text from sections after that.

> wording as much as possible.
right, i done that and i homogenized some text.

>   Think of running a diff on these
Since we use IPv6/IPv4 translator in all the document, i have changed 
the figures to read IPv6/IPv4 translator.

> e) In 7.1 and 7.2, your figure just says "IPv4 Network", not "IPV4
fixed

> 7.2? Is mentioning it here really relevant to the example?
It applies only to 7.3 cause in this case the DNS64 only synthesizes RR 
for which it is authoritative (as oposed to the other cases, where the 
DNS64 synthesizes any RR for which there is no AAAA RR).

I think it is relevant, since this is distinctive for this case.

> 5) in 7.2, s/address T 203.0.113.1/address 203.0.113.1/  (extraneous

fixed
>     in 7.3, s/address X 192.0.2.1/address X 192.0.2.1/    (extraneous
fixed

> (is 203.0.x.x in the approved example address range?)
yes, see RFC 5737

> 6) miscellaneous editorial suggestions:
done

> b) in 7.1, s/96 bits then/96 bits plus/
rephrased as:

  upper 96 bits and the received IPv4 address in the lower 32 bits
> c) in 7.3, s/and so on//
done
> d) in 7.3, s/This is so because in principle it/It/
I have removed the in principle

> were using it as a verb. "operates" avoids that problem.)
done

> f) in 8, s/by its very function//
done
> g) appendix A, s/also running/running/ (you already have an also)
done
> h) appendix A, s/as a result// (you already have a hence)
done
> i) appendix A, s/internet/Internet/
done
> j) appendix A, s/In any case, the/The/
done
> k) appendix A, s/but thsi requires effort on the part of the site
done

> previous three paragraphs? So is this text and the following bullets
right, i have removed the bullet list altogether.

Regards, marcelo

Thanks,
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>