Considerations for Transitioning Content to IPv6
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Considerations for Transitioning Content to IPv6) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Considerations for Transitioning Content to IPv6'
  as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes considerations for the transition of end user
  content on the Internet to IPv6.  While this is tailored to address
  end user content, which is typically web-based, many aspects of this
  document may be more broadly applicable to the transition to IPv6 of
  other applications and services.  This document explores the
  challenges involved in the transition to IPv6, potential migration
  tactics, possible migration phases, and other considerations.  The
  audience for this document is the Internet community generally,
  particularly IPv6 implementers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/


No IPR declarations have been submitted directly on this I-D.

[Ballot discuss]
I'm not seeing that this revision went through IETF LC. Given the scope of the changes, laying down a record confirming IETF consensus seems prudent.

[Ballot comment]
I have cleared my Discuss. Thank for such a major edit of the document.

(FWIW I think the document should be re-reviewed in the IESG before approval and I don't know if various last calls have been completed with the document, but I'm happy with it.)

[Ballot comment]
I cleared my Discuss.

Updated on 2012/1/20.

1. (cleared)

2. Throughout section 5, "domains" are anthropomorphized to "choose to
use [whitelisting]," "view DNS Whitelisting [...]," "transition to
IPv6," etc.  At the risk of pedantic clunkiness of style, as an
example I suggest:

OLD:

  However, there is clear consensus that DNS Whitelisting can
  be a useful tactic a domain may choose to use as they transition to
  IPv6.

NEW:

  However, there is clear consensus that DNS Whitelisting can
  be a useful tactic an administrator can use during the transition
  of a domain to the use of IPv6 transport.

or NEW:

  However, there is clear consensus that DNS Whitelisting can be a
  useful tactic for use during the transition of a domain to IPv6
  transport.

[Ballot comment]
Updated to reflect feedback on rev -06 (2011/6/21).

1. The following edited text in section 4 is intended, in part, to
address one of my Discuss points:

  Implementers are attempting to protect users of their domain from
  having a negative experience (poor performance) when they receive DNS
  response containing AAAA resource records or when attempting to use
  IPv6 transport.  There are two concerns which relate to this
  practice; one of which relates to IPv6-related impairment and the
  other which relates to the maturity or stability of IPv6 transport
  for high-traffic domains.  Both can negatively affect the experience
  of end users.

I find this text confusing as (a) it sort of mixes the method with the
outcome and (b) I didn't understand the two concerns at first
reading.  I suggest:

  Implementers use IPv6 AAAA DNS Whitelisting to protect users of
  their domain from having a negative experience (poor performance)
  because of potential problems with IPv6 transport to the domain.
  There are two primary problems to be avoided: IPv6-related
  impairment in which the end-to-end IPv6 transport between the user
  and the domain leads to a negative experience and the maturity,
  scalability and stability of the IPv6 transport at the domain.


2. Throughout section 8, "domains" are anthropomorphized to "choose to
use [whitelisting]," "view DNS Whitelisting [...]," "transition to
IPv6," etc.  At the risk of pedantic clunkiness of style, as an
example I suggest:

OLD:

  However, there is clear consensus that DNS Whitelisting can
  be a useful tactic a domain may choose to use as they transition to
  IPv6.

NEW:

  However, there is clear consensus that DNS Whitelisting can
  be a useful tactic an administrator can use during the transition
  of a domain to the use of IPv6 transport.

or NEW:

  However, there is clear consensus that DNS Whitelisting can be a
  useful tactic for use during the transition of a domain to IPv6
  transport.

[Ballot discuss]
Updated to reflect feedback on rev -06 (2011/6/21).

The text describing "universal deployment," specifically section 5.1,
has been edited to indicated that it is "harmful and problematic."  In
my opinion, the text is sufficiently speculative and vague so as not
to be useful:

  "which could also involve using [a] centralized registry..."

  "DNS Whitelisting functionality would need to be built into [...]
  DNS server software"

  "operators of [...] DNS servers would have to upgrade their
  software"

  "New IETF[...] (RFC) documents may need to be completed [...]"

I don't find that the text in section 5.1 supports the conclusion in
the last sentence of section 5.1.  I suggest that the text about
universal deployment be removed from the document.

[Ballot comment]
- Spaces in references are odd and may break some tools. Be better
not do to that I think. Example: "[Evaluating IPv6 Adoption]"

