Thank you for your review, and a –04 revision is coming soon. Other comments
inline below.
Thanks!
Jason
On 4/26/11 5:51 AM, "Pekka Savola"
<pekkas(_at_)netcore(_dot_)fi<mailto:pekkas(_at_)netcore(_dot_)fi>> wrote:
On Fri, 15 Apr 2011, The IESG wrote:
The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 AAAA DNS Whitelisting Implications'
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> as an
Informational RFC
This is an ops-dir review of
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.
The document is readable and could be published as-is. I share some of the
concerns already expressed in the document, but I think the doc strikes a
reasonable balance between the concerns and practical points.
One bigger comment:
-------------------
Section 6 on deployment scenarios seems too black and white: either it is
done ad-hoc or (completely) universally. The latter is unfeasible.
[JL] I received similar feedback from others and have tried to address this
better in the upcoming –04 version.
The document should cover a middle ground which is already discussed in
[NW-Article-DNS-WL], i.e., one or more whitelisting information providers
would be used by multiple content networks. This has many benefits compared
to completely ad-hoc model, and is feasible compared to universal model.
[JL] Added a note concerning this in the I-D.
The "universal deployment model" proposition has created ripples throughout
the document (one such place is S 7.3.7), and I think the document might
have been clearer if that was taken out completely -- or at least, issues
related to each deployment model would be more clearly separated.
[JL] Good question, which is such a meta-concern that I'm going to list it in
the open items tracker at the end of the document for consideration after the
–04 update (since so many other changes are taking place in that version).
8.3.1. Solving Current End User IPv6 Impairments
...
One challenge with this option is the potential difficulty of
motivating members of the Internet community to work collectively
towards this goal, sharing the labor, time, and costs related to such
an effort. Of course, since just such a community effort is now
underway for IPv6, it is possible that this would call for only a
moderate amount of additional work.
... I would observe that ad-hoc whitelisting is already requiring a lot of
work from each of whitelisting providers. Would this require more than
that? If the alternative is to do nothing (no whitelisting, no user
impairment notification) that is clear the winner from the selfish POV. But
if the choice is between whitelisting and alerting, I don't see much
difference between the two. Both could benefit from joint activities, but
both can also be operated in an ad-hoc fashion.
editorial:
----------
7.3.7. Additional Implications If Deployed On An Ad Hoc Basis
Additional implications, should this be deployed on an ad hoc basis,
could include scalability problems relating to operational processes,
monitoring, and ACL updates.
... this could be read to imply that S 7.3.1-6 would be applicable to
universal deployment. This is not what is meant. Maybe clarify somewhat
like as follows:
Previous subsections described implications that apply to both ad-hoc and
universal deployment models. Some additional implications are specific
to ad-hoc deployment models, namely ...
[JL] Great suggestion! I have made this change.
S 7.5
governmental, and/or cultural conflicts, given the new control point
which has be established with DNS whitelisting. For example, in one
s/be/been/
[JL] Corrected
[IPv6 Brokenness]
Anderson, T., "Measuring and Combating IPv6 Brokenness",
Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
s/2011/2010/
[JL] Corrected
Thanks again,
Jason
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf