I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00.txt
Reviewer: Francis Dupont
Review Date: 20110618
IETF LC End Date: 20110623
IESG Telechat date: unknown
Summary: Not Ready
Major issues: the "DNS resolver" selection problem is not a DNS problem:
it comes from a common use of the DNS which is not in the DNS model.
I agree it is a real world problem but its origin IMHO requires more care
about its explaination.
I suggest to ask the DNSOP WG about what to do (and to get the correct
terminology, IMHO resolver -> caching server). BTW DNSSEC could change
this: it makes views of not local domains more coherent and the different
kinds of DNSSEC aware resolvers (*not* caching servers) are host software.
Minor issues:
- I don't understand why the notion (and well known term) of
ingress filtering is not used...
- I have a mixed feeling about the whole document: IMHO it is more
in the scope of the mif WG, and I am not convinced by it at the
exception of the negative points (i.e., multi-homing in IPv6 still
doesn't work at it should...). So what is its real goal?
Nits/editorial comments:
- 1 page 3: missing comma? in
"Whenever a host or small network (which does not meet minimum IPv6
allocation criteria) is connected to multiple upstream networks IPv6
^ ,
address is assigned by each respective service provider resulting in
hosts with more than one active IPv6 addresses."
- 1 page 3: definced -> defined?
- 1 page 4: in its standard model, the DNS is location independent so
any caching servers should return the same thing... (cf major issue)
- 1 page 4: resolvers -> caching servers
- 1 page 4: introduce thee uRPF abbrev (or better use 'ingress
filtering')
- 3.1 page 6 (comment): the explaination of scenario 2 strongly
suggests the use of DHCPv6!
- 3.3 page 8: another place where 'ingress filtering' is better
- 3.3 page 8 (and further): there are hosts which manages multiple
default routers (BTW this doesn't solve the problem at all, the
text is just not accurate as it assumes no such host exists)
- 3.3 page 9: ie, -> i.e.,
- 3.3 page 9: policy routing (Cisco term, Juniper has the same thing
with a different name) allows a router to determine which traffic
should be sent to which network (i.e., the text is false).
- 7.2 page 15: coexistence -> co-existence (i.e., I believe the title
is right)
- 8 page 16: his -> its (the policy distributor is a device)
Regards
[email protected]
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