- I'm not sure the reference to world IPv6 day should stay,
it'll be outdated just after an RFC issues so why bother?
(Describing what happens in June in retrospect will be very
interesting but this bit isn't.)

[Ballot discuss]
My original discuss said:

"I don't think the language used to describe the "universal deployment"
option is sufficiently negative. For example, I would like to see the phrase
"considered harmful" liberally scattered whenever this option is described.
Would/did the WG consider adding such a statement at the front of the
document to send out a clear signal? The current text is far too even-handed
IMO, even though it makes what appears to be all the very telling arguments
against doing that."

Version-04 is a real improvement, (thanks) and says that a -05 will be
coming so I've split the remaining parts of my discuss into a few more
easily actionable parts.

(1) One specific change I'd like in -05 is as follows -  page 6 of -04 says:

  Finally, DNS Whitelisting can be deployed in two primary ways:
  universally on a global basis, or on an ad hoc basis.

I'd like that to say something like:

  Finally, DNS Whitelisting could possibly be deployed in two ways:
  universally on a global basis, (though that would be considered
  harmful and is just covered to show why this is the case), or,
  more realistically, on an ad hoc basis.

(2) I think section 6 still makes "universal" deployment sound much
more realistic than it really is. I'd like to see that rephrased to make
it clear that universal deployment is really just a reductio-ad-absurdum
argument. If that's not the case, then I think the main point of
my original discuss remains.

As an example of the kind of change I'd like, the intro to section
6 in -04 says:

  In considering how DNS Whitelisting may emerge more widely, there are
  two main deployment scenarios, which are explored below.

I'd suggest:

  In considering how DNS Whitelisting may emerge more widely, there are
  two deployment scenarios explored below, one of which (the ad-hoc
  case) is realistic and may happen - the other (universal deployment) is
  really just described in order to highlight its difficulties and to allow
  us to show more clearly why it would be considered harmful.

That would also need a few further editorial changes in 6.2 to work with
that language.

(3) In 8.1 s/One obvious approach/One seemingly obvious approach/

[Ballot discuss]
I don't know what to do about this document. I'm not sure I can honestly recommend this as the IETF position about whitelisting. The document seems to diverge from what the practical reality is with content providers, which are using or considering various levels of white- and blacklisting solutions. I'm not sure if following the recommendations of the document will increase or decrease IPv6 adoption. In addition, I think the document takes a very black and white position. Maybe  would like the document more if it would have made some recommendations on reducing the effects of whitelisting, reducing the duration of whitelisting, standardizing/centralizing some tasks, listing additional things providers need to employ, etc.

But I realize this is not a very actionable comment. I do want to talk about this situation on the call.

[Ballot discuss]
I don't know what to do about this document. I'm not sure I can honestly recommend this as the IETF position about whitelisting. The document seems to diverge from what the practical reality is with content providers, and I'm not sure if following the recommendations of the document will increase or decrease IPv6 adoption. In addition, I think the document takes a very black and white position. Maybe it should have made some recommendations on reducing the effects of whitelisting, reducing the duration of whitelisting, standardizing/centralizing some tasks, etc.

But I realize this is not a very actionable comment. I do want to talk about this situation on the call.

[Ballot comment]
o  DNS whitelisting is a very different behavior from the current
      practice concerning the publishing of IPv4 address resource
      records,

But location-based DNS responses and other practices are widely deployed in the IPv4 Internet, and while whitelisting differs substantially from them, I think we should not pretend that DNS operates in its original pure fashion either.

  In practice, DNS whitelisting generally means that a very small
  fraction of the DNS recursive resolvers on the Internet (those in the
  whitelist ACL) will receive AAAA responses.

Hmm. I'm not sure this corresponds to reality in all cases. For instance, a certain large content provider reported that their whitelist contained most of the assigned IPv6 address space.

  Finally, DNS whitelisting can be deployed in two primary ways:
  universally on a global basis, or on an ad hoc basis.  Deployment on
  a universal deployment basis means that DNS whitelisting is
  implemented on all authoritative DNS servers, across the entire
  Internet.  In contrast, deployment on an ad hoc basis means that only
  some authoritative DNS servers, and perhaps even only a few,
  implement DNS whitelisting.  These two potential deployment models
  are described in Section 6.

I think the universal deployment model is so obviously unworkable that I don't even know why this it is brought up here. And I'm not sure why we need to call the other alternative "ad hoc" -- it comes down to network managers making their own decisions as to whether they believe they need whitelisting (or IPv6 to begin with, or DNSSEC, or ...) There is no universal deployment for any feature in an internet-wide fashion!

Also, in reality there are different shades of universality. Groups of content providers may work together on a joint model, through an RIR, standards could be written or common open source tools or databases be employed. The split between "universal" and "ad hoc" misses all these nuances.

  As noted in Section 1, domains which implement DNS whitelisting are
  attempting to protect a few users of their domain, who have impaired
  IPv6 access, from having a negative experience (poor performance).
  While it is outside the scope of this document to explore the various
  reasons why a particular user's system (host) may have impaired IPv6
  access, for the users who experience this impairment it is a very
  real performance impact.

In a lot of cases, its not about a performance impact. Application behavior and timeouts may not be at all reasonable for recovering a wrong choice.

  There are a number of potential implications relating to DNS
  whitelisting, which have been raised as concerns by some parts of the
  Internet community.  Many of those potential implications are further
  enumerated here and in Section 7.

Are you implying that there is more? If so, maybe it should be described. If not, just say "Those potential implications are ..."

  While in Section 1 the level of IPv6-related impairment has been
  estimated to be as high as 0.078% of Internet users, which is a
  primary motivation cited for the practice of DNS whitelisting, it is
  not clear if the level of IPv4-related impairment is more or less
  that this percentage (which in any case is likely to have declined
  since its original citation).  Indeed, as at least one document
  reviewer has pointed out, it may simply be that websites are only
  measuring IPv6 impairments and not IPv4 impairments, whether because
  IPv6 is new or whether those websites are simply unable to or are
  otherwise not in a position to be able to measure IPv4 impairment
  (since this could result in no Internet access whatsoever).

I have measured IPv4 and IPv6 impairments alongside each other. The IPv6 impairments *are* bigger. The IPv4 impairments are not insignificant, however. My measurements were not about the case of a large, well-managed content provider being accessible by randomly picked individual users or networks, it was the reverse. But it goes to show that there is significant breakage in both the IPv4 and IPv6 Internet and that IPv6 breakage is often bigger. I for one do not fault the content providers for trying to ensure that their content is as widely accessible as possible.

  Also, it is possible that DNS whitelisting could affect some of the
  architectural assumptions which underlie parts of Section 2 of
  [RFC4213] which outlines the dual stack approach to the IPv6
  transition.  DNS whitelisting could modify the behavior of the DNS,
  as described in Section 2.2 of [RFC4213] and could require different
  sets of DNS servers to be used for hosts that are (using terms from
  that document) IPv6/IPv4 nodes, IPv4-only nodes, and IPv6-only nodes.
  As such, broad use of DNS whitelisting may necessitate the review
  and/or revision of standards documents which describe dual-stack and
  IPv6 operating modes, dual-stack architecture generally, and IPv6
  transition methods, including but not limited to [RFC4213].

I think this worry is a little bit overstated.

  An unfortunate implication of the adoption of DNS whitelisting may be
  the encouragement of a reversal of this trend, which would be a move
  back towards greater levels of homogeneity.  In this case, a domain
  owner which has implemented DNS whitelisting may prefer greater
  levels of control be exerted over end user hosts (which broadly
  includes all types of end user software and hardware) in order to
  attempt to enforce technical standards relating to establishing
  certain IPv6 capabilities or the enforcing the elimination of or
  restriction of certain end user hosts.  While the domain operator is
  attempting to protect, maintain, and/or optimize the end user
  experience for their domain, the collective result of many domains
  implementing DNS whitelisting, or even a few major domains (meaning
  domains which are a major destination of Internet traffic)
  implementing DNS whitelisting, may be to encourage a return to more
  homogenous and/or controlled end user hosts.  This could have
  unintended side effects on and counter-productive implications for
  future innovation at the edges of the network.

As above.

  As noted in Section 4, the implications of DNS whitelisting may drive
  end users and/or networks to delay, postpone, or cancel adoption of
  IPv6, or to actively seek alternatives to it.  Such alternatives may
  include the use of multi-layer network address translation (NAT)
  techniques like NAT444 [I-D.shirasaki-nat444], which these parties
  may decide to pursue on a long-term basis to avoid the perceived
  costs and aggravations related to DNS whitelisting.  This could of
  course come at the very time that the Internet community is trying to
  get these very same parties interested in IPv6 and motivated to begin
  the transition to IPv6.  As a result, parties that are likely to be
  concerned over the negative implications of DNS whitelisting could
  logically be concerned of the negative effects that this practice
  could have on the adoption of IPv6 if it became widespread or was
  adopted by majors Internet domains or other major parties in the
  Internet ecosystem.

  At the same time, as noted in Section 3, some highly-trafficked
  domains may find the prospect of transitioning to IPv6 daunting
  without having some short-term ability to incrementally control the
  amount and source of IPv6 traffic to their domains.

I think these different viewpoints would have deserved a more equal treatment. For instance, it is not at all clear to me why whitelisting drives NAT444 while inability to gradually turn on IPv6 in a controlled manner doesn't.

In general, Section 7 seems to be written as a critique of the whitelisting practices, not as a comparison of the different implications of choosing to either deploy or not deploy whitelisting.

  8.1. Implement DNS Whitelisting Universally
  8.2. Implement DNS Whitelisting On An Ad Hoc Basis
  8.3. Do Not Implement DNS Whitelisting

I think that this set of options is not a very good one. Option 1 is clearly impossible for any technology, option 2 is even named in a manner that makes it obvious that the document doesn't prefer it, and option 3 has well known issues. One of the things that would have helped this document is to not contrast the extremes but to highlight practices that are preferred/not preferred. For instance, I think developing common whitelisting databases and tools, temporary whitelisting, moving later to blacklisting and eventually to no-listing-at-all would all be useful actions.  Trying to deny the need for content providers to have some control of how their network is accessed will IMO likely result in less or no IPv6 deployment. Fortunately, the good news is that I think the Internet is moving forward and hopefully we can grow out of whitelisting into blacklist and no listing at all.

  8.3.2. Gain Experience Using IPv6 Transition Names

  Another alternative is for domains to gain experience using an FQDN
  which has become common for domains beginning the transition to IPv6;
  ipv6.example.com and www.ipv6.example.com.  This can be a way for a
  domain to gain IPv6 experience and increase IPv6 use on a relatively
  controlled basis, and to inform any plans for DNS whitelisting with
  experience.

And that's one of the other alternatives that are not so extreme. However, I think for much of the premier content in Internet, we're already past this. Been there done that. We need more IPv6 deployment than this can give.

  However, there is clear consensus that DNS whitelisting is
  at best a useful temporary measure which a domain may choose to
  pursue as they prepare for the transition to IPv6.  In particular,
  some major domains view DNS whitelisting as one of the few practical
  and low risk approaches enabling them to prepare for the transition
  to IPv6.  Thus, DNS whitelisting is not a recommended practice over
  the long-term.  In addition, DNS whitelisting should be avoided
  wherever possible in the short-term and its use is generally
  discouraged.

The last sentence does not seem to match the earlier sentences.

[Ballot comment]
o  DNS whitelisting is a very different behavior from the current
      practice concerning the publishing of IPv4 address resource
      records,

But location-based DNS responses and other practices are widely deployed in the IPv4 Internet, and while whitelisting differs substantially from them, I think we should not pretend that DNS operates in its original pure fashion either.

  In practice, DNS whitelisting generally means that a very small
  fraction of the DNS recursive resolvers on the Internet (those in the
  whitelist ACL) will receive AAAA responses.

Hmm. I'm not sure this corresponds to reality in all cases. For instance, a certain large content provider reported that their whitelist contained most of the assigned IPv6 address space.

  Finally, DNS whitelisting can be deployed in two primary ways:
  universally on a global basis, or on an ad hoc basis.  Deployment on
  a universal deployment basis means that DNS whitelisting is
  implemented on all authoritative DNS servers, across the entire
  Internet.  In contrast, deployment on an ad hoc basis means that only
  some authoritative DNS servers, and perhaps even only a few,
  implement DNS whitelisting.  These two potential deployment models
  are described in Section 6.

I think the universal deployment model is so obviously unworkable that I don't even know why this it is brought up here. And I'm not sure why we need to call the other alternative "ad hoc" -- it comes down to network managers making their own decisions as to whether they believe they need whitelisting (or IPv6 to begin with, or DNSSEC, or ...) There is no universal deployment for any feature in an internet-wide fashion!

Also, in reality there are different shades of universality. Groups of content providers may work together on a joint model, through an RIR, standards could be written or common open source tools or databases be employed. The split between "universal" and "ad hoc" misses all these nuances.

  As noted in Section 1, domains which implement DNS whitelisting are
  attempting to protect a few users of their domain, who have impaired
  IPv6 access, from having a negative experience (poor performance).
  While it is outside the scope of this document to explore the various
  reasons why a particular user's system (host) may have impaired IPv6
  access, for the users who experience this impairment it is a very
  real performance impact.

In a lot of cases, its not about a performance impact. Application behavior and timeouts may not be at all reasonable for recovering a wrong choice.

  There are a number of potential implications relating to DNS
  whitelisting, which have been raised as concerns by some parts of the
  Internet community.  Many of those potential implications are further
  enumerated here and in Section 7.

Are you implying that there is more? If so, maybe it should be described. If not, just say "Those potential implications are ..."

  While in Section 1 the level of IPv6-related impairment has been
  estimated to be as high as 0.078% of Internet users, which is a
  primary motivation cited for the practice of DNS whitelisting, it is
  not clear if the level of IPv4-related impairment is more or less
  that this percentage (which in any case is likely to have declined
  since its original citation).  Indeed, as at least one document
  reviewer has pointed out, it may simply be that websites are only
  measuring IPv6 impairments and not IPv4 impairments, whether because
  IPv6 is new or whether those websites are simply unable to or are
  otherwise not in a position to be able to measure IPv4 impairment
  (since this could result in no Internet access whatsoever).

I have measured IPv4 and IPv6 impairments alongside each other. The IPv6 impairments *are* bigger. The IPv4 impairments are not insignificant, however. My measurements were not about the case of a large, well-managed content provider being accessible by randomly picked individual users or networks, it was the reverse. But it goes to show that there is significant breakage in both the IPv4 and IPv6 Internet and that IPv6 breakage is often bigger. I for one do not fault the content providers for trying to ensure that their content is as widely accessible as possible.

[Ballot comment]
In practice, DNS whitelisting generally means that a very small
  fraction of the DNS recursive resolvers on the Internet (those in the
  whitelist ACL) will receive AAAA responses.

Hmm. I'm not sure this corresponds to reality in all cases. For instance, a certain large content provider reported that their whitelist contained most of the assigned IPv6 address space.

  Finally, DNS whitelisting can be deployed in two primary ways:
  universally on a global basis, or on an ad hoc basis.  Deployment on
  a universal deployment basis means that DNS whitelisting is
  implemented on all authoritative DNS servers, across the entire
  Internet.  In contrast, deployment on an ad hoc basis means that only
  some authoritative DNS servers, and perhaps even only a few,
  implement DNS whitelisting.  These two potential deployment models
  are described in Section 6.

I think the universal deployment model is so obviously unworkable that I don't even know why this it is brought up here. And I'm not sure why we need to call the other alternative "ad hoc" -- it comes down to network managers making their own decisions as to whether they believe they need whitelisting (or IPv6 to begin with, or DNSSEC, or ...) There is no universal deployment for any feature in an internet-wide fashion!

Also, in reality there are different shades of universality. Groups of content providers may work together on a joint model, through an RIR, standards could be written or common open source tools or databases be employed. The split between "universal" and "ad hoc" misses all these nuances.

[Ballot comment]
From Section 2:

  for some on the
  authorized whitelist

"for all"?  Why would just "some" on the authorized whitelist receive
the AAAA records?

In my opinion, "a few" should be dropped from the first sentence of
section 3.

My first reaction to the third paragraph of section 3 is that the
scenario described in the paragraph would be better solved by a
blacklist rather than a whitelist.  I'd like to know how the
scenario supports the whitelist solution.

In the fourth paragraph of section 4, s/networks,/networks;/

In section 8.2:
s/discovering that they a given domain/discovering that a given domain/

[Ballot discuss]
I would like to hear more about the reasons for including "universal
deployment" as a potential deployment scenario in this document.  Is
universal deployment in any way a realistic outcome?  Section 6.2
states:

  it is
  unlikely that DNS whitelisting would, at least in the next several
  years, become universally deployed

and lists several other conditions necessary for universal deployment.
Given all of these roadblocks, is there any real possibility of
universal deployment?

In section 3, in the interest of full disclosure, the way in which
whitelisting "protects [...] users of their domain [...] from having a
negative experience" is by only allowing users who resolve the domain
in question from a whitelisted recursive resolver to have IPv6 access
to the domain.

What would make whitelisting go away?

[Ballot comment]
- Spaces in references are odd and may break some tools. Be better
not do to that I think. Example: "[Evaluating IPv6 Adoption]"

- I'm not sure the reference to world IPv6 day should stay,
it'll be outdated just after an RFC issues so why bother?
(Describing what happens in June in retrospect will be very
interesting but this bit isn't.)

[Ballot discuss]
I don't think the language used to describe the "universal deployment"
option is sufficiently negative. For example, I would like to see the phrase
"considered harmful" liberally scattered whenever this option is described.
Would/did the WG consider adding such a statement at the front of the
document to send out a clear signal? The current text is far too even-handed
IMO, even though it makes what appears to be all the very telling arguments
against doing that.

Newby question for the IESG: If we as a group did consider that option
harmful, is it the kind of thing we'd add as IESG note? Is there a process
for that other than just discussing it on the telechat etc?

[Ballot comment]
At section 8.3, it does not follow from not implementing DNS whitelisting that the internet community
will "choose to take no action whatsoever". Please rephrase this to reflect the points made elsewhere
in the document that other approaches to ensuring a good experience during v4/v6 transition are being
pursued. Please consider pointing to the happy-eyeballs work.

[Ballot comment]
section 8 is "solutions", but it's not really clear what the problem is.  Not all of the solutions seem to help if the problem is that some users have suboptimal IPv6 experiences, so they aren't really solutions, so it seems like the problem is just lack of global advice or position on deployment plans for whitelisting?  Instead of describing solutions, this is really repetitive of section 6 on "likely deployment scenarios".  I would suggest combining these sections and not calling it solutions, as it is a bit confusing.

[Ballot discuss]
In section 7, it seems like there should be more discussion of what happens as (working) IPv6 deployments proceed, at some point possibly at a rapid pace, and the burden of adding to whitelists or dealing with requests for whitelist addition potentially grows quickly.

In the same vein, it seems like whitelists work well well when they're relatively short; will systems scale as the whitelists grow longer?

These concerns could lead to shared whitelists being commonly used and distributed amongst sites using rsync or similar means to reduce the admnistrative burden of updating them, but this has problems of paths between sites not being the same so there could not be a single universal whitelist, though there may be one that's close.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 AAAA DNS Whitelisting Implications'
  as an
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-04-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

This is the document shepherd writeup for
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 IPv6 AAAA DNS
Whitelisting Implications prepared 03/01/2011.

1.a Joel Jaeggli is the documnet shepherd. The document shepherd has
personally reviewed this version of the document and had previously
submitted a detailed review of draft 02 the document. The document
Shepherd belives that this version of the document is ready for publication.

1.b For it's intended scope and audience the document has received
extensive review. Reviewers and Operators not routinely involved in IETF
activities have contributed there thoughts to the consideration.
Significant commentary was received during last call which triggered the
subsequent revision into draft 03.

1.c The document shepherd has no such concerns. The document has been
socialized in DNSOP and V6OPS and among operational users of the approach.

1.d The Document Shepherd has no such concerns

1.e The working group has measurable consensus around the content and
concerns that the document expresses. There is an observation by some
participants in the working group about, both the relevance of so called
end-to-end principle concerns hilighted in a document and the utility
overall of a document, the concerns of which operators may chose to
ignore. The working group and indeed the objecting participants in
question can agreed that concerns are legitimate, and the general sense
is that highlighting the remains a valuable activity.

1.f Mildly dissenting participants were asked of the intended to do so,
they indicated that they had no intention of doing so. Draft-03 went
some if not all the way towards mollifying the concerns enumerated in 1.e

1.g idnits have been verified. The warning produced by the current
version of the idnits on draft-shirasaki-nat444 is incorrect.

1.h References are split between normative and informative. There are no
incomplete normative references.

1.i The document makes no requests of IANA

1.j No formal Language is present to require validation.

1.k

Technical Summary

The objective of this document is to describe what the whitelisting
of DNS AAAA resource records is, hereafter referred to as DNS
whitelisting, as well as the implications of this emerging practice
and what alternatives may exist. The audience for this document is
the Internet community generally, including the IETF and IPv6
implementers.

Working Group Summary

During the WGLC, Doug Barton captured the major criticism of the
document thusly:

However I return to my main premise which is:
1. 99.9% of the organizations who have chose this solution
already understand these issues, and
2. The 0.1% who don't, don't care.

While I think that's a valid concern I'm not sure that it results in
a lack of utility for the information present. Consensus squarely
favors publication and we feel that the document will be
informative and useful in it's present form.

Document Quality

There are implementers of V6 AAAA whitelisting who have weighed in
with their plans and comments on the content of the document.
significant effort has gone into obtaining community involvement
given the concerns that the document raises. The acknowledgments
include several deep reviews of the document.