Re: Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC

[Pekka Savola <[e-mail]>]

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.

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.

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.

......


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 ...

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/

    [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/