Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51249E0679; Tue, 31 May 2011 13:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.162 X-Spam-Level: X-Spam-Status: No, score=-108.162 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmje2MCnM6vc; Tue, 31 May 2011 13:30:28 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE49E0789; Tue, 31 May 2011 13:30:27 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128913207; Tue, 31 May 2011 16:30:17 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Tue, 31 May 2011 16:30:17 -0400 From: "Livingood, Jason" To: Dave Crocker Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* Thread-Index: AQHMH9GMnHR+sjqO9E6E35G4C6F/uA== Date: Tue, 31 May 2011 20:30:14 +0000 Message-ID: In-Reply-To: <4DE3B8FD.7040209@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.227.190] Content-Type: multipart/alternative; boundary="_000_CA0A98D728D62jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 31 May 2011 13:37:11 -0700 Cc: "v6ops@ietf.org" , IETF Discussion , Apps Review Subject: Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 20:30:31 -0000 --_000_CA0A98D728D62jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dave - Thanks for the additional feedback. Any changes noted below will be = made soon in a -06 update. See inline comments. Regards Jason On 5/30/11 11:34 AM, "Dave CROCKER" > wrote: (I see that you've posted -05. This response is for completeness.) On 5/29/2011 7:54 PM, Livingood, Jason wrote: [JL] Duly noted in my previous emails. I'm keeping the naming as an open is= sue in the =9604 and will be seeking WG and WG co-chair guidance one way or the= other. One of the reasons for cross-area review is to look for cross-area problems= . Separate from the legal formalities, the purpose of 'trademark' is to try t= o avoid market confusion. Market confusion was exactly the reason that I rai= sed concern about the naming and I wasn't the only one who noticed the problem.= (My original, informal posting was directly result of that confusion...) So I'm sorry to see that the naming conflict is felt to be irrelevant by th= ose running the working group. (I was also a little surprised to see that that= core of folk constitute working group rough consensus, for removing open items.) As for the actual term "whitelisting" I suppose we should admire the boldne= ss of the view that access to v6 is a priviledge -- note that that's the denotati= onal perspective of the word whitelisting... [JL] Duly noted. operator of a website, such as www.example.com, the operator essentially applies an access control list (ACL) on the authoritat= ive DNS servers for the domain example.com. The ACL is populated with An ACL usually is a yes/no mechanism. Here, however, the mechanism is = for asserting a preference for IPv6 over IPv4. That does not seem to match the definition of ACL that I'm used to, un= less the semantic is defined as denying IPv4 access to the listed clients. The term ACL is particularly odd to use if the mechanism pertains to r= esponses rather than queries. [JL] I am using 'ACL' in the most general possible sense and am open to alternative descriptors if you wish to suggest one. But most people seem to= know an ACL is a list that, if you are listed on it, grants you access to some resource. In this case if the resolver is on the list then it gets AAAA RRs= . On reflection, the term is growing on me for this use. "AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good labels. They provide useful, direct and precise meaning, while avoiding th= e various referential and denotational problems of a loaded term like whiteli= st. [JL] Great! And I like thinking about it more in terms of granting "access"= to AAAA RRs than viewing it as "blocking" AAAA RRs, as I find access contr= ol a more neutral term and one that is still easy to understand conceptuall= y. [JL] I took a stab at a new diagram in =9604 =97 so take a look and let me = know if it is what you are suggesting (I've left the original one in for now). Took a quick look at the added diagram in the new draft. The thing about a protocol timeline diagram is that it uses verticality to provide ordering. = So a response is lower down than a request. I don't get that from your Figure 2. [JL] Oh! Now I understand what you were asking for. See my email under sepa= rate cover with an example to see if I am getting closer. Others can see wh= at I now have in draft form at https://img.skitch.com/20110531-j1r2ubr43273= fd9i8xuj6btyn9.jpg (By the way, your first sub-scenario, with Resolver 1, shows only a v4 resp= onse, without indicating whether the resolver sent a v6 or v4 query. For the rev= iew, I think this distinction between transport and data -- "how is the query/response transported" vs. "what RRs are returned" -- was a continuing point of confusion for me. ) [JL] Ack. I'll add an extra note at the top of the diagram to clarify that = the access control logic is independent of whether IPv6 transport is used b= etween the host and resolver, or resolver and authority. At least one highly-trafficked domain has noted that they have received requests to not send DNS responses with AAAA resource records to particular resolvers. In this case, the operators of "At least one" seems a rather tiny statistic. Perhaps the actual stati= stic is significantly larger? [JL] It does not seem to be. Other than this being passed along by Google, = I've not heard of any similar stories. Nevertheless, it seemed interesting enoug= h to include. As an anecdote, it is perhaps interesting. As a basis for promoting the en= tire effort, not so much. I couldn't tell which role it was serving, but it fel= t like the latter. network infrastructure is not yet ready to handle the large traffi= c volume which may be associated with the hosts in their network connecting to the websites of these domains. This concern is clear= ly So even though the site allows v6 DNS queries to go out from a host, i= t can't really support having the host use v6? [JL] A network isn't really in control of the end host's limitations w/r/t = IPv6 impairment. A good summary of the issue of impairment is @ http://www.fud.n= o/ipv6/ That sort of commentary, along with the citation, might be good to include,= for clarification. [JL] Done. 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 8 hundredths of one percent? I think that that's 8 of every 10,000 Internet users? That's considered a high percentage? [JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that rate, it'd be cheaper and easier for me (an ISP) to just buy new computers = for the affected "impaired" users than to have to navigate years of whitelistin= g with a variety of domains. In any case, one recent measurement estimates it= at 0.05% now and another at 0.015%. Despite this, this practice is still gener= ating some interest. I'm hoping World IPv6 Day goes well and is informative for t= he community as to this percentage on a widespread basis, across a wide variet= y of web sites. Even if it is 8%, is that considered high? [JL] 8% of the Internet finding google.com or facebook.com inaccessible wou= ld be bad for everyone. That could generate several hundred thousand support call= s per day to a big ISP. On reflection, I'm surprised to hear that IPv6 usage is up as high as 8 out= of every 10,000 users, nevermind a large multiple of that. (Although it does = carry a backhanded note of encouragement about v6 adoption, I'm a bit suspicious = of the statistic.) [JL] Important to keep in mind that the IPv6-impairment occurs in situation= s where someone usually does not have functioning IPv6 transport =97 just s= eeing the AAAA RR causes issues. troubleshooting standpoint. In this scenario, a DNS recursive resolver operator will have no way to systematically determine whether DNS whitelisting is or is not implemented for a domain, si= nce the absence of AAAA resource records may simply be indicative that the domain has not yet added IPv6 addressing for the domain, rathe= r than that they have done so but have restricted query access via D= NS The premise is that, in large scale use, servers /will/ have a way to systematically determine whether it is implemented? What are the exist= ing examples of having such a capability for other Internet protocols and = services? [JL] Perhaps I'm overplaying this point, but you know someone has email ser= vice if they have an MX record for example, or a website if the host answers on TCP/80. But as I re-read this it is probably overkill and so I've deleted i= t. I have however moved some of the text to a prior section, since determining whether or not domains are whitelisting is still a challenge at scale. Note that a site can have email service without an MX and that TCP:80 is no= t merely an "indicator" of web service, but actually /is/ the web service. My point is that this idea of signaling/registering support of a service, a= s separate from actually providing the service, is not part of typical Intern= et service requirements and the simplification this provides is significant. = We need to be careful that we do not inadvertently teach folks that "signaling support" is an expected feature. (And with this response, given that you already deleted the text, it's my t= urn to overplay a point...) nature, not to mention physics. For example, as Sir Issac Newton noted, "Every object in a state of uniform motion tends to remain = in that state of motion unless an external force is applied to it" [L= aws Code does not have momenum. Neither do configurations or lists. This r= eally isn't about physics. [JL] But people and processes do have (operational) momentum=85 Indeed, and the process of dealing with the naming issue for this does seem= to show that... It is entirely about group psychology, as you note, and the administra= tive challenges in the logistics of large-scale operational changes (which = probably /does/ have something to with physics, but it seems a stretch to credi= t Newton. How about Heisenberg?...) [JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an inter= esting citation I feel it's almost a personal challenge to figure out a way to kee= p it in there. ;-) How certain of it's being a challenge are you? Does your certainty change = as you think about it? [JL] I'm not wed to the reference. It was suggested earlier in the developm= ent of the document. If you have any better reference to the notion of mome= ntum taking some effort to slow, I'm open to that. The way I think about it is that in 5 or 10 years none of the people working on the details of the IPv6 transition now will still be invo= lved in the day-to-day operational work. But DNS Whitelisting could still be in = place =96 and once something gets a momentum to it (people, processes, and organizations) it is really, really hard to change that. Well, I seriously applaud that concern, especially since its validity is pr= oven every day (including in the IETF...) On the average, I tend to believe that the best way to instruct folks later= is by imparting information about tradeoffs and, especially, cost vs. benefit. In the current case, the near-term cost/benefit makes some sense. In the long term, the scaling cost of maintenance and the architectural cos= t of losing spontaneous interoperability strike me as pretty f'ing expensive. 8.3. Do Not Implement DNS Whitelisting As an alternative to adopting DNS whitelisting, the Internet community generally can choose to take no action whatsoever, perpetuating the current predominant authoritative DNS operational model on the Internet, and leave it up to end users with IPv6-rela= ted impairments to discover and fix those impairments. That is, place the burden of fixing a problem on those creating it? [JL] In a way. It gets back to the question you asked about what level of impairment justifies this practice. One obvious option is to let end users = sort it out (presumably by consulting with their ISPs / network operators). This= may be simpler and it's the way solutions to non-IPv6 problems tend to work tod= ay. On the average, demanding that an end-user make an explicit decision about = an operational tuning issue does not work very well. [JL] Thanks again for your feedback! Jason d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --_000_CA0A98D728D62jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Dave - Thanks for the additional feedback. Any changes noted below wil= l be made soon in a -06 update. See inline comments.

Regards
Jason

On 5/30/11 11:34 AM, "Dave CROCKER" <dhc@dcrocker.net> wrote:

(I see that you've posted -05.  This response is for complet= eness.)

On 5/29/2011 7:54 PM, Livingood, Jason wrote:
[JL] Duly noted in my previous emails. I'm keeping the naming as an op= en issue
in the =9604 and will be seeking WG and WG co-chair guidance one way o= r the other.

One of the reasons for cross-area review is to look for cross-area pro= blems.

Separate from the legal formalities, the purpose of 'trademark' is to = try to
avoid market confusion.  Market confusion was exactly the re= ason that I raised
concern about the naming and I wasn't the only one who noticed the pro= blem.  (My
original, informal posting was directly result of that confusion...)

So I'm sorry to see that the naming conflict is felt to be irrelevant = by those
running the working group.  (I was also a little surprised t= o see that that core
of folk constitute working group rough consensus, for removing open it= ems.)

As for the actual term "whitelisting" I suppose we should ad= mire the boldness of
the view that access to v6 is a priviledge -- note that that's the den= otational
perspective of the word whitelisting...

[JL] Duly noted. 

         operator of a website, such as www.e= xample.com, the operator
         essentially applies a= n access control list (ACL) on the authoritative
         DNS servers for the d= omain example.com. The ACL is populated with

     An ACL usually is a yes/no mechanism. Here, h= owever, the mechanism is for
     asserting a preference for IPv6 over IPv4.

     That does not seem to match the definition of= ACL that I'm used to, unless the
     semantic is defined as denying IPv4 access to= the listed clients.

     The term ACL is particularly odd to use if th= e mechanism pertains to responses
     rather than queries.


[JL] I am using 'ACL' in the most general possible sense and am open t= o
alternative descriptors if you wish to suggest one. But most people se= em to know
an ACL is a list that, if you are listed on it, grants you access to s= ome
resource. In this case if the resolver is on the list then it gets AAA= A RRs.

On reflection, the term is growing on me for this use.

"AAAA ACL" or "V6 DNS ACL" or "V6 resolver AC= L" now seem to me quite good
labels.  They provide useful, direct and precise meaning, wh= ile avoiding the
various referential and denotational problems of a loaded term like wh= itelist.

[JL] Great! And I like thinking about it more in terms of granting &qu= ot;access" to AAAA RRs than viewing it as "blocking" AAAA RR= s, as I find access control a more neutral term and one that is still easy = to understand conceptually.

[JL] I took a stab at a new diagram in =9604 =97 so take a look and le= t me know if
it is what you are suggesting (I've left the original one in for now).=

Took a quick look at the added diagram in the new draft.  Th= e thing about a
protocol timeline diagram is that it uses verticality to provide order= ing.  So a
response is lower down than a request. I don't get that from your Figu= re 2.

[JL] Oh! Now I understand what you were asking for. See my email under= separate cover with an example to see if I am getting closer. Others can s= ee what I now have in draft form at https://img.skitch.com/20110531-j1= r2ubr43273fd9i8xuj6btyn9.jpg 


(By the way, your first sub-scenario, with Resolver 1, shows only a v4= response,
without indicating whether the resolver sent a v6 or v4 query. &n= bsp;For the review,
I think this distinction between transport and data -- "how is th= e
query/response transported" vs. "what RRs are returned"= -- was a continuing
point of confusion for me. )

[JL] Ack. I'll add an extra note at the top of the diagram to clarify = that the access control logic is independent of whether IPv6 transport is u= sed between the host and resolver, or resolver and authority.

         At least one highly-t= rafficked domain has noted that they have
         received requests to = not send DNS responses with AAAA resource
         records to particular= resolvers. In this case, the operators of


     "At least one" seems a rather tiny = statistic. Perhaps the actual statistic is
     significantly larger?


[JL] It does not seem to be. Other than this being passed along by Goo= gle, I've
not heard of any similar stories. Nevertheless, it seemed interesting = enough to
include.

As an anecdote, it is perhaps interesting.  As a basis for p= romoting the entire
effort, not so much.  I couldn't tell which role it was serv= ing, but it felt
like the latter.


         network infrastructur= e is not yet ready to handle the large traffic
         volume which may be a= ssociated with the hosts in their network
         connecting to the web= sites of these domains. This concern is clearly


     So even though the site allows v6 DNS queries= to go out from a host, it can't
     really support having the host use v6?


[JL] A network isn't really in control of the end host's limitations w= /r/t IPv6
impairment. A good summary of the issue of impairment is @ http://www.fud.no/ipv6/

That sort of commentary, along with the citation, might be good to inc= lude, for
clarification.

[JL] Done.



         While in Section 1 th= e level of IPv6-related impairment has been
         estimated to be as hi= gh as 0.078% of Internet users, which is a


     8 hundredths of one percent?

I think that that's 8 of every 10,000 Internet users?


     That's considered a high percentage?


[JL] It is. I joked at one of the v6ops WG meetings awhile ago that at= that
rate, it'd be cheaper and easier for me (an ISP) to just buy new compu= ters for
the affected "impaired" users than to have to navigate years= of whitelisting
with a variety of domains. In any case, one recent measurement estimat= es it at
0.05% now and another at 0.015%. Despite this, this practice is still = generating
some interest. I'm hoping World IPv6 Day goes well and is informative = for the
community as to this percentage on a widespread basis, across a wide v= ariety of
web sites.


     Even if it is 8%, is that considered high?


[JL] 8% of the Internet finding google.com or facebook.com inaccessibl= e would be
bad for everyone. That could generate several hundred thousand support= calls per
day to a big ISP.

On reflection, I'm surprised to hear that IPv6 usage is up as high as = 8 out of
every 10,000 users, nevermind a large multiple of that.  (Al= though it does carry
a backhanded note of encouragement about v6 adoption, I'm a bit suspic= ious of
the statistic.)

[JL] Important to keep in mind that the IPv6-impairment occurs in situ= ations where someone usually does not have functioning IPv6 transport =97 j= ust seeing the AAAA RR causes issues.

         troubleshooting stand= point. In this scenario, a DNS recursive
         resolver operator wil= l have no way to systematically determine
         whether DNS whitelist= ing is or is not implemented for a domain, since
         the absence of AAAA r= esource records may simply be indicative that
         the domain has not ye= t added IPv6 addressing for the domain, rather
         than that they have d= one so but have restricted query access via DNS


     The premise is that, in large scale use, serv= ers /will/ have a way to
     systematically determine whether it is implem= ented? What are the existing
     examples of having such a capability for othe= r Internet protocols and services?


[JL] Perhaps I'm overplaying this point, but you know someone has emai= l service
if they have an MX record for example, or a website if the host answer= s on
TCP/80. But as I re-read this it is probably overkill and so I've dele= ted it. I
have however moved some of the text to a prior section, since determin= ing
whether or not domains are whitelisting is still a challenge at scale.=

Note that a site can have email service without an MX and that TCP:80 = is not
merely an "indicator" of web service, but actually /is/ the = web service.

My point is that this idea of signaling/registering support of a servi= ce, as
separate from actually providing the service, is not part of typical I= nternet
service requirements and the simplification this provides is significa= nt.  We
need to be careful that we do not inadvertently teach folks that "= ;signaling
support" is an expected feature.

(And with this response, given that you already deleted the text, it's= my turn
to overplay a point...)

         nature, not to mentio= n physics. For example, as Sir Issac Newton
         noted, "Every ob= ject in a state of uniform motion tends to remain in
         that state of motion = unless an external force is applied to it" [Laws


     Code does not have momenum. Neither do config= urations or lists. This really
     isn't about physics.


[JL] But people and processes do have (operational) momentum=85

Indeed, and the process of dealing with the naming issue for this does= seem to
show that...


     It is entirely about group psychology, as you= note, and the administrative
     challenges in the logistics of large-scale op= erational changes (which probably
     /does/ have something to with physics, but it= seems a stretch to credit Newton.
     How about Heisenberg?...)


[JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an = interesting
citation I feel it's almost a personal challenge to figure out a way t= o keep it
in there. ;-)

How certain of it's being a challenge are you?  Does your ce= rtainty change as
you think about it?

[JL] I'm not wed to the reference. It was suggested earlier in the dev= elopment of the document. If you have any better reference to the notion of= momentum taking some effort to slow, I'm open to that.

  The way I think about it is that in 5 or 10 years none of = the
people working on the details of the IPv6 transition now will still be= involved
in the day-to-day operational work. But DNS Whitelisting could still b= e in place
=96 and once something gets a momentum to it (people, processes, and
organizations) it is really, really hard to change that.

Well, I seriously applaud that concern, especially since its validity = is proven
every day (including in the IETF...)

On the average, I tend to believe that the best way to instruct folks = later is
by imparting information about tradeoffs and, especially, cost vs. ben= efit.

In the current case, the near-term cost/benefit makes some sense.

In the long term, the scaling cost of maintenance and the architectura= l cost of
losing spontaneous interoperability strike me as pretty f'ing expensiv= e.


         8.3. Do Not Implement= DNS Whitelisting

         As an alternative to = adopting DNS whitelisting, the Internet
         community generally c= an choose to take no action whatsoever,
         perpetuating the curr= ent predominant authoritative DNS operational
         model on the Internet= , and leave it up to end users with IPv6-related
         impairments to discov= er and fix those impairments.


     That is, place the burden of fixing a problem= on those creating it?


[JL] In a way. It gets back to the question you asked about what level= of
impairment justifies this practice. One obvious option is to let end u= sers sort
it out (presumably by consulting with their ISPs / network operators).= This may
be simpler and it's the way solutions to non-IPv6 problems tend to wor= k today.

On the average, demanding that an end-user make an explicit decision a= bout an
operational tuning issue does not work very well.

[JL] Thanks again for your feedback!

Jason



d/

--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

--_000_CA0A98D728D62jasonlivingoodcablecomcastcom_-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C03E07E0 for ; Tue, 31 May 2011 09:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cV0dYwC5lVv for ; Tue, 31 May 2011 09:52:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6578AE080A for ; Tue, 31 May 2011 09:52:51 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p4VGqoVh003654 for ; Tue, 31 May 2011 09:52:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306860770; bh=FHJFYtd0YIhp+q1VU7ptc1HbeEk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hZUWWOHByBomA8TwGjEJytE6zo5hQe5EUu0PD6MAB2qwqcpSgNtyUT6qyFOaavpdh C5SoH2uGpiqlUvYQ13pSQ== Received: from gwj15 (gwj15.prod.google.com [10.200.10.15]) by kpbe13.cbf.corp.google.com with ESMTP id p4VGqmnP030069 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 31 May 2011 09:52:49 -0700 Received: by gwj15 with SMTP id 15so2751595gwj.25 for ; Tue, 31 May 2011 09:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=J9EVmdnRsMC9NjMrwJDjm7zZgMxbVn78n3r5YdWfj+E=; b=kVyMQYKwIvnD9V8gVA7kMYOdricoy0o7Yg9rS6iL7xJY0UsUVubO5X8ZetYAX1STQg IdrSM/Z0pHhbETJXggzw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iJX0AL3K7Hb6QipvsOW/5XPqP6b7hYD2IjK3pgWBva+06bsbUkE9pOWIrEY51EAOtD Fo+ZAigSo6vvyrpMyPxw== Received: by 10.151.24.10 with SMTP id b10mr5120949ybj.93.1306860768479; Tue, 31 May 2011 09:52:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Tue, 31 May 2011 09:52:28 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 31 May 2011 09:52:28 -0700 Message-ID: To: "Livingood, Jason" Content-Type: multipart/alternative; boundary=000e0cd23ef6e048bc04a4953bcf X-System-Of-Record: true X-Mailman-Approved-At: Tue, 31 May 2011 13:37:17 -0700 Cc: Joel Jaeggli , "v6ops@ietf.org" , Apps Review , IETF Discussion , Dave Crocker Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:52:57 -0000 --000e0cd23ef6e048bc04a4953bcf Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 31, 2011 at 6:17 AM, Livingood, Jason < Jason_Livingood@cable.comcast.com> wrote: > While you have not contributed text per se (by sending it directly), I > try to be a good listener and items you and other Googlers have raised have > been included in the document around motivations and so on. Even new > Sections 3.2 and 3.2 were added based on listening to you and/or your > colleagues talk about the issue (and some direct conversations a couple of > weeks ago). > Sure - anything said at the IETF and on mailing lists is subject to the note well. But I wouldn't want to be seen as having contributed to the document. Regards, Lorenzo --000e0cd23ef6e048bc04a4953bcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 31, 2011 at 6:17 AM, Livingood, Jaso= n <Jason_Livingood@cable.comcast.com> wrote:
While you have not contributed text per se (by sending it directly), I= try to be a good listener and items you and other Googlers have raised hav= e been included in the document around motivations and so on. Even new Sect= ions 3.2 and 3.2 were added based on listening to you and/or your colleagues talk about the issue (and some = direct conversations a couple of weeks ago).=A0

Sure - anything said at the IETF and on mailing lists is subject to the not= e well. But I wouldn't want to be seen as having contributed to the doc= ument.

Regards,
Lorenzo
--000e0cd23ef6e048bc04a4953bcf-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262EEE088B; Tue, 31 May 2011 09:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIn+kdR6sAPF; Tue, 31 May 2011 09:00:41 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 192B4E089F; Tue, 31 May 2011 09:00:35 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:41956) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QRRMu-00056L-Xz (Exim 4.72) (return-path ); Tue, 31 May 2011 17:00:32 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QRRMu-0002jL-Fe (Exim 4.67) (return-path ); Tue, 31 May 2011 17:00:32 +0100 Date: Tue, 31 May 2011 17:00:32 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Gert Doering In-Reply-To: <20110530154841.GM45955@Space.Net> Message-ID: References: <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch X-Mailman-Approved-At: Tue, 31 May 2011 13:37:08 -0700 Cc: "v6ops@ietf.org" , Apps Review , dcrocker@bbiw.net, IETF Discussion Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:00:50 -0000 Gert Doering wrote: > > Whitelisting, on the other hand, is the term that Google introduced for > this kind of "thing" and people seem to clearly understand what this > is about. "You are on my white list of people that I like talking to!". I think it's OK to refer to it as "whitelisting". I think it is confusing to refer to it as "DNS whitelisting". "Resolver whitelist" is better (it's a whitelist of resolvers) or perhaps "IPv6 whitelisting" (what members of the list are cleared to use) if you need a short phrase. Speaking of confusing, the first sentence of the abstract and introduction in the current revision of the draft is an abomination that should be taken out and shot. Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5 or 6 later. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B489E07B2; Tue, 31 May 2011 06:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.28 X-Spam-Level: X-Spam-Status: No, score=-108.28 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hVVgIrZ+Mww; Tue, 31 May 2011 06:23:04 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 97FC1E0850; Tue, 31 May 2011 06:22:31 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128628846; Tue, 31 May 2011 09:17:02 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Tue, 31 May 2011 09:17:02 -0400 From: "Livingood, Jason" To: Lorenzo Colitti , Joel Jaeggli Thread-Topic: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* Thread-Index: AQHMH17K/TZcHaXuhE61OwYpuBgohJSm60kA Date: Tue, 31 May 2011 13:17:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [24.40.55.72] Content-Type: multipart/alternative; boundary="_000_CA0A60E828C51jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 31 May 2011 08:08:22 -0700 Cc: "v6ops@ietf.org" , Apps Review , IETF Discussion , Dave Crocker Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:23:05 -0000 --_000_CA0A60E828C51jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 5/31/11 2:48 AM, "Lorenzo Colitti" > wrote: On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli > wrote: But you've contributed to this document, so have others from that list. I don't want to contribute to the document While you have not contributed text per se (by sending it directly), I try = to be a good listener and items you and other Googlers have raised have bee= n included in the document around motivations and so on. Even new Sections = 3.2 and 3.2 were added based on listening to you and/or your colleagues tal= k about the issue (and some direct conversations a couple of weeks ago). In any case, I appreciate your feedback and opinions. At the end of the day= it is only an informational I-D, and not a standard or BCP, so maybe not s= uch a big deal. Regards Jason --_000_CA0A60E828C51jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <953917ACD40B9D44A7C530ED48F84EB4@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 5/31/11 2:48 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:

On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli <= span dir=3D"ltr"> <joelja@bogus.com> wro= te:
But you've contributed to this document, so have others from that list= .

I don't want to contribute to the document

While you have not contributed text per se (by sending it directly), I= try to be a good listener and items you and other Googlers have raised hav= e been included in the document around motivations and so on. Even new Sect= ions 3.2 and 3.2 were added based on listening to you and/or your colleagues talk about the issue (and some = direct conversations a couple of weeks ago). 

In any case, I appreciate your feedback and opinions. At the end of th= e day it is only an informational I-D, and not a standard or BCP, so maybe = not such a big deal. 

Regards
Jason
--_000_CA0A60E828C51jasonlivingoodcablecomcastcom_-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD9EE07BD; Tue, 31 May 2011 00:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.088 X-Spam-Level: X-Spam-Status: No, score=-102.088 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MnKzUIu4+iS; Tue, 31 May 2011 00:00:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2B370E0798; Tue, 31 May 2011 00:00:47 -0700 (PDT) Received: from wifi-216-59.mtg.afnog.org ([196.200.216.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4V70NGI011412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 May 2011 07:00:31 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--46976651 From: Joel Jaeggli In-Reply-To: Date: Tue, 31 May 2011 00:00:21 -0700 Message-Id: References: <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net> <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 31 May 2011 07:00:38 +0000 (UTC) X-Mailman-Approved-At: Tue, 31 May 2011 08:08:56 -0700 Cc: IETF Discussion , "v6ops@ietf.org" , Dave Crocker , Gert Doering , Apps Review Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 07:00:49 -0000 --Apple-Mail-6--46976651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 30, 2011, at 11:48 PM, Lorenzo Colitti wrote: > On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli = wrote: > But you've contributed to this document, so have others from that = list. >=20 > I don't want to contribute to the document because - in my opinion, = and speaking only for myself - I don't think it can be made into a = balanced assessment of the issue without major changes. I do things that the ietf says are a bad idea all the time, I take the = concerns expressed in informational documents that I've read = under-advisement when I do so. > Since a) I don't have even a fraction of the time I would need to = actually contribute said changes, b) the document is already in an = advanced state of the IETF process, and c) it doesn't matter so much = what the document ends up saying, because most of the organizations for = whom this is an issue have already looked at the data and recognized = that they have no alternative, I was simply steering clear of the = document entirely. >=20 > It's true that I have pointed out things I think are incorrect. But I = did not view these as contributions, more as offering occasional token = opposition lest silence be interpreted as assent. :-) But perhaps you're = right and I should not comment on it at all. >=20 > Cheers, > Lorenzo --Apple-Mail-6--46976651 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On May 30, 2011, at 11:48 PM, Lorenzo Colitti wrote:

On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli <joelja@bogus.com> wrote:
But you've contributed to this document, so have others from that list.

I don't want to contribute to the document because - in my opinion, and speaking only for myself - I don't think it can be made into a balanced assessment of the issue without major changes.

I do things that the ietf says are a bad idea all the time, I take the concerns expressed in informational documents that I've read under-advisement when I do so.

Since a) I don't have even a fraction of the time I would need to actually contribute said changes, b) the document is already in an advanced state of the IETF process, and c) it doesn't matter so much what the document ends up saying, because most of the organizations for whom this is an issue have already looked at the data and recognized that they have no alternative, I was simply steering clear of the document entirely.

It's true that I have pointed out things I think are incorrect. But I did not view these as contributions, more as offering occasional token opposition lest silence be interpreted as assent. :-) But perhaps you're right and I should not comment on it at all.

Cheers,
Lorenzo

--Apple-Mail-6--46976651-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A51E07BD for ; Mon, 30 May 2011 23:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PPOPInUylBY for ; Mon, 30 May 2011 23:48:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3DE07D7 for ; Mon, 30 May 2011 23:48:27 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p4V6mQWp023951 for ; Mon, 30 May 2011 23:48:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306824507; bh=FrzuBnQOmnqgYtanwRJny9rAWyA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZVaYv33OPhS1ius2dgNhGuZJGxvim8WMMWcpSg/m4PvNHOqd3hinwFkwtUgZaPSJO N6mB6xWSkp1Y48KrTuuCg== Received: from yxa15 (yxa15.prod.google.com [10.190.1.15]) by kpbe20.cbf.corp.google.com with ESMTP id p4V6mPnX017702 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 30 May 2011 23:48:25 -0700 Received: by yxa15 with SMTP id 15so1713114yxa.9 for ; Mon, 30 May 2011 23:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MhH8+2cFafGleUo/wv6dxT+9tWBqPoMXgBW3PhkPITw=; b=M5Ob57nm9DGFHmQ9QEI5wMoblW2QjZr9DtOTG8154qYSEfhAHIFKep+TzCFqyQTwuA OO5izU6OLzZz/KiJP+1A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iPDKcWdPjEh2O0wp/mzj/mF+ntEcs6ZMi/qIpIMbgbiM9Be6RIM3fc0Ijhw+YPpLUn w5ymAJbedRbKrtH5cU/w== Received: by 10.150.113.20 with SMTP id l20mr4609357ybc.36.1306824505169; Mon, 30 May 2011 23:48:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Mon, 30 May 2011 23:48:04 -0700 (PDT) In-Reply-To: <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.com> References: <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net> <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.com> From: Lorenzo Colitti Date: Mon, 30 May 2011 23:48:04 -0700 Message-ID: To: Joel Jaeggli Content-Type: multipart/alternative; boundary=000e0cd568306a19da04a48cca65 X-System-Of-Record: true X-Mailman-Approved-At: Tue, 31 May 2011 08:09:25 -0700 Cc: IETF Discussion , "v6ops@ietf.org" , Dave Crocker , Gert Doering , Apps Review Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 06:48:28 -0000 --000e0cd568306a19da04a48cca65 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli wrote: > But you've contributed to this document, so have others from that list. > I don't want to contribute to the document because - in my opinion, and speaking only for myself - I don't think it can be made into a balanced assessment of the issue without major changes. Since a) I don't have even a fraction of the time I would need to actually contribute said changes, b) the document is already in an advanced state of the IETF process, and c) it doesn't matter so much what the document ends up saying, because most of the organizations for whom this is an issue have already looked at the data and recognized that they have no alternative, I was simply steering clear of the document entirely. It's true that I have pointed out things I think are incorrect. But I did not view these as contributions, more as offering occasional token opposition lest silence be interpreted as assent. :-) But perhaps you're right and I should not comment on it at all. Cheers, Lorenzo --000e0cd568306a19da04a48cca65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 30, 2011 at 11:20 PM, Joel Jaeggli <= span dir=3D"ltr"><joelja@bogus.com> wrote:
But you've contributed to= this document, so have others from that list.

I don't want to contribute to the document because - in my opinion, and= speaking only for myself - I don't think it can be made into a balance= d assessment of the issue without major changes.

Since a) I don't have even a fraction of the time I would need to actua= lly contribute said changes, b) the document is already in an advanced stat= e of the IETF process, and c) it doesn't matter so much what the docume= nt ends up saying,=A0because most of the organizations for whom this is an = issue have already looked at the data and recognized that they have no alte= rnative, I was simply steering clear of the document entirely.

It's true that I have pointed out things I think ar= e incorrect. But I did not view these as contributions, more as offering oc= casional token opposition lest silence be interpreted as assent. :-) But pe= rhaps you're right and I should not comment on it at all.

Cheers,
Lorenzo
--000e0cd568306a19da04a48cca65-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AACE06D4; Mon, 30 May 2011 23:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.682 X-Spam-Level: X-Spam-Status: No, score=-101.682 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEwwMb1+HQHt; Mon, 30 May 2011 23:21:05 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E43EBE06BE; Mon, 30 May 2011 23:21:04 -0700 (PDT) Received: from wifi-216-59.mtg.afnog.org ([196.200.216.59]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p4V6KIDA010617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 May 2011 06:20:38 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--49386231 From: Joel Jaeggli In-Reply-To: Date: Mon, 30 May 2011 23:20:11 -0700 Message-Id: <7006BAA9-E515-42E7-85E2-06E1263CAD0E@bogus.com> References: <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 31 May 2011 06:20:53 +0000 (UTC) X-Mailman-Approved-At: Tue, 31 May 2011 08:08:35 -0700 Cc: IETF Discussion , "v6ops@ietf.org" , Dave Crocker , Gert Doering , Apps Review Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 06:21:06 -0000 --Apple-Mail-4--49386231 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 30, 2011, at 11:09 PM, Lorenzo Colitti wrote: > On Mon, May 30, 2011 at 8:48 AM, Gert Doering wrote: > I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that > protects which IPv6 clients are allowed to talk to a DNS server. >=20 > ACL is the wrong term. Saying it's an ACL makes it easy to make the = argument that whoever is implementing this is denying access to a = particular resource (the AAAA record). >=20 > In fact, the opposite is true - by electing not to return an AAAA = record, the implementer is able to allow access to a particular resource = (the content that the user wants to reach) instead of publishing the = resource over IPv6 where some users can't usefully reach it. >=20 > Which is of course, the root of the problem here. It is the reason why = many large website operators have either implemented whitelisting = (Google, Facebook) or have announced that they will be implementing = whitelisting (Yahoo, Akamai). And it is the reason why said website = operators are not contributing to this document. But you've contributed to this document, so have others from that list. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-4--49386231 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On May 30, 2011, at 11:09 PM, Lorenzo Colitti wrote:

On Mon, May 30, 2011 at 8:48 AM, Gert Doering <gert@space.net> wrote:
I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that
protects which IPv6 clients are allowed to talk to a DNS server.

ACL is the wrong term. Saying it's an ACL makes it easy to make the argument that whoever is implementing this is denying access to a particular resource (the AAAA record).

In fact, the opposite is true - by electing not to return an AAAA record, the implementer is able to allow access to a particular resource (the content that the user wants to reach) instead of publishing the resource over IPv6 where some users can't usefully reach it.

Which is of course, the root of the problem here. It is the reason why many large website operators have either implemented whitelisting (Google, Facebook) or have announced that they will be implementing whitelisting (Yahoo, Akamai). And it is the reason why said website operators are not contributing to this document.

But you've contributed to this document, so have others from that list.

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--Apple-Mail-4--49386231-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9EBE06D4 for ; Mon, 30 May 2011 23:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPsS2h24nJ8o for ; Mon, 30 May 2011 23:10:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A953CE06E1 for ; Mon, 30 May 2011 23:10:10 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p4V6A9pB026274 for ; Mon, 30 May 2011 23:10:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306822209; bh=QNZSFlli55cjrPwL/x+BDCJjVdA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GSFWZU2L+BFEfylUuWctiIJ6JoTwAKJfISGNxLLI4pSmsQ3L9Ncdu7n/yNk01T5lH 2xqPB41oPjM6qC6HUjJug== Received: from gxk1 (gxk1.prod.google.com [10.202.11.1]) by hpaq1.eem.corp.google.com with ESMTP id p4V6A7qq001433 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 30 May 2011 23:10:08 -0700 Received: by gxk1 with SMTP id 1so2121750gxk.24 for ; Mon, 30 May 2011 23:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oyVX/gc61gBxzLHbPQFgEUSGslTK7g062bfu2SI8XK4=; b=ZOP3zSYuKeDuyHHZ2E6o4X9HG4B+RBBdoqVmyqY7v8IWG2kpDHyo2qy0ryQua2CqTr uCup36Dtbgtse/48u6aw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NqgAyJ3EivTsdT7Lk4wYxvzFVLaqxR2cLLks+kGbHH06sVx9cy1/0U0AXgijs59MiI 29LRm93Pj4bLkuSdJDDw== Received: by 10.150.7.15 with SMTP id 15mr4510149ybg.378.1306822207110; Mon, 30 May 2011 23:10:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.101.5 with HTTP; Mon, 30 May 2011 23:09:47 -0700 (PDT) In-Reply-To: <20110530154841.GM45955@Space.Net> References: <4DE3B8FD.7040209@dcrocker.net> <20110530154841.GM45955@Space.Net> From: Lorenzo Colitti Date: Mon, 30 May 2011 23:09:47 -0700 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=000e0cd2878870809c04a48c4132 X-System-Of-Record: true X-Mailman-Approved-At: Tue, 31 May 2011 08:09:11 -0700 Cc: "v6ops@ietf.org" , Apps Review , Dave Crocker , IETF Discussion Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 06:10:11 -0000 --000e0cd2878870809c04a48c4132 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 30, 2011 at 8:48 AM, Gert Doering wrote: > I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that > protects which IPv6 clients are allowed to talk to a DNS server. > ACL is the wrong term. Saying it's an ACL makes it easy to make the argument that whoever is implementing this is denying access to a particular resource (the AAAA record). In fact, the opposite is true - by electing not to return an AAAA record, the implementer is able to allow access to a particular resource (the content that the user wants to reach) instead of publishing the resource over IPv6 where some users can't usefully reach it. Which is of course, the root of the problem here. It is the reason why many large website operators have either implemented whitelisting (Google, Facebook) or have announced that they will be implementing whitelisting (Yahoo, Akamai). And it is the reason why said website operators are not contributing to this document. --000e0cd2878870809c04a48c4132 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 30, 2011 at 8:48 AM, Gert Doering <gert@space.net>= ; wrote:
I have no idea what a "v6 DNS ACL" should be, except maybe an ACL= that
protects which IPv6 clients are allowed to talk to a DNS server.

ACL is the wrong term.=A0Saying it's an ACL m= akes it easy to make the argument that whoever is implementing this is deny= ing access to a particular resource (the AAAA record).

In fact, the opposite is true - by electing not to retu= rn an AAAA record, the implementer is able to allow access to a particular = resource (the content that the user wants to reach) instead of publishing t= he resource over IPv6 where some users can't usefully reach it.

Which is of course, the root of the problem here. It is= the reason why many large website operators=A0have either implemented whit= elisting (Google, Facebook) or have announced that they will be implementin= g whitelisting (Yahoo, Akamai). And it is the reason why said website opera= tors are not contributing to this document.
--000e0cd2878870809c04a48c4132-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A6FE07F9 for ; Mon, 30 May 2011 08:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPgGTFBKZOXh for ; Mon, 30 May 2011 08:48:46 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 94801E07F1 for ; Mon, 30 May 2011 08:48:44 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4977DF81AE for ; Mon, 30 May 2011 17:48:41 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 29588F81D8 for ; Mon, 30 May 2011 17:48:41 +0200 (CEST) Received: (qmail 19876 invoked by uid 1007); 30 May 2011 17:48:41 +0200 Date: Mon, 30 May 2011 17:48:41 +0200 From: Gert Doering To: dcrocker@bbiw.net Message-ID: <20110530154841.GM45955@Space.Net> References: <4DE3B8FD.7040209@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE3B8FD.7040209@dcrocker.net> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 31 May 2011 08:08:07 -0700 Cc: "v6ops@ietf.org" , "Livingood, Jason" , IETF Discussion , Apps Review Subject: Re: [apps-review] [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 15:48:53 -0000 Hi, On Mon, May 30, 2011 at 08:34:21AM -0700, Dave CROCKER wrote: > "AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good > labels. They provide useful, direct and precise meaning, while avoiding the > various referential and denotational problems of a loaded term like whitelist. I have no idea what a "v6 DNS ACL" should be, except maybe an ACL that protects which IPv6 clients are allowed to talk to a DNS server. Whitelisting, on the other hand, is the term that Google introduced for this kind of "thing" and people seem to clearly understand what this is about. "You are on my white list of people that I like talking to!". Gert Doering -- Operator -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAA7E07E5; Mon, 30 May 2011 08:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwgKd0n+VEQO; Mon, 30 May 2011 08:34:34 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 71AA1E07AB; Mon, 30 May 2011 08:34:34 -0700 (PDT) Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p4UFYP23012039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 30 May 2011 08:34:31 -0700 Message-ID: <4DE3B8FD.7040209@dcrocker.net> Date: Mon, 30 May 2011 08:34:21 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Livingood, Jason" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 30 May 2011 08:34:31 -0700 (PDT) Cc: "v6ops@ietf.org" , IETF Discussion , Apps Review Subject: Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 15:34:36 -0000 (I see that you've posted -05. This response is for completeness.) On 5/29/2011 7:54 PM, Livingood, Jason wrote: > [JL] Duly noted in my previous emails. I'm keeping the naming as an open issue > in the –04 and will be seeking WG and WG co-chair guidance one way or the other. One of the reasons for cross-area review is to look for cross-area problems. Separate from the legal formalities, the purpose of 'trademark' is to try to avoid market confusion. Market confusion was exactly the reason that I raised concern about the naming and I wasn't the only one who noticed the problem. (My original, informal posting was directly result of that confusion...) So I'm sorry to see that the naming conflict is felt to be irrelevant by those running the working group. (I was also a little surprised to see that that core of folk constitute working group rough consensus, for removing open items.) As for the actual term "whitelisting" I suppose we should admire the boldness of the view that access to v6 is a priviledge -- note that that's the denotational perspective of the word whitelisting... > operator of a website, such as www.example.com, the operator > essentially applies an access control list (ACL) on the authoritative > DNS servers for the domain example.com. The ACL is populated with > > An ACL usually is a yes/no mechanism. Here, however, the mechanism is for > asserting a preference for IPv6 over IPv4. > > That does not seem to match the definition of ACL that I'm used to, unless the > semantic is defined as denying IPv4 access to the listed clients. > > The term ACL is particularly odd to use if the mechanism pertains to responses > rather than queries. > > > [JL] I am using 'ACL' in the most general possible sense and am open to > alternative descriptors if you wish to suggest one. But most people seem to know > an ACL is a list that, if you are listed on it, grants you access to some > resource. In this case if the resolver is on the list then it gets AAAA RRs. On reflection, the term is growing on me for this use. "AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good labels. They provide useful, direct and precise meaning, while avoiding the various referential and denotational problems of a loaded term like whitelist. > [JL] I took a stab at a new diagram in –04 — so take a look and let me know if > it is what you are suggesting (I've left the original one in for now). Took a quick look at the added diagram in the new draft. The thing about a protocol timeline diagram is that it uses verticality to provide ordering. So a response is lower down than a request. I don't get that from your Figure 2. (By the way, your first sub-scenario, with Resolver 1, shows only a v4 response, without indicating whether the resolver sent a v6 or v4 query. For the review, I think this distinction between transport and data -- "how is the query/response transported" vs. "what RRs are returned" -- was a continuing point of confusion for me. ) > At least one highly-trafficked domain has noted that they have > received requests to not send DNS responses with AAAA resource > records to particular resolvers. In this case, the operators of > > > "At least one" seems a rather tiny statistic. Perhaps the actual statistic is > significantly larger? > > > [JL] It does not seem to be. Other than this being passed along by Google, I've > not heard of any similar stories. Nevertheless, it seemed interesting enough to > include. As an anecdote, it is perhaps interesting. As a basis for promoting the entire effort, not so much. I couldn't tell which role it was serving, but it felt like the latter. > network infrastructure is not yet ready to handle the large traffic > volume which may be associated with the hosts in their network > connecting to the websites of these domains. This concern is clearly > > > So even though the site allows v6 DNS queries to go out from a host, it can't > really support having the host use v6? > > > [JL] A network isn't really in control of the end host's limitations w/r/t IPv6 > impairment. A good summary of the issue of impairment is @ http://www.fud.no/ipv6/ That sort of commentary, along with the citation, might be good to include, for clarification. > 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 > > > 8 hundredths of one percent? I think that that's 8 of every 10,000 Internet users? > That's considered a high percentage? > > > [JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that > rate, it'd be cheaper and easier for me (an ISP) to just buy new computers for > the affected "impaired" users than to have to navigate years of whitelisting > with a variety of domains. In any case, one recent measurement estimates it at > 0.05% now and another at 0.015%. Despite this, this practice is still generating > some interest. I'm hoping World IPv6 Day goes well and is informative for the > community as to this percentage on a widespread basis, across a wide variety of > web sites. > > > Even if it is 8%, is that considered high? > > > [JL] 8% of the Internet finding google.com or facebook.com inaccessible would be > bad for everyone. That could generate several hundred thousand support calls per > day to a big ISP. On reflection, I'm surprised to hear that IPv6 usage is up as high as 8 out of every 10,000 users, nevermind a large multiple of that. (Although it does carry a backhanded note of encouragement about v6 adoption, I'm a bit suspicious of the statistic.) > troubleshooting standpoint. In this scenario, a DNS recursive > resolver operator will have no way to systematically determine > whether DNS whitelisting is or is not implemented for a domain, since > the absence of AAAA resource records may simply be indicative that > the domain has not yet added IPv6 addressing for the domain, rather > than that they have done so but have restricted query access via DNS > > > The premise is that, in large scale use, servers /will/ have a way to > systematically determine whether it is implemented? What are the existing > examples of having such a capability for other Internet protocols and services? > > > [JL] Perhaps I'm overplaying this point, but you know someone has email service > if they have an MX record for example, or a website if the host answers on > TCP/80. But as I re-read this it is probably overkill and so I've deleted it. I > have however moved some of the text to a prior section, since determining > whether or not domains are whitelisting is still a challenge at scale. Note that a site can have email service without an MX and that TCP:80 is not merely an "indicator" of web service, but actually /is/ the web service. My point is that this idea of signaling/registering support of a service, as separate from actually providing the service, is not part of typical Internet service requirements and the simplification this provides is significant. We need to be careful that we do not inadvertently teach folks that "signaling support" is an expected feature. (And with this response, given that you already deleted the text, it's my turn to overplay a point...) > nature, not to mention physics. For example, as Sir Issac Newton > noted, "Every object in a state of uniform motion tends to remain in > that state of motion unless an external force is applied to it" [Laws > > > Code does not have momenum. Neither do configurations or lists. This really > isn't about physics. > > > [JL] But people and processes do have (operational) momentum… Indeed, and the process of dealing with the naming issue for this does seem to show that... > It is entirely about group psychology, as you note, and the administrative > challenges in the logistics of large-scale operational changes (which probably > /does/ have something to with physics, but it seems a stretch to credit Newton. > How about Heisenberg?...) > > > [JL] Hmmm… I don't think it is Heisenberg-related. But it's such an interesting > citation I feel it's almost a personal challenge to figure out a way to keep it > in there. ;-) How certain of it's being a challenge are you? Does your certainty change as you think about it? The way I think about it is that in 5 or 10 years none of the > people working on the details of the IPv6 transition now will still be involved > in the day-to-day operational work. But DNS Whitelisting could still be in place > – and once something gets a momentum to it (people, processes, and > organizations) it is really, really hard to change that. Well, I seriously applaud that concern, especially since its validity is proven every day (including in the IETF...) On the average, I tend to believe that the best way to instruct folks later is by imparting information about tradeoffs and, especially, cost vs. benefit. In the current case, the near-term cost/benefit makes some sense. In the long term, the scaling cost of maintenance and the architectural cost of losing spontaneous interoperability strike me as pretty f'ing expensive. > 8.3. Do Not Implement DNS Whitelisting > > As an alternative to adopting DNS whitelisting, the Internet > community generally can choose to take no action whatsoever, > perpetuating the current predominant authoritative DNS operational > model on the Internet, and leave it up to end users with IPv6-related > impairments to discover and fix those impairments. > > > That is, place the burden of fixing a problem on those creating it? > > > [JL] In a way. It gets back to the question you asked about what level of > impairment justifies this practice. One obvious option is to let end users sort > it out (presumably by consulting with their ISPs / network operators). This may > be simpler and it's the way solutions to non-IPv6 problems tend to work today. On the average, demanding that an end-user make an explicit decision about an operational tuning issue does not work very well. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4CE0767; Sun, 29 May 2011 19:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.896 X-Spam-Level: X-Spam-Status: No, score=-107.896 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sWjjUkXL97z; Sun, 29 May 2011 19:54:33 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C8A22E0657; Sun, 29 May 2011 19:54:31 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.128054652; Sun, 29 May 2011 22:54:22 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Sun, 29 May 2011 22:54:21 -0400 From: "Livingood, Jason" To: Dave Crocker , IETF Discussion Thread-Topic: Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* Thread-Index: AQHMHnTaa+cb8O33f02hYGkDuWA7dQ== Date: Mon, 30 May 2011 02:54:20 +0000 Message-ID: In-Reply-To: <4DC821FB.2050904@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CA084387289FFjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 30 May 2011 08:31:12 -0700 Cc: "v6ops@ietf.org" , Apps Review Subject: Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 02:54:42 -0000 --_000_CA084387289FFjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dave =96 Thanks for this email as well. It is my last item in queue before = posting an updated =9604 draft (whew!). See some specific responses inline = below. Thanks JL On 5/9/11 1:18 PM, "Dave CROCKER" > wrote: (This is an "official" and significantly extended version of an informal an= d narrow review I posted earlier. /d) Howdy. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Review (v2): Title: IPv6 AAAA DNS Whitelisting Implications I-D: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 By: D. Crocker > Date: <> Summary =3D=3D=3D=3D=3D=3D=3D This draft covers a a dual-stack problem in which a target host's DNS entry contains records for IPv4 and IPv6, but returning IPv6 information to a DNS client can cause problems. The paper discusses for resolving this through u= se of a a DNS-based mechanism that manually lists response preferences to select = which DNS records to return. The paper describes the mechanism and explores vari= ous effects and possibilities of its use, including the difference between usin= g it selectively among a smaller number of sites, versus universally. The draft is a serious effort to explore the use of such a mechanism and it touches many different issues. It is generally well-organized and clearly written, although it very much needs the aid of a professional technical ed= itor. The writing often assumes too much knowledge by the reader. The paper's exploration of universal adoption seems to vary between conside= ring that goal practical versus considering it only as a matter of completeness = for discussing the full range of possibilities. That is, it is not clear wheth= er the paper views this alternative as practically possible and even preferred= , versus only a matter for academic thoroughness. [JL] I consider it the latter =96 highly unlikely but included for complete= ness (on the assumption that a failure to include it would lead to comments= that it was incomplete without it). However the =9604 update will make mor= e clear the remoteness of the possibility of universal deployment. The paper needs to take a basic position about feasibility, explain it in terms of comparable adoption effo= rts at Internet-scale, and then make its treatment of universal adoption a bit = more consistent. [JL] Good feedback - I've tried to do that in the =9604 version. When introducing terms, mechanisms, configurations and scenarios, the paper needs to be more careful to describe them adequately for a reader new to th= e topic. This is not a matter of having a tutorial about the DNS, but rather= a tutorial for this type of mechanism and when and how it can be used. As a specific example, the document cites "domain-by-domain" use, but I am = not clear how that would work, in terms of configuration and cross-net informat= ion exchange. One question is how the server knows the 'domain' of the client? The document should careful to distinguish what is existing practice, versu= s what is being explored as added possibilities. The difference in concreten= ess and certitude between the two is substantial. The document's use of the term whitelisting appears to continue an existing= , recent use, for this type of mechanism. Unfortunately it directly conflict= s with long-standing use of the term by the anti-abuse community for whitelis= ting in the DNS. Its use here also seems to be a mismatch with the word's dictio= nary semantics, which is most naturally used to distinguish yes/no choices, rath= er than either/or choices. So there is no intuitive sense of "goodness" (whit= elist =3D yes) or "badness" (blacklist) for this use. The word "preferences" seem= s more in line with the meaning of the mechanism. [JL] Duly noted in my previous emails. I'm keeping the naming as an open is= sue in the =9604 and will be seeking WG and WG co-chair guidance one way or= the other. Your other notes have also suggested a simplification of the do= cument in some respects so that is also noted as an open item as well (but = I really do need to get an update out in the meantime). Detailed Comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Abstract The objective of this document is to describe what the whitelisting of DNS AAAA resource records is, hereafter referred to as DNS RRs are whitelisted? Isn't it the addresses and not the records that are whitelisted? Does this mean putting whitelisting records into the DNS or does it mean something else? Comcast's own considerable expertise notwithstanding, has this doc been vet= ted with a range of organizations that actually DO whitelisting? Has it been circulated through MAAWG and APWG? Any comments from Spamhaus? The Acknowledgements list does not seem to indicate a range of whitelist ops fo= lks whose names I know. (But then, I only know a few...) [JL] Per my other note today, this will be fixed in the =9604. 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. I suspect that product marketers won't have much interest in this. I suspe= ct that the target for this is anti-abuse technical and operations staff. In a= ny event, the targetting statement should be more precise. [JL] Addressed in my earlier response to your shorter review. 1. Introduction This document describes the emerging practice of whitelisting of DNS One natural, semantic problem with the term 'whitelist' is that it does not really match the function being performed. The white/black distinction imp= lies goodness -- or as Wikipedia says, "priviledge". Instead, the use here is f= or preference or priority. What would a "blacklist" be, here? Also note it i= s not obvious what it means to be whitelisted, here? Does it mean to choose the = AAAA records or the A records? This is more like a 'Preference' or 'Configuration' list. At the least, the name for this should be IPv6 Resolver Whitelisting. It m= akes clear /what/ is being "whitelisted". [JL] Ack. Carried in Open Items for =9604. AAAA resource records (RRs), which contain IPv6 addresses, hereafter referred to as DNS whitelisting. The document explores the This provides a name, but not a function. That is, it does not say what th= is mechanisms actually /does/ or is /for/. [JL] Addressed in my earlier response to your shorter review. implications of this emerging practice are and what alternatives may exist. The practice of DNS whitelisting appears to have first been used by major web content sites (sometimes described herein as "highly- It's use for email anti-abuse dates back farther. Specifically within the context of the DNS, the term whitelisting is theref= ore made ambiguous. A google query for "whitelist dns" also demonstrates the history and curren= t ambiguity. [JL] Addressed in my earlier response to your shorter review. trafficked domains" or "major domains"). These web site operators, or domain operators, observed that when they added AAAA resource records to their authoritative DNS servers in order to support IPv6 access to their content that a small fraction of end users had slow or otherwise impaired access to a given web site with both AAAA and A resource records. The fraction of users with such impaired access has been estimated to be roughly 0.078% of total Internet users [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 Brokenness]. Thus, in an example Internet Service Provider (ISP) network of 10 million users, approximately 7,800 of those users may experience such impaired access. At a minimum, these sorts of statistics need to be normalized across IPv6 users/traffic, given how small a percentage that is, in total users and tot= al traffic. If that's what is meant it should be stated. If it isn't, the statistic should be recalculated and explained a bit more precisely. [JL] Addressed in my earlier response to your shorter review. As a result of this impairment affecting end users of a given domain, a few major domains have either implemented DNS whitelisting or are considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations]. When implemented, DNS whitelisting in practice means that a domain's authoritative DNS will return a AAAA resource record to DNS recursive resolvers [RFC1035] on the whitelist, while returning no AAAA resource records to DNS resolvers which are not on the whitelist. It This explanation of the function should be offered sooner and should be summarized in the Abstract. [JL] Good suggestion =96 made some tweaks to the Abstract to try to address= this. is important to note that these major domains are motivated by a desire to maintain a high-quality user experience for all of their Rather than being important to note, this sentence sounds oddly like market= ing hype, in a technical specification. It is gratuitous because specified fea= tures are never added to /lower/ the quality of the user experience, for example. In addition, the mechanism also affects client activity that has no user directly involved. users. By engaging in DNS whitelisting, they are attempting to shield users with impaired access from the symptoms of those impairments. The /technical/ statement that should be here is that they are attempting t= o provide a work-around for problematic behaviors in dual-stack IPv4/IPv6 environments. The paper should make more clear exactly where the problem lies and when. I= f it can occur for a number of reasons, explaining each of those scenarios would= be useful. [JL] I've attempted to do so in the =9604 update. Critics of the practice of DNS whitelisting have articulated several concerns. Among these are that: o DNS whitelisting is a very different behavior from the current practice concerning the publishing of IPv4 address resource records, o that it may create a two-tiered Internet, o that policies concerning whitelisting and de-whitelisting are opaque, Livingood Expires August 26, 2011 [Page 5] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 o that DNS whitelisting reduces interest in the deployment of IPv6, o that new operational and management burdens are created, well, yeah... in fact it should be noted that the burdens are particularly onerous at scale. [JL] Ack =96 updated the text to reflect this o and that the costs and negative implications of DNS whitelisting outweigh the perceived benefits, compared to fixing underlying impairments. and it doesn't scale. and it violates an extremely basic premise of cross-Internet interoperabili= ty by requiring prior arrangement. [JL] Ack =96 added this This document explores the reasons and motivations for DNS whitelisting. It also explores the outlined concerns regarding this practice. Readers will hopefully better understand what DNS whitelisting is, why some parties are implementing it, and what criticisms of the practice exist. 2. How DNS Whitelisting Works How IPv6 AAAA DNS Whitelisting Works. (Anti-spam DNS Whitelisting works rather differently...) DNS whitelisting is implemented in authoritative DNS servers. These servers implement IP address-based restrictions on AAAA query responses. So far, DNS whitelisting has been primarily implemented by web server operators deploying IPv6-enabled services. For a given Really? This is web-specific? The same restrictions are not applied for o= ther applications? So if the same client-side hosts attempt to contact the server for email or xmpp, they won't get the same handling? [JL] Quite so =96 I updated the text to clarify this. operator of a website, such as www.example.com, the operator essentially applies an access control list (ACL) on the authoritative DNS servers for the domain example.com. The ACL is populated with An ACL usually is a yes/no mechanism. Here, however, the mechanism is for asserting a preference for IPv6 over IPv4. That does not seem to match the definition of ACL that I'm used to, unless = the semantic is defined as denying IPv4 access to the listed clients. The term ACL is particularly odd to use if the mechanism pertains to respon= ses rather than queries. [JL] I am using 'ACL' in the most general possible sense and am open to alt= ernative descriptors if you wish to suggest one. But most people seem to kn= ow an ACL is a list that, if you are listed on it, grants you access to som= e resource. In this case if the resolver is on the list then it gets AAAA R= Rs. the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive Either address type can be listed? So this really is a pure 'preferences' mechanism? Which settings count as whitelisting? Do any count as blacklisting? [JL] A resolver can have both IPv6 and IPv4 addresses. Whether a resolver i= s listed on the whitelist and is therefore able to receive AAAA RR response= s is orthogonal to whether the resolver itself has an IPv4 or IPv6 address = =97 since the whitelisting decision making tends to be based on some conclu= sion about the hosts that query the resolver rather than the resolver. resolvers on the Internet, which have been authorized to receive AAAA resource record responses. These DNS recursive resolvers are operated by third parties, such as ISPs, universities, governments, businesses, and individual end users. If a DNS recursive resolver IS NOT matched in the ACL, then AAAA resource records will NOT be sent in response to a query for a hostname in the example.com domain. This configuration appears to ensure the maximum barrier to adoption for IP= v6, since it means that IPv6 will not work automatically. It will only work fo= r hosts that are manually configured to receive responses with v6 records. That's a rather major implication. It's a default that is probably meant t= o apply during the very early stages of adoption, when there are few users of= the newer mechanism. It's probably worth discussing it in more detail, including discussing when= to change the default... [JL] Correct on all 3 points. I've tried to address this better in the =960= 4 version. However, if a DNS recursive resolver IS matched in the ACL, then AAAA resource records will be sent in response to a query for a given hostname in the example.com domain. While these are not network- layer access controls they are nonetheless access controls that are a factor for end users and other parties like network operators, especially as networks and hosts transition from one network address family to another (IPv4 to IPv6). Also, all of this clarifies the function of this listing mechanism and sugg= ests a very different name, to be more precise and accurate in naming it: IPv6 DNS Response Preference List. [JL] I've added all the various naming suggestions to the Open Issues secti= on. 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. The large majority of DNS resolvers on the Internet will therefore receive only A resource records containing IPv4 addresses. Thus, quite simply, the authoritative server hands out different answers depending upon who is asking; with IPv4 and IPv6 resource records for some on the authorized whitelist, and only IPv4 resource records for everyone else. See Section 2.1 and Figure 1 for a description of how this Livingood Expires August 26, 2011 [Page 6] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 works. 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. 2.1. Description of the Operation of DNS Whitelisting The system logic of DNS whitelisting is as follows: 1. The authoritative DNS server for example.com receives DNS queries for the A (IPv4) and AAAA (IPv6) address resource records for the FQDN www.example.com, for which AAAA (IPv6) resource records exist. This means that the mechanism is /only/ triggered when /both/ address recor= ds are queried? A query for only one type of address record won't trigger the= list lookup? I think that doesn't match other statements in the document. [JL] Updated to clarify / correct my text. (changed A and AAAA to and/or) 2. The authoritative DNS server examines the IP address of the DNS recursive resolver sending the AAAA (IPv6) query. "examines"? Examines it for what? What does this step mean? [JL] Examines as in looks at the IP address. I'll just simplify it and comb= ine it with #3. 3. The authoritative DNS server checks this IP address against the access control list (ACL) that is the DNS whitelist. 4. If the DNS recursive resolver's IP address IS matched in the ACL, then the response to that specific DNS recursive resolver can contain AAAA (IPv6) address resource records. Oh. This is not about whether to send responses /over/ v6 vs. v4? This is whether to /include/ a particular type of RR in responses??? In that case an appropriate name for this mechanism is more like: DNS Response Content Preference List [JL] Adding this suggested name to the Open Issues list as well. And this seems even less like an ACL than it did before. (I assume the justification is that access is being prevented by virtue of not supplying = the address, but still...) 5. If the DNS recursive resolver's IP address IS NOT matched in the ACL, then the response to that specific DNS recursive resolver cannot contain AAAA (IPv6) address resource records. In this case, the server should return a response with the response code (RCODE) being set to 0 (No Error) with an empty answer section for the AAAA record query. Livingood Expires August 26, 2011 [Page 7] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 --------------------------------------------------------------------- A query is sent from a DNS recursive resolver that IS NOT on the DNS whitelist: Request Request www.example.com www.example.com AAAA +-------------+ AAAA +-----------------+ ++--++ ---------> | RESOLVER | ---------> | www.example.com | || || A | **IS NOT** | A | IN A exists | +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | +--------+ A | example.com | A | | Host <--------- | WHITELIST | <--------- | | Computer A Record +-------------+ A Record +-----------------+ Response DNS Recursive Response example.com (only IPv4) Resolver (only IPv4) Authoritative #1 Server --------------------------------------------------------------------- A query is sent from a DNS recursive resolver that IS on the DNS whitelist: Request Request www.example.com www.example.com AAAA +-------------+ AAAA +-----------------+ ++--++ ---------> | RESOLVER | ---------> | www.example.com | || || A | **IS** | A | IN A exists | +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | +--------+ AAAA | example.com | AAAA | | Host <--------- | WHITELIST | <--------- | | Computer A | | A | | <--------- | | <--------- | | A and AAAA +-------------+ A and AAAA +-----------------+ Record DNS Recursive Record example.com Responses Resolver Responses Authoritative (IPv4+IPv6) #2 (IPv4+IPv6) Server --------------------------------------------------------------------- Figure 1: DNS Whitelisting - Functional Diagram This diagram is confusing to me. I suspect that a protocol exchange sequen= ce format, in the style of: Host Resolver 1 Authoritative ----------> ---------> <--------- <---------- will be considerably more helpful. [JL] I took a stab at a new diagram in =9604 =97 so take a look and let me = know if it is what you are suggesting (I've left the original one in for no= w). 3. What Problems Are Implementers Trying To Solve? This is a very useful section and it is probably worth moving it higher, to precede the 'how it works' section. 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). By the way, what does 'impaired v6 access' mean? I think there needs to be a simple, direct description of what occurs witho= ut this mechanism. For example, perhaps you mean that a host can send DNS queries using IPv6 b= ut cannot receive DNS responses over IPv6? Perhaps you mean that the host can = send IPv6 but cannot receive it. (That's a different scale and scope of problem= from the first example I gave.) This brief, summary problem statement should be included in the Abstract, t= o make /much/ more clear what this mechanism is for. [JL] Done. Added text to the Abstract and Intro and added more to note that= this is about both impairment and (actual or perceived) immaturity of IPv6= network routing and practices. 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. It would affect access to all or most dual Livingood Expires August 26, 2011 [Page 8] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 stack services to which the user attempts to connect. This negative end user experience can range from someone slower than usual (as compared to native IPv4-based access), to extremely slow, to no access to the domain whatsoever. Rather than repeat that this is about end-users, it sounds more that this i= s about whether a service works or does not work, whether a user is directly present or not. While one can debate whether DNS whitelisting is the optimal solution to the end user experience problem, it is quite clear that DNS whitelisting implementers are interested in maximizing the performance of their services for end users as a primary motivation for implementation. You keep citing 'performance' but haven't described what sort of performanc= e degradation takes place. Is this really about relatively better or worse performance -- and if so, how -- or is this about working or not working? [JL] Good point =96 I added this text: "In essence, whether the end user even has an IPv6 address or not (they pro= bably only have an IPv4 address), merely by receiving a AAAA record respons= e the user either cannot access a FQDN or it is so slow that the user gives= up and assumes the destination is unreachable." Also rather than saying what implementers are interested in, it's probably = more helpful to note that the practice is now significantly established and ther= efore worth documenting, independent of its possible controversy. At least one highly-trafficked domain has noted that they have received requests to not send DNS responses with AAAA resource records to particular resolvers. In this case, the operators of "At least one" seems a rather tiny statistic. Perhaps the actual statistic= is significantly larger? [JL] It does not seem to be. Other than this being passed along by Google, = I've not heard of any similar stories. Nevertheless, it seemed interesting = enough to include. those recursive resolvers have expressed a concern that their IPv6 I suspect that it's not resolvers that are doing the expressing, since thei= r vocabulary is usually too limited... [JL] Quite. Updated: "In this case, DNS recursive resolvers operators have expressed=85" network infrastructure is not yet ready to handle the large traffic volume which may be associated with the hosts in their network connecting to the websites of these domains. This concern is clearly So even though the site allows v6 DNS queries to go out from a host, it can= 't really support having the host use v6? [JL] A network isn't really in control of the end host's limitations w/r/t = IPv6 impairment. A good summary of the issue of impairment is @ http://www.= fud.no/ipv6/ Wow. I do understand why service providers often have to work around sillin= ess at the client side, but this problem at the client side seems particularly egregious. a temporary consideration relating to the deployment of IPv6 network infrastructure on the part of networks with end user hosts, rather than a long-term concern. These end user networks may also have Again this goal of short-term usage is worth noting earlier, including in t= he Abstract. other tools at their disposal in order to address this concern, including applying rules to network equipment such as routers and firewalls (this will necessarily vary by the type of network, as well as the technologies used and the design of a given network), as well as configuration of their recursive resolvers (though modifying or suppressing AAAA resource records in a DNSSEC-signed domain on a Security-Aware Resolver will be problematic Section 10.1). Some implementers with highly-trafficked domains have explained that DNS whitelisting is a necessary, though temporary, risk reduction tactic intended to ease their transition to IPv6 and minimize any perceived risk in such a transition. As a result, they perceive this as a tactic to enable them to incrementally enable IPv6 connectivity to their domains during the early phases of their transition to IPv6. Finally, some domains, have run IPv6 experiments whereby they added AAAA resource records and observed and measured errors [Heise Online Experiment], which should be important reading for any domain contemplating either the use of DNS whitelisting or simply adding IPv6 addressing to their site. 4. Concerns Regarding DNS Whitelisting 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 I think the implications are not conditional; they exist rather than being potential. The 'potential' is that what is implicated will come to pass. [JL] Fair point =96 removed 'potential' there and in another similar sectio= n. Livingood Expires August 26, 2011 [Page 9] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 enumerated here and in Section 7. Pro forma question: Why are implications discussed in multiple places? [JL] Some of them in are briefly noted in Section 4, but the exhaustive lis= t in in Section 7. Some parties in the Internet community, including ISPs, are concerned This style of text personalizes the issues unnecessarily (IMO). It does no= t really matter who holds the concerns, or else they'd be described more prec= isely. [JL] I'll have to look at that after the =9604 update. In a previous draft = I was asked to call out different parts of the community separately. (Alway= s challenging to work through conflicting feedback.) I suggest merely noting that there are concerns and then listing and discus= sing the concerns, rather than adding text to attribute the concerns to others, = even if the conclusion of your text is that a particular concern is not valid. [JL] Duly noted. Let me get the =9604 update out, after which I will look a= t generally simplifying the I-D and look at this issue specifically. that the practice of DNS whitelisting for IPv6 address resource records represents a departure from the generally accepted practices regarding IPv4 address resource records in the DNS on the Internet [Whitelisting Concerns]. These parties explain their belief that for "These parties explain their belief" is an example of personalization that = is not needed. This isn't about the believers. It is about possible problems= . [JL] Ack. A resource records, containing IPv4 addresses, once an authoritative server operator adds the A record to the DNS, then any DNS recursive resolver on the Internet can receive that A record in response to a This does not appear to be a grammatically valid sentence. My guess is tha= t deleting "A resource... addresses" fixes this. [JL] Change made. And by the way, the document's reference to "recursive" resolvers is mostly likely incorrect. The problem is not restricted only to that very specific= type of resolver, is it? If in fact it /is/ specific to them -- and your following text describes an indirect effects scenario where it might be -- I suggest calling out the configuration at the beginning, along the lines of: One way the problem with returning AAAA records can be experienced is= when recursive resolvers are used. Although that resolver might support IPv6, i= ts client hosts might not. So, returning an AAAA record will mean that these limited hosts will be given an unusable address. And this type of description belongs in the text describing the motivating problem(s), rather than buried in the 'concerns' discussion. (The text, here, pertains to A records, but the problem I've described uses= the same configuration but for AAAA records with mixed v6 support.) query. By extension, this means that any of the hosts connected to any of these DNS recursive resolvers can receive the IPv4 address resource records for a given FQDN. This enables new server hosts which are connected to the Internet, and for which a fully qualified domain name (FQDN) such as www.example.com has been added to the DNS with an IPv4 address record, to be almost immediately reachable by any host on the Internet. In this case, these new servers hosts become more and more widely accessible as new networks and new end user hosts connect to the Internet over time, capitalizing on and increasing so-called "network effects" (also called network externalities). It also means that the new server hosts do not need to know about these new networks and new end user hosts in order to make their content and applications available to them, in essence that each end in this end-to-end model is responsible for connecting to the Internet and once they have done so they can connect to each other without additional impediments or middle networks or intervening networks or servers knowing about these end points and whether one is allowed to contact the other. Hmmm. This rather lengthy bit of prose appears merely to be explaining the basic and long-standing DNS value proposition??? [JL] Ack =96 see previous comments about simplification. At the same time I= 'm trying to keep the document understandable to wide audience (and one of = your other notes suggested I need to be somewhat less technical or more des= criptive). You may be more familiar with the mechanics of DNS whereas someo= ne else is less so. I'll think about this one=85 In contrast, the concern is that DNS whitelisting may fundamentally change this model. In the altered DNS whitelisting end-to-end model, one end (where the end user is located) cannot readily connect to the other end (where the content is located), without parts of the middle (recursive resolvers) used by one end (the client, or end user hosts) being known to an intermediary (authoritative nameservers) and approved for access to the resource at the end. As new networks connect to the Internet over time, those networks need to contact any and all domains which have implemented DNS whitelisting in order to apply to be added to their DNS whitelist, in the hopes of making the content and applications residing on named server hosts in those domains accessible by the end user hosts on that new network. Furthermore, this same need to contact all domains implementing DNS whitelisting also applies to all pre-existing (but not whitelisted) networks connected to the Internet. In the current IPv4 Internet when a new server host is added to the Internet it is generally widely available to all end user hosts and networks, when DNS whitelisting of IPv6 resource records is used, If it is available to the hosts, it is available to the network. networks, when -> networks. When [JL] Fixed Livingood Expires August 26, 2011 [Page 10] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 these new server hosts are not accessible to any end user hosts or networks until such time as the operator of the authoritative DNS They are still accessible. The IP-level mechanisms still work. They are not reachable when using the domain name. [JL] Fixed servers for those new server hosts expressly authorizes access to those new server hosts by adding DNS recursive resolvers around the Internet to the ACL. This has the potential to be a significant This is a good example of the reason the term ACL is inappropriate: It imp= lies a security protection that does not actually exist. The hosts are still ac= cessible. [JL] I still think the whitelist is comparable to an ACL insofar as it cont= rols access to AAAA RR responses on the authoritative server, regardless of= access by IP address to some destination host. change in reachability of content and applications by end users and networks as these end user hosts and networks transition to IPv6, resulting in more (but different) breakage. A concern expressed is that if much of the content that end users are most interested in is not accessible as a result, then end users and/or networks may resist adoption of IPv6 or actively seek alternatives to it, such as using multi-layer network address translation (NAT) techniques like NAT444 [I-D.shirasaki-nat444] on a long-term basis. There is also concern that this practice also could disrupt the continued increase in Internet adoption by end users if they cannot simply access new content and applications but must instead contact the operator of their DNS recursive resolver, such as their ISP or another third party, to have their DNS recursive resolver authorized for access to the content or applications that interests them. Meanwhile, these parties say, over 99.9% of the other end users that are also using that same network or DNS recursive resolver are unable to access the IPv6-based content, despite their experience being a positive one. 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 8 hundredths of one percent? That's considered a high percentage? [JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that= rate, it'd be cheaper and easier for me (an ISP) to just buy new computers= for the affected "impaired" users than to have to navigate years of whitel= isting with a variety of domains. In any case, one recent measurement estim= ates it at 0.05% now and another at 0.015%. Despite this, this practice is = still generating some interest. I'm hoping World IPv6 Day goes well and is = informative for the community as to this percentage on a widespread basis, = across a wide variety of web sites. Even if it is 8%, is that considered high? [JL] 8% of the Internet finding google.com or facebook.com inaccessible wou= ld be bad for everyone. That could generate several hundred thousand suppor= t calls per day to a big ISP. 5.2. Similarities to DNS Load Balancing DNS whitelisting also has some similarities to DNS load balancing. There are of course many ways that DNS load balancing can be performed. In one example, multiple IP address resource records (A and/or AAAA) can be added to the DNS for a given FQDN. This approach is referred to as DNS round robin [RFC1794]. DNS round robin may also be employed where SRV resource records are used [RFC2782]. Right, but that's algorithmic rather than involving the manual method, desc= ribed here. So it does not seem comparable. [JL] Whether I agree with you or not, the WG asked to include it in an earl= ier draft. I tried to simply say that there are "some" similarities as a qu= alifier. 6. Likely Deployment Scenarios In considering how DNS whitelisting may emerge more widely, there are two likely deployment scenarios, which are explored below. In either of these deployment scenarios, it is possible that reputable third parties could create and maintain DNS whitelists, in much the same way that blacklists are used for reducing email spam. In the email context, a mail operator subscribes to one or more of these lists and as such the operational processes for additions and deletions to the list are managed by a third party. A similar model could emerge for DNS whitelisting, whether deployment occurs universally or on an ad hoc basis. The challenges of email whitelists and blacklists should be cited, since it provides a rich base of experience for such an effort, at scale. 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis The seemingly most likely deployment scenario is where some Most likely? This is not already established practice? [JL] It is established at some large domains like google.com (which compris= e a large % of global Internet traffic). But other domains are now on the c= usp of their IPv6 transition and are pondering whether or not to use whitel= isting. This document will hopefully be one of many data points in their de= cision-making. authoritative DNS server operators implement DNS whitelisting but many or most others do not do so. What can make this scenario challenging from the standpoint of a DNS recursive resolver operator is determining which domains implement DNS whitelisting, particularly since a domain may not do so as they initially transition to IPv6, and may instead do so later. Thus, a DNS recursive resolver operator Livingood Expires August 26, 2011 [Page 13] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 may initially believe that they can receive AAAA responses as a domain adopts IPv6, but then notice via end user reports that they no longer receive AAAA responses due to that domain adopting DNS whitelisting. Of course, a domain's IPv6 transition may be effectively invisible to recursive server operators due to the effect of DNS whitelisting. This suggests that every listing at the server needs a contact record for periodic checks whether to renew the listing. In contrast to a universal deployment of DNS whitelisting Section 6.2, deployment on an ad hoc basis is likely to be significantly more challenging from an operational, monitoring, and Oh? Use in small scale is more challenging than use of manual exceptions l= ist at large scale? That's a very unexpected view. [JL] I think it is in some regards but thinking it through more fully, I th= ink you are correct and I have removed this. troubleshooting standpoint. In this scenario, a DNS recursive resolver operator will have no way to systematically determine whether DNS whitelisting is or is not implemented for a domain, since the absence of AAAA resource records may simply be indicative that the domain has not yet added IPv6 addressing for the domain, rather than that they have done so but have restricted query access via DNS The premise is that, in large scale use, servers /will/ have a way to systematically determine whether it is implemented? What are the existing examples of having such a capability for other Internet protocols and servi= ces? [JL] Perhaps I'm overplaying this point, but you know someone has email ser= vice if they have an MX record for example, or a website if the host answer= s on TCP/80. But as I re-read this it is probably overkill and so I've dele= ted it. I have however moved some of the text to a prior section, since det= ermining whether or not domains are whitelisting is still a challenge at sc= ale. whitelisting. As a result, discovering which domains implement DNS whitelisting, in order to differentiate them from those that do not, is likely to be challenging. One benefit of DNS whitelisting being deployed on an ad hoc basis is that only the domains that are interested in doing so would have to upgrade their authoritative DNS servers in order to implement the ACLs necessary to perform DNS whitelisting. In this potential deployment scenario, it is also possible that a given domain will implement DNS whitelisting temporarily. A domain, particularly a highly-trafficked domain, may choose to do so in order to ease their transition to IPv6 through a selective deployment and minimize any perceived risk in such a transition. 6.2. Deploying DNS Whitelisting Universally The least likely deployment scenario is one where DNS whitelisting is implemented on all authoritative DNS servers, across the entire Internet. While this scenario seems less likely than ad hoc deployment due to some parties not sharing the concerns that have so far motivated the use of DNS whitelisting, it is nonetheless conceivable that it could be one of the ways in which DNS whitelisting is deployed. Significantly, the partial-deployment model casts this mechanism as a trans= ition expedient -- as the document reasonably describes it -- whereas universal deployment casts it as a fundamental change to the architecture. Given that it would take decades to achieve relatively full deployment of t= his 'across the entire Internet', what is the benefit of discussing this highly unlikely scenario? Is it really "conceivable"? I doubt it. If you think otherwise, the paper needs to explore the deployment and adoption issues in= much more detail, because I don't see how it could work. [JL] Per my previous email responses this has been extensively reworked. I = feel I should probably leave the universal deployment scenario in there for= completeness, but it's been cut down and minimized. I'm open to reconsider= ing the question later. In order for this deployment scenario to occur, it is likely that DNS whitelisting functionality would need to be built into all authoritative DNS server software, and that all operators of authoritative DNS servers would have to upgrade their software and enable this functionality. It is likely that new Internet Draft documents would need to be developed which describe how to properly configure, deploy, and maintain DNS whitelisting. As a result, it is Livingood Expires August 26, 2011 [Page 14] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 unlikely that DNS whitelisting would, at least in the next several years, become universally deployed. Furthermore, these DNS whitelists are likely to vary on a domain-by-domain basis, depending upon a variety of factors. Such factors may include the motivation of each domain owner, the location of the DNS recursive resolvers in relation to the source content, as well as various other parameters that may be transitory in nature, or unique to a specific end user host type. It is probably unlikely that a single clearinghouse for managing whitelisting is possible; it will more likely be unique to the source content owners and/or domains which implement DNS whitelists. While this scenario may be unlikely, it may carry some benefits. First, parties performing troubleshooting would not have to determine whether or not DNS whitelisting was being used, as it always would be in use. In addition, if universally deployed, it is possible that the criteria for being added to or removed from a DNS whitelist could be standardized across the entire Internet. Nevertheless, even if uniform DNS whitelisting policies were not standardized, is also possible that a central registry of these policies could be developed and deployed in order to make it easier to discover them, a key part of achieving transparency regarding DNS whitelisting. Is any of this paragraph realistic? Obviously my asking means I don't it i= s. These seem to be of theoretical rather than pragmatic interest. ("If every= one refuses to shoot, there will be no wars.") It's true that this is an "implications" paper rather than a BCP, but still= ... [JL] Good point. Paragraph removed. 7. Implications of DNS Whitelisting There are many potential implications of DNS whitelisting. The key potential implications are detailed below. 7.1. Architectural Implications DNS whitelisting could be perceived as modifying the end-to-end model and/or the general notion of the architecture that prevails on the I'll suggest that perception is not a major issue about a technical topic l= ike this. (It's not entirely irrelevant, of course, but I suspect it is quite = minor.) The major issue is whether it /actually/ modifies the end-to-end nature of = the DNS. And I think it does, as well as modifying the "spontaneous interoperability" expectation for most Internet mechanism, since it require= s prior registration. [JL] Removed the perception stuff=85 7.2. Public IPv6 Address Reachability Implications The predominant experience of end user hosts and servers on the IPv4- addressed Internet today is that when a new server with a public IPv4 address is added to the DNS, that it is then globally accessible by This sentence is not quite correct, in strict technical terms. Since this = is a technical discussion, we need to be precise: the host is reachable when th= e routing tables make it reachable. That's strictly a mapper of IP Address handling, not name-to-address mapping. What you mean is that its domain name is immediately useful for reaching it= . [JL] Correction made. IPv4-addressed hosts. This is a generalization and in Section 5 there are examples of common cases where this may not necessarily be the case. For the purposes of this argument, that concept of accessibility can be considered "pervasive reachability". It has so far been assumed that the same expectations of pervasive reachability would exist in the IPv6-addressed Internet. However, if DNS whitelisting is deployed, this will not be the case since only end user hosts using DNS recursive resolvers which are included in the again, you mean /name-based/ reachability. [JL] Fixed. In a way I was grasping at the "spontaneous interoperability" n= otion you mentioned. Livingood Expires August 26, 2011 [Page 16] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 ACL of a given domain using DNS whitelisting would be able to reach new servers in that given domain via IPv6 addresses. The expectation of any end user host being able to connect to any server (essentially both hosts, just at either end of the network), defined here as "pervasive reachability", will change to "restricted reachability" with IPv6. Establishing DNS whitelisting as an accepted practice in the early phases of mass IPv6 deployment could well establish it as an integral part of how IPv6 DNS resource records are deployed globally. As a result, it is then possible that DNS whitelisting could live on for decades on the Internet as a key foundational element of domain name management that we will all live with for a long time. (that last sentence could benefit from some editing.) [JL] Ack =96 fixed. It is a critical to understand that the concept of reachability described above depends upon a knowledge or awareness of an address in the DNS. Thus, in order to establish reachability to an end point, a host is dependent upon looking up an IP address in the DNS If this section were started with a sentence like this, then there would no= t be a problem with the other references' being confused with address-based rout= ing reachability. [JL] Great point! I've actually moved the last paragraph to the start of th= at section and it makes much more sense. when a FQDN is used. When DNS whitelisting is used, it is quite likely the case that an IPv6-enabled end user host could ping or connect to an example server host, even though the FQDN associated with that server host is restricted via a DNS whitelist. Since most First, I suspect that "example" doesn't add meaning to the sentence. Secon= d, pinging and connecting might happen with or without the whitelist entry. S= o I do not understand what import there is in this sentence. [JL] I removed pinging but left connecting. What I'm saying you may still b= e able to connect to the host via an IP if you cannot use the FQDN (it won'= t always be the case, such as on a virtual web server sharing one IP across= several sites). I'll reword it a bit though since I see your point. Internet applications and hosts such as web servers depend upon the DNS, and as end users connect to FQDNs such as www.example.com and do not remember or wish to type in an IP address, the notion of reachability described here should be understood to include knowledge how to associate a name with a network address. Again, this 'premise' statement should introduce the sub-section, not end i= t. [JL] Done (as noted above) 7.3. Operational Implications This section explores some of the operational implications which may occur as a result of, are related to, or become necessary when engaging in the practice of DNS whitelisting. 7.3.1. De-Whitelisting May Occur The more general version of this issue is 'synchronization'. Entries in th= e whitelist need to be synchronized with host status and capabilities. It is possible for a DNS recursive resolver added to a whitelist to then be removed from the whitelist, also known as de-whitelisting. Since de-whitelisting can occur, through a decision by the authoritative server operator, the domain owner, or even due to a technical error, an operator of a DNS recursive resolver will have new operational and monitoring requirements and/or needs as noted in Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. 7.3.2. Authoritative DNS Server Operational Implications Operators of authoritative servers may need to maintain an ACL a a -> on a (?) [JL] fixed server-wide basis affecting all domains, on a domain-by-domain basis, Livingood Expires August 26, 2011 [Page 17] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 as well as on a combination of the two. As a result, operational I'm not really understanding the first sentence. One problem might be that= its discussing an implication of some configuration or usage options that have = not been previously specified, so that the reference here might be overly crypt= ic. For example, I don't know what "affecting all domains" actually means. It almost sounds as if it could mean "everyone gets AAAA records" or "no one g= ets AAAA records" yet I'm reaonably certain that is /not/ what is meant. [JL] Yes, that sentence was unclear. It is now: "Operators of authoritative servers (which are frequently authoritative for= multiple domain names) will need to maintain an ACL on a server-wide basis= affecting all domains, or on a domain-by-domain basis." practices and software capabilities may need to be developed in order to support such functionality. In addition, processes may need to be put in place to protect against inadvertently adding or removing IP addresses, as well as systems and/or processes to respond to such incidents if and when they occur. For example, a system may be needed to record DNS whitelisting requests, report on their status along a workflow, add IP addresses when whitelisting has been approved, remove IP addresses when they have been de-whitelisted, log the personnel involved and timing of changes, schedule changes to occur in the future, and to roll back any inadvertent changes. Might be worth starting with a simple, broad summary statement, possibly al= ong the lines of: An AAAA DNS Whitelist serves as a critical infrastructure service; to b= e useful it needs careful and extensive administration, monitoring and operat= ion. Each new and essential mechanism creates substantial follow-on support co= sts. [JL] Thanks =96 added that text. Operators may also need implement new forms of monitoring in order to apply change control, as noted briefly in Section 7.3.4. 7.3.3. DNS Recursive Resolver Server Operational Implications Operators of DNS recursive resolvers, which may include ISPs, enterprises, universities, governments, individual end users, and many other parties, are likely to need to implement new forms of monitoring, as noted briefly in Section 7.3.4. But more critically, such operators may need to add people, processes, and systems in order to manage large numbers of DNS whitelisting applications as part of their own IPv6 transition, for all domains that the end users of such servers are interested in now or in which they may be I think the summary observation is simple and should be stated directly: T= his is a manual mechanism that becomes expensive in time and personnel effort a= s it scales up. [JL] Added that interested in the future. As anticipation of interesting domains is likely infeasible, it is more likely that operators may either choose to only apply to be whitelisted for a domain based upon one or more end user requests, or that they will attempt to do so for all domains that they can ascertain to be engaging in DNS whitelisting. "attempt to do so for all domain that they can ascertain to be engaging in = DNS whitelisting" appears to be saying to do whitelisting for domains that do whitelisting. I don't understand. [JL] I was going to great effort to badly make a point that you can't antic= ipate all domains users will want to access and so will need a way for user= s to request whitelisting instead. I've reworded as: "But more critically, such operators will need to add people, processes, an= d systems in order to manage large numbers of DNS Whitelisting applications= . Since there is no common method for determining whether or not a domain i= s engaged in DNS Whitelisting, operators will have to apply to be whitelist= ed for a domain based upon one or more end user requests, which means syste= ms, processes, and personnel for handling and responding to those requests = will also be necessary." When operators apply for DNS whitelisting for all domains, that may "apply for DNS whitelisting for all domains" -- again I'm not understanding= what this means. [JL] See above 7.3.5. Implications of Operational Momentum It seems plausible that once DNS whitelisting is implemented it will be very difficult to deprecate such technical and operational practices. This assumption is based in an understanding of human in -> on [JL] Fixed nature, not to mention physics. For example, as Sir Issac Newton noted, "Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it" [Laws Code does not have momenum. Neither do configurations or lists. This real= ly isn't about physics. [JL] But people and processes do have (operational) momentum=85 It is entirely about group psychology, as you note, and the administrative challenges in the logistics of large-scale operational changes (which proba= bly /does/ have something to with physics, but it seems a stretch to credit New= ton. How about Heisenberg?...) [JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an inter= esting citation I feel it's almost a personal challenge to figure out a way= to keep it in there. ;-) The way I think about it is that in 5 or 10 years= none of the people working on the details of the IPv6 transition now will = still be involved in the day-to-day operational work. But DNS Whitelisting = could still be in place =96 and once something gets a momentum to it (peopl= e, processes, and organizations) it is really, really hard to change that. = This seems very much like the physics principle to which I refer but I'm op= en to other citations. I envision this possibility: Q (from new trainee): Why are we doing this DNS Whitelisting thing? A: Because that's what we have to do for IPv6 access to every new domain. Q: Why? A: Because we've been doing it for years and it says to do it here in this = operations manual we have to follow. Q: Then I guess we should keep doing it? A: Yes, we should. It'd be hard to change the standard process, and we'd ha= ve to escalate it to someone, etc. of Motion]. Thus, once DNS whitelisting is implemented it is quite likely that it would take considerable effort to deprecate the practice and remove it everywhere on the Internet - it will otherwise simply remain in place in perpetuity. To better illustrate this point, one could consider one example (of many) that there are many email servers continuing to attempt to query or otherwise check anti- Livingood Expires August 26, 2011 [Page 19] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 spam DNS blocklists which have long ago ceased to exist. 7.3.6. Troubleshooting Implications The implications of DNS whitelisted present many challenges, which have been detailed in Section 7. These challenges may negatively But this is /still/ section 7. Can you be more specific? Or perhaps say "throughout this section". [JL] fixed affect the end users' ability to troubleshoot, as well as that of DNS recursive resolver operators, ISPs, content providers, domain owners (where they may be different from the operator of the authoritative DNS server for their domain), and other third parties. This may make the process of determining why a server is not reachable significantly more complex. 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, I'm pretty sure that scaling problems for this exist in all scenarios, not = just ad hoc usage. [JL] True. Simplified to: "As more domains choose to implement DNS Whitelisting, and more networks be= come IPv6-capable and request to be whitelisted, scaling up operational pro= cesses, monitoring, and ACL updates will become more difficult. The increas= ed rate of change and increased size of whitelists will increase the likeli= hood of configuration and other operational errors." monitoring, and ACL updates. In particular, it seems likely that as the number of domains that are using DNS whitelisting increases, as well as the number of IPv6-capable networks requesting to be whitelisted, that there is an increased likelihood of configuration and other operational errors, especially with respect to the ACLs themselves. It is unclear when and if it would be appropriate to change from whitelisting to blacklisting, and whether or how this could feasibly be coordinated across the Internet, which may be proposed or Actually the question of coordination is quite clear and rather fundamental= : No. Anyone believing otherwise needs to cite a successful example, at Internet = scale and diversity, more recently than the 1983 switch to IP (which didn't go al= l that well anyhow...) Simple, unambiguous showstoppers should be stated in a simple and direct ma= nner. When there is room for debate, softer language makes sense. Again, if th= e question of coordination really is subject to debate, then the basis needs = to be stated. (Good luck!) [JL] That's not encouraging=85 Changed to: "It is unclear when and if it would be appropriate to change from whitelist= ing to blacklisting. It is clear that trying to coordinate this across the = Internet is likely be be impossible, so such a change to blacklisting would= happen on a domain-by-domain basis (if at all)." implemented on an ad hoc basis when a majority of networks (or allocated IPv6 address blocks) have been whitelisted. Finally, some parties implementing DNS whitelisting consider this to be a temporary measure. As such, it is not clear how these parties will judge the network conditions to have changed sufficiently to justify disabling DNS whitelisting and/or what the process and timing will be in order to discontinue this practice. One further potential implication is that an end user with only an IPv4 address, using a DNS resolver which has not been whitelisted by any domains, would not be able to get any AAAA resource records. In such a case, this could give that end user the incorrect impression that there is no IPv6-based content on the Internet since they are unable to discover any IPv6 addresses via the DNS. 7.4. Homogeneity May Be Encouraged A broad trend which has existed on the Internet appears to be a move towards increasing levels of heterogeneity. One manifestation of increasing levels of heterogeneity -> more heterogeneity [JL] fixed (I think heterogeneity does not have 'levels'.) Substantively: say the nature of the heterogeneity within the initial clai= m. For example, there is /less/ heterogeneity of ISPs, given industry consolidation. There is less heterogeneity of infrastructure equipment suc= h as routers. Etc. [JL] I have gotten lots and lots of questions related to this section, whic= h led me to conclude that I've done a poor job stating the issue. I was dan= cing around it but here it is more directly in an updated section (the new = 2nd and final paragraph of this section): "Some forms of so-called "network neutrality" principles around the world i= nclude the notion that any IP-capable device should be able to connect to a= network, which seems to encourage heterogeneity. These principles are ofte= n explicitly encouraged by application providers given the reasons noted ab= ove, though some of these same providers may also be implementing DNS White= listing. This is ironic, as one implication of the adoption of DNS Whitelis= ting is that it encourages a move back towards homogeneity. This is because= some implementers have expressed a preference for greater levels of contro= l by networks over end user hosts in order to attempt to enforce technical = requirements intended to reduce IPv6-related impairments. This return to an= environment of more homogenous and/or controlled end user hosts could have= unintended side effects on and counter-productive implications for future = innovation at the edges of the network." this is in an increasing number, variety, and customization of end user hosts, including home network, operating systems, client Livingood Expires August 26, 2011 [Page 20] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 software, home network devices, and personal computing devices. This trend appears to have had a positive effect on the development and growth of the Internet. A key facet of this that has evolved is the ability of the end user to connect any technically compliant device or use any technically compatible software to connect to the Internet. Not only does this trend towards greater heterogeneity reduce the control which is exerted in the middle of the network, described in positive terms in [Tussle in Cyberspace], [Rethinking the Internet], and [RFC3724], but it can also help to enable greater and more rapid innovation at the edges. An unfortunate implication of the adoption of DNS whitelisting may be the encouragement of a reversal of this trend, which would be a move the encouragement of -> to encourage [JL] totally changed this, as noted above. 8.1. Implement DNS Whitelisting Universally One obvious solution is to implement DNS whitelisted universally, and to do so using some sort of centralized registry of DNS whitelisting policies, contracts, processes, or other information. This potential solution seems unlikely at the current time. I'm pretty sure that the only thing that is obvious about a premise of univ= ersal adoption is that it's not practical. Seriously. At the least, this section needs to be less cavalier about putting this alternative forward as a "solution", especially given the rather serious drawbacks/problems with it. [JL] Fixed 8.2. Implement DNS Whitelisting On An Ad Hoc Basis If DNS whitelisting is to be adopted, it is likely to be adopted on "is to be"? I thought it already had a significant installed base. [JL] Fixed. this ad hoc, or domain-by-domain basis. Therefore, only those domains interested in DNS whitelisting would need to adopt the practice, though as noted herein discovering that they a given domain has done so may be problematic. Also in this scenario, ad hoc use by a particular domain may be a temporary measure that has been adopted to ease the transition of the domain to IPv6 over some short-term timeframe. 8.3. Do Not Implement DNS Whitelisting As an alternative to adopting DNS whitelisting, the Internet community generally can choose to take no action whatsoever, perpetuating the current predominant authoritative DNS operational model on the Internet, and leave it up to end users with IPv6-related impairments to discover and fix those impairments. That is, place the burden of fixing a problem on those creating it? [JL] In a way. It gets back to the question you asked about what level of i= mpairment justifies this practice. One obvious option is to let end users s= ort it out (presumably by consulting with their ISPs / network operators). = This may be simpler and it's the way solutions to non-IPv6 problems tend to= work today. Livingood Expires August 26, 2011 [Page 23] Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 8.3.1. Solving Current End User IPv6 Impairments A further extension of not implementing DNS whitelisting, is to also endeavor to actually fix the underlying technical problems that have prompted the consideration of DNS whitelisting in the first place, as an alternative to trying to apply temporary workarounds to avoid the symptoms of underlying end user IPv6 impairments. A first step is obviously to identify which users have such impairments, which would appear to be possible, and then to communicate this information to end users. Such end user communication is likely to be most helpful if the end user is not only alerted to a potential problem but is given careful and detailed advice on how to resolve this on their own, or where they can seek help in doing so. Section 11 may also be relevant in this case. 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. This 'challenge' is at the core of /all/ adoption efforts for Internet prot= ocols and services that entail distributed adoption. Despite any potential challenges, many in the Internet community are already working towards this goal and/or have expressed a general preference for this approach. If this is not already an organized effort with a website, sponsoring consortium, or the like, it should be. If it is, then cite it in this doc! [JL] Fixed. It is World IPv6 Day and the many efforts related to that. 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. I do not understand what this means. What is it for? What are the results? How are theyused? [JL] Ack. This has been clarified in the =9604. 9. Is DNS Whitelisting a Recommended Practice? Opinions in the Internet community concerning whether or not DNS whitelisting is a recommended practice are understandably quite varied. However, there is clear consensus that DNS whitelisting is at best a useful temporary measure which a domain may choose to If that is a clear consensus, then it makes even less sense to promote the = idea of universal adoption, given the timescale needed to achieve it. 10. Security Considerations There are no particular security considerations if DNS whitelisting is not adopted, as this is how the public Internet works today with A resource records. Or rather, failure to adopt a mechanism like this or repair the underlying problem, for those sites experiencing that problem, will result in a denial= of service, albeit not an intentional one. Still, that's a pretty basic secur= ity issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --_000_CA084387289FFjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Dave =96 Thanks for this email as well. It is my last item in queue be= fore posting an updated =9604 draft (whew!). See some specific responses in= line below.

Thanks
JL

On 5/9/11 1:18 PM, "Dave CROCKER" <dhc@dcrocker.net> wrote:

(This is an "official" and significantly extended version of= an informal and
narrow review I posted earlier.  /d)

Howdy.

I have been selected as the Applications Area Review Team reviewer for= this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments = you may
receive. Please wait for direction from your document shepherd or AD b= efore
posting a new version of the draft.

Review (v2):

Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-impl= ications-03

By:     D. Crocker <dcrocker@bbiw.net>
Date:   <>

Summary
=3D=3D=3D=3D=3D=3D=3D

This draft covers a a dual-stack problem in which a target host's DNS = entry
contains records for IPv4 and IPv6, but returning IPv6 information to = a DNS
client can cause problems. The paper discusses for resolving this thro= ugh use of
a a DNS-based mechanism that manually lists response preferences to se= lect which
DNS records to return.  The paper describes the mechanism an= d explores various
effects and possibilities of its use, including the difference between= using it
selectively among a smaller number of sites, versus universally.

The draft is a serious effort to explore the use of such a mechanism a= nd it
touches many different issues.  It is generally well-organiz= ed and clearly
written, although it very much needs the aid of a professional technic= al editor.
The writing often assumes too much knowledge by the reader.

The paper's exploration of universal adoption seems to vary between co= nsidering
that goal practical versus considering it only as a matter of complete= ness for
discussing the full range of possibilities.  That is, it is = not clear whether
the paper views this alternative as practically possible and even pref= erred,
versus only a matter for academic thoroughness.

[JL] I consider it the latter =96 highly unlikely but included for com= pleteness (on the assumption that a failure to include it would lead to com= ments that it was incomplete without it). However the =9604 update will mak= e more clear the remoteness of the possibility of universal deployment. 

The paper needs to take a basic
position about feasibility, explain it in terms of comparable adoption= efforts
at Internet-scale, and then make its treatment of universal adoption a= bit more
consistent.

[JL] Good feedback - I've tried to do that in the =9604 version.

When introducing terms, mechanisms, configurations and scenarios, the = paper
needs to be more careful to describe them adequately for a reader new = to the
topic.  This is not a matter of having a tutorial about the = DNS, but rather a
tutorial for this type of mechanism and when and how it can be used.

As a specific example, the document cites "domain-by-domain"= use, but I am not
clear how that would work, in terms of configuration and cross-net inf= ormation
exchange.  One question is how the server knows the 'domain'= of the client?

The document should careful to distinguish what is existing practice, = versus
what is being explored as added possibilities.  The differen= ce in concreteness
and certitude between the two is substantial.

The document's use of the term whitelisting appears to continue an exi= sting,
recent use, for this type of mechanism.  Unfortunately it di= rectly conflicts
with long-standing use of the term by the anti-abuse community for whi= telisting
in the DNS. Its use here also seems to be a mismatch with the word's d= ictionary
semantics, which is most naturally used to distinguish yes/no choices,= rather
than either/or choices.  So there is no intuitive sense of &= quot;goodness" (whitelist
=3D yes) or "badness" (blacklist) for this use. The word &qu= ot;preferences" seems more
in line with the meaning of the mechanism.

[JL] Duly noted in my previous emails. I'm keeping the naming as an op= en issue in the =9604 and will be seeking WG and WG co-chair guidance one w= ay or the other. Your other notes have also suggested a simplification of t= he document in some respects so that is also noted as an open item as well (but I really do need to get an upda= te out in the meantime).

Detailed Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Abstract

    The objective of this document is to describe = what the whitelisting
    of DNS AAAA resource records is, hereafter ref= erred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the rec= ords that are
whitelisted?

Does this mean putting whitelisting records into the DNS or does it me= an
something else?

Comcast's own considerable expertise notwithstanding, has this doc bee= n vetted
with a range of organizations that actually DO whitelisting? &nbs= p;Has it been
circulated through MAAWG and APWG?  Any comments from Spamha= us?  The
Acknowledgements list does not seem to indicate a range of whitelist o= ps folks
whose names I know.  (But then, I only know a few...)

[JL] Per my other note today, this will be fixed in the =9604.

    whitelisting, as well as the implications of t= his emerging practice
    and what alternatives may exist.  Th= e audience for this document is
    the Internet community generally, including th= e IETF and IPv6
    implementers.

I suspect that product marketers won't have much interest in this.&nbs= p; I suspect
that the target for this is anti-abuse technical and operations staff.= In any
event, the targetting statement should be more precise.

[JL] Addressed in my earlier response to your shorter review.

1.  Introduction

    This document describes the emerging practice = of whitelisting of DNS

One natural, semantic problem with the term 'whitelist' is that it doe= s not
really match the function being performed.  The white/black = distinction implies
goodness -- or as Wikipedia says, "priviledge".  I= nstead, the use here is for
preference or priority.  What would a "blacklist" = be, here?  Also note it is not
obvious what it means to be whitelisted, here?  Does it mean= to choose the AAAA
records or the A records?

This is more like a 'Preference' or 'Configuration' list.

At the least, the name for this should be IPv6 Resolver Whitelisting.&= nbsp; It makes
clear /what/ is being "whitelisted".

[JL] Ack. Carried in Open Items for =9604.

    AAAA resource records (RRs), which contain IPv= 6 addresses, hereafter
    referred to as DNS whitelisting.  Th= e document explores the

This provides a name, but not a function.  That is, it does = not say what this
mechanisms actually /does/ or is /for/.

[JL] Addressed in my earlier response to your shorter review.

    implications of this emerging practice are and= what alternatives may
    exist.

    The practice of DNS whitelisting appears to ha= ve first been used by
    major web content sites (sometimes described h= erein as "highly-

It's use for email anti-abuse dates back farther.




Specifically within the context of the DNS, the term whitelisting is t= herefore
made ambiguous.

A google query for "whitelist dns" also demonstrates the his= tory and current
ambiguity.

[JL] Addressed in my earlier response to your shorter review.

    trafficked domains" or "major domain= s").  These web site operators,
    or domain operators, observed that when they a= dded AAAA resource
    records to their authoritative DNS servers in = order to support IPv6
    access to their content that a small fraction = of end users had slow
    or otherwise impaired access to a given web si= te with both AAAA and A
    resource records.  The fraction of u= sers with such impaired access
    has been estimated to be roughly 0.078% of tot= al Internet users
    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating= IPv6 Adoption] [IPv6
    Brokenness].  Thus, in an example In= ternet Service Provider (ISP)
    network of 10 million users, approximately 7,8= 00 of those users may
    experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across I= Pv6
users/traffic, given how small a percentage that is, in total users an= d total
traffic.  If that's what is meant it should be stated. =  If it isn't, the
statistic should be recalculated and explained a bit more precisely.

[JL] Addressed in my earlier response to your shorter review.

    As a result of this impairment affecting end u= sers of a given domain,
    a few major domains have either implemented DN= S whitelisting or are
    considering doing so [NW-Article-DNS-WL] [IPv6= Whitelist Operations].
    When implemented, DNS whitelisting in practice= means that a domain's
    authoritative DNS will return a AAAA resource = record to DNS recursive
    resolvers [RFC1035] on the whitelist, while re= turning no AAAA
    resource records to DNS resolvers which are no= t on the whitelist.  It

This explanation of the function should be offered sooner and should b= e
summarized in the Abstract.

[JL] Good suggestion =96 made some tweaks to the Abstract to try to ad= dress this.

    is important to note that these major domains = are motivated by a
    desire to maintain a high-quality user experie= nce for all of their

Rather than being important to note, this sentence sounds oddly like m= arketing
hype, in a technical specification.  It is gratuitous becaus= e specified features
are never added to /lower/ the quality of the user experience, for exa= mple.

In addition, the mechanism also affects client activity that has no us= er
directly involved.


    users.  By engaging in DNS whitelist= ing, they are attempting to
    shield users with impaired access from the sym= ptoms of those
    impairments.

The /technical/ statement that should be here is that they are attempt= ing to
provide a work-around for problematic behaviors in dual-stack IPv4/IPv= 6
environments.

The paper should make more clear exactly where the problem lies and wh= en. If it
can occur for a number of reasons, explaining each of those scenarios = would be
useful.

[JL] I've attempted to do so in the =9604 update.

    Critics of the practice of DNS whitelisting ha= ve articulated several
    concerns.  Among these are that:

    o  DNS whitelisting is a very differ= ent behavior from the current
       practice concerning the publishin= g of IPv4 address resource
       records,

    o  that it may create a two-tiered I= nternet,

    o  that policies concerning whitelis= ting and de-whitelisting are
       opaque,

Livingood          &= nbsp;     Expires August 26, 2011   = ;            &n= bsp;[Page 5]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    o  that DNS whitelisting reduces int= erest in the deployment of IPv6,

    o  that new operational and manageme= nt burdens are created,

well, yeah... in fact it should be noted that the burdens are particul= arly
onerous at scale.

[JL] Ack =96 updated the text to reflect this



    o  and that the costs and negative i= mplications of DNS whitelisting
       outweigh the perceived benefits, = compared to fixing underlying
       impairments.

and it doesn't scale.

and it violates an extremely basic premise of cross-Internet interoper= ability by
requiring prior arrangement.

[JL] Ack =96 added this

    This document explores the reasons and motivat= ions for DNS
    whitelisting.  It also explores the = outlined concerns regarding this
    practice.  Readers will hopefully be= tter understand what DNS
    whitelisting is, why some parties are implemen= ting it, and what
    criticisms of the practice exist.


2.  How DNS Whitelisting Works

How IPv6 AAAA DNS Whitelisting Works.

(Anti-spam DNS Whitelisting works rather differently...)


    DNS whitelisting is implemented in authoritati= ve DNS servers.  These
    servers implement IP address-based restriction= s on AAAA query
    responses.  So far, DNS whitelisting= has been primarily implemented
    by web server operators deploying IPv6-enabled= services.  For a given

Really?  This is web-specific?  The same restricti= ons are not applied for other
applications?

So if the same client-side hosts attempt to contact the server for ema= il or
xmpp, they won't get the same handling?

[JL] Quite so =96 I updated the text to clarify this.

    operator of a website, such as www.example.com= , the operator
    essentially applies an access control list (AC= L) on the authoritative
    DNS servers for the domain example.com. &= nbsp;The ACL is populated with

An ACL usually is a yes/no mechanism.  Here, however, the me= chanism is for
asserting a preference for IPv6 over IPv4.

That does not seem to match the definition of ACL that I'm used to, un= less the
semantic is defined as denying IPv4 access to the listed clients.

The term ACL is particularly odd to use if the mechanism pertains to r= esponses
rather than queries.

[JL] I am using 'ACL' in the most general possible sense and am open t= o alternative descriptors if you wish to suggest one. But most people seem = to know an ACL is a list that, if you are listed on it, grants you access t= o some resource. In this case if the resolver is on the list then it gets AAAA RRs.

    the IPv4 and/or IPv6 addresses or prefix range= s of DNS recursive

Either address type can be listed?  So this really is a pure= 'preferences'
mechanism?

Which settings count as whitelisting?  Do any count as black= listing?

[JL] A resolver can have both IPv6 and IPv4 addresses. Whether a resol= ver is listed on the whitelist and is therefore able to receive AAAA RR res= ponses is orthogonal to whether the resolver itself has an IPv4 or IPv6 add= ress =97 since the whitelisting decision making tends to be based on some conclusion about the hosts that query the= resolver rather than the resolver.

    resolvers on the Internet, which have been aut= horized to receive AAAA
    resource record responses.  These DN= S recursive resolvers are
    operated by third parties, such as ISPs, unive= rsities, governments,
    businesses, and individual end users. &nb= sp;If a DNS recursive resolver IS
    NOT matched in the ACL, then AAAA resource rec= ords will NOT be sent
    in response to a query for a hostname in the e= xample.com domain.

This configuration appears to ensure the maximum barrier to adoption f= or IPv6,
since it means that IPv6 will not work automatically.  It wi= ll only work for
hosts that are manually configured to receive responses with v6 record= s.

That's a rather major implication.  It's a default that is p= robably meant to
apply during the very early stages of adoption, when there are few use= rs of the
newer mechanism.

It's probably worth discussing it in more detail, including discussing= when to
change the default...

[JL] Correct on all 3 points. I've tried to address this better in the= =9604 version.

    However, if a DNS recursive resolver IS matche= d in the ACL, then AAAA
    resource records will be sent in response to a= query for a given
    hostname in the example.com domain.  = ;While these are not network-
    layer access controls they are nonetheless acc= ess controls that are a
    factor for end users and other parties like ne= twork operators,
    especially as networks and hosts transition fr= om one network address
    family to another (IPv4 to IPv6).

Also, all of this clarifies the function of this listing mechanism and= suggests
a very different name, to be more precise and accurate in naming it:

     IPv6 DNS Response Preference List.

[JL] I've added all the various naming suggestions to the Open Issues = section.

    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.&nb= sp; The large majority of
    DNS resolvers on the Internet will therefore r= eceive only A resource
    records containing IPv4 addresses.  = Thus, quite simply, the
    authoritative server hands out different answe= rs depending upon who
    is asking; with IPv4 and IPv6 resource records= for some on the
    authorized whitelist, and only IPv4 resource r= ecords for everyone
    else.  See Section 2.1 and Figure 1 = for a description of how this



Livingood          &= nbsp;     Expires August 26, 2011   = ;            &n= bsp;[Page 6]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    works.

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

2.1.  Description of the Operation of DNS Whitelisting

    The system logic of DNS whitelisting is as fol= lows:

    1.  The authoritative DNS server for= example.com receives DNS queries
        for the A (IPv4) and A= AAA (IPv6) address resource records for the
        FQDN www.example.com, = for which AAAA (IPv6) resource records
        exist.

This means that the mechanism is /only/ triggered when /both/ address = records
are queried?  A query for only one type of address record wo= n't trigger the list
lookup?  I think that doesn't match other statements in the = document.

[JL] Updated to clarify / correct my text. (changed A and AAAA to and/= or)



    2.  The authoritative DNS server exa= mines the IP address of the DNS
        recursive resolver sen= ding the AAAA (IPv6) query.

"examines"?  Examines it for what?  What= does this step mean?

[JL] Examines as in looks at the IP address. I'll just simplify it and= combine it with #3.

    3.  The authoritative DNS server che= cks this IP address against the
        access control list (A= CL) that is the DNS whitelist.

    4.  If the DNS recursive resolver's = IP address IS matched in the ACL,
        then the response to t= hat specific DNS recursive resolver can
        contain AAAA (IPv6) ad= dress resource records.

Oh.  This is not about whether to send responses /over/ v6 v= s. v4?  This is
whether to /include/ a particular type of RR in responses???

In that case an appropriate name for this mechanism is more like:

    DNS Response Content Preference List

[JL] Adding this suggested name to the Open Issues list as well.

And this seems even less like an ACL than it did before.  (I= assume the
justification is that access is being prevented by virtue of not suppl= ying the
address, but still...)


    5.  If the DNS recursive resolver's = IP address IS NOT matched in the
        ACL, then the response= to that specific DNS recursive resolver
        cannot contain AAAA (I= Pv6) address resource records.  In this
        case, the server shoul= d return a response with the response code
        (RCODE) being set to 0= (No Error) with an empty answer section
        for the AAAA record qu= ery.

Livingood          &= nbsp;     Expires August 26, 2011   = ;            &n= bsp;[Page 7]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    ----------------------------------------------= -----------------------
    A query is sent from a DNS recursive resolver = that IS NOT on the DNS
    whitelist:

           &nbs= p;    Request       =             &nb= sp;  Request
           &nbs= p;www.example.com         &nbs= p;        www.example.com
           &nbs= p;      AAAA    +----= ---------+     AAAA    +---= --------------+
      ++--++  = ---------> |  RESOLVER   |  --------->= | www.example.com |
      ||  ||   =     A      | **IS NOT** &= nbsp;|      A     &n= bsp;| IN A exists     |
    +-++--++-+ ---------&g= t; |     ON      | &= nbsp;---------> | IN AAAA exists  |
    +--------+     A&n= bsp;     | example.com |    &n= bsp; A      |    &nb= sp;            |
       Host    <-= -------- |  WHITELIST  |  <--------- |&nbs= p;            &= nbsp;   |
     Computer   A Record  += ;-------------+  A Record   +-----------------&= #43;
           &nbs= p;    Response   DNS Recursive   Re= sponse       example.com
           &nbs= p;   (only IPv4)   Resolver     (on= ly IPv4)    Authoritative
           &nbs= p;            &= nbsp;      #1      &= nbsp;           &nbs= p;        Server
    ----------------------------------------------= -----------------------
    A query is sent from a DNS recursive resolver = that IS on the DNS
    whitelist:

           &nbs= p;    Request       =             &nb= sp;  Request
           &nbs= p;www.example.com         &nbs= p;        www.example.com
           &nbs= p;     AAAA     +-------------&= #43;     AAAA    +-------------= ----+
      ++--++  = ---------> |  RESOLVER   |  --------->= | www.example.com |
      ||  ||   =     A      |   **IS*= *    |      A  =     | IN A exists     |
    +-++--++-+ ---------&g= t; |     ON      | &= nbsp;---------> | IN AAAA exists  |
    +--------+   AAAA  = ;   | example.com |     AAAA   = ; |           &= nbsp;     |
       Host    <-= -------- |  WHITELIST  |  <--------- |&nbs= p;            &= nbsp;   |
     Computer      A=       |      &n= bsp;      |      A&n= bsp;     |      &nbs= p;          |
           &nbs= p;   <--------- |       &nb= sp;     |  <--------- |   &= nbsp;           &nbs= p; |
           &nbs= p;   A and AAAA +-------------+ A and AAAA  = 3;-----------------+
           &nbs= p;    Record     DNS Recursive = ;  Record        example.com
           &nbs= p;   Responses     Resolver   =   Responses      Authoritative
           &nbs= p;   (IPv4+IPv6)      #2 &= nbsp;      (IPv4+IPv6)   &= nbsp;   Server
    ----------------------------------------------= -----------------------

           &nbs= p;   Figure 1: DNS Whitelisting - Functional Diagram

This diagram is confusing to me.  I suspect that a protocol = exchange sequence
format, in the style of:

      Host     =         Resolver 1   &nbs= p;        Authoritative

           ---------= ->
           &nbs= p;            &= nbsp;         --------->
           &nbs= p;            &= nbsp;        <---------
          <------= ----

will be considerably more helpful.

[JL] I took a stab at a new diagram in =9604 =97 so take a look and le= t me know if it is what you are suggesting (I've left the original one in f= or now).

3.  What Problems Are Implementers Trying To Solve?

This is a very useful section and it is probably worth moving it highe= r, to
precede the 'how it works' section.


    As noted in Section 1, domains which implement= DNS whitelisting are
    attempting to protect a few users of their dom= ain, who have impaired
    IPv6 access, from having a negative experience= (poor performance).

By the way, what does 'impaired v6 access' mean?

I think there needs to be a simple, direct description of what occurs = without
this mechanism.

For example, perhaps you mean that a host can send DNS queries using I= Pv6 but
cannot receive DNS responses over IPv6? Perhaps you mean that the host= can send
IPv6 but cannot receive it.  (That's a different scale and s= cope of problem from
the first example I gave.)

This brief, summary problem statement should be included in the Abstra= ct, to
make /much/ more clear what this mechanism is for.

[JL] Done. Added text to the Abstract and Intro and added more to note= that this is about both impairment and (actual or perceived) immaturity of= IPv6 network routing and practices.



    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 impa= irment it is a very
    real performance impact.  It would a= ffect access to all or most dual



Livingood          &= nbsp;     Expires August 26, 2011   = ;            &n= bsp;[Page 8]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    stack services to which the user attempts to c= onnect.  This negative
    end user experience can range from someone slo= wer than usual (as
    compared to native IPv4-based access), to extr= emely slow, to no
    access to the domain whatsoever.

Rather than repeat that this is about end-users, it sounds more that t= his is
about whether a service works or does not work, whether a user is dire= ctly
present or not.


    While one can debate whether DNS whitelisting = is the optimal solution
    to the end user experience problem, it is quit= e clear that DNS
    whitelisting implementers are interested in ma= ximizing the
    performance of their services for end users as= a primary motivation
    for implementation.

You keep citing 'performance' but haven't described what sort of perfo= rmance
degradation takes place. Is this really about relatively better or wor= se
performance -- and if so, how -- or is this about working or not worki= ng?

[JL] Good point =96 I added this text: 
"In essence, whether the end user even has an IPv6 address or = not (they probably only have an IPv4 address), merely by receiving a AAAA r= ecord response the user either cannot access a FQDN or it is so slow that t= he user gives up and assumes the destination is unreachable."

Also rather than saying what implementers are interested in, it's prob= ably more
helpful to note that the practice is now significantly established and= therefore
worth documenting, independent of its possible controversy.


    At least one highly-trafficked domain has note= d that they have
    received requests to not send DNS responses wi= th AAAA resource
    records to particular resolvers.  In= this case, the operators of

"At least one" seems a rather tiny statistic.  Per= haps the actual statistic is
significantly larger?

[JL] It does not seem to be. Other than this being passed along by Goo= gle, I've not heard of any similar stories. Nevertheless, it seemed interes= ting enough to include.

    those recursive resolvers have expressed a con= cern that their IPv6

I suspect that it's not resolvers that are doing the expressing, since= their
vocabulary is usually too limited...

[JL] Quite. Updated:
"In this case, DNS recursive resolvers operators have expresse= d=85"

    network infrastructure is not yet ready to han= dle the large traffic
    volume which may be associated with the hosts = in their network
    connecting to the websites of these domains.&n= bsp; This concern is clearly

So even though the site allows v6 DNS queries to go out from a host, i= t can't
really support having the host use v6?

[JL] A network isn't really in control of the end host's limitations w= /r/t IPv6 impairment. A good summary of the issue of impairment is @ <= a href=3D"http://www.fud.no/ipv6/">http://www.fud.no/ipv6/

Wow. I do understand why service providers often have to work around s= illiness
at the client side, but this problem at the client side seems particul= arly
egregious.


    a temporary consideration relating to the depl= oyment of IPv6 network
    infrastructure on the part of networks with en= d user hosts, rather
    than a long-term concern.  These end= user networks may also have

Again this goal of short-term usage is worth noting earlier, including= in the
Abstract.


    other tools at their disposal in order to addr= ess this concern,
    including applying rules to network equipment = such as routers and
    firewalls (this will necessarily vary by the t= ype of network, as well
    as the technologies used and the design of a g= iven network), as well
    as configuration of their recursive resolvers = (though modifying or
    suppressing AAAA resource records in a DNSSEC-= signed domain on a
    Security-Aware Resolver will be problematic Se= ction 10.1).

    Some implementers with highly-trafficked domai= ns have explained that
    DNS whitelisting is a necessary, though tempor= ary, risk reduction
    tactic intended to ease their transition to IP= v6 and minimize any
    perceived risk in such a transition. &nbs= p;As a result, they perceive this
    as a tactic to enable them to incrementally en= able IPv6 connectivity
    to their domains during the early phases of th= eir transition to IPv6.

    Finally, some domains, have run IPv6 experimen= ts whereby they added
    AAAA resource records and observed and measure= d errors [Heise Online
    Experiment], which should be important reading= for any domain
    contemplating either the use of DNS whitelisti= ng or simply adding
    IPv6 addressing to their site.


4.  Concerns Regarding DNS Whitelisting

    There are a number of potential implications r= elating to DNS
    whitelisting, which have been raised as concer= ns by some parts of the
    Internet community.  Many of those p= otential implications are further

I think the implications are not conditional; they exist rather than b= eing
potential.  The 'potential' is that what is implicated will = come to pass.

[JL] Fair point =96 removed 'potential' there and in another similar s= ection.


Livingood          &= nbsp;     Expires August 26, 2011   = ;            &n= bsp;[Page 9]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    enumerated here and in Section 7.

Pro forma question:  Why are implications discussed in multi= ple places?

[JL] Some of them in are briefly noted in Section 4, but the exhaustiv= e list in in Section 7. 



    Some parties in the Internet community, includ= ing ISPs, are concerned

This style of text personalizes the issues unnecessarily (IMO). &= nbsp;It does not
really matter who holds the concerns, or else they'd be described more= precisely.

[JL] I'll have to look at that after the =9604 update. In a previous d= raft I was asked to call out different parts of the community separately. (= Always challenging to work through conflicting feedback.)


I suggest merely noting that there are concerns and then listing and d= iscussing
the concerns, rather than adding text to attribute the concerns to oth= ers, even
if the conclusion of your text is that a particular concern is not val= id.

[JL] Duly noted. Let me get the =9604 update out, after which I will l= ook at generally simplifying the I-D and look at this issue specifically.



    that the practice of DNS whitelisting for IPv6= address resource
    records represents a departure from the genera= lly accepted practices
    regarding IPv4 address resource records in the= DNS on the Internet
    [Whitelisting Concerns].  These part= ies explain their belief that for

"These parties explain their belief" is an example of person= alization that is
not needed.  This isn't about the believers.  It i= s about possible problems.

[JL] Ack.

    A resource records, containing IPv4 addresses,= once an authoritative
    server operator adds the A record to the DNS, = then any DNS recursive
    resolver on the Internet can receive that A re= cord in response to a

This does not appear to be a grammatically valid sentence.  = My guess is that
deleting "A resource... addresses" fixes this.

[JL] Change made.

And by the way, the document's reference to "recursive" reso= lvers is mostly
likely incorrect.  The problem is not restricted only to tha= t very specific type
of resolver, is it?

If in fact it /is/ specific to them -- and your following text describ= es an
indirect effects scenario where it might be -- I suggest calling out t= he
configuration at the beginning, along the lines of:

      One way the problem with returning= AAAA records can be experienced is when
recursive resolvers are used.  Although that resolver might = support IPv6, its
client hosts might not.  So, returning an AAAA record will m= ean that these
limited hosts will be given an unusable address.

And this type of description belongs in the text describing the motiva= ting
problem(s), rather than buried in the 'concerns' discussion.

(The text, here, pertains to A records, but the problem I've described= uses the
same configuration but for AAAA records with mixed v6 support.)


    query.  By extension, this means tha= t any of the hosts connected to
    any of these DNS recursive resolvers can recei= ve the IPv4 address
    resource records for a given FQDN.  = This enables new server hosts
    which are connected to the Internet, and for w= hich a fully qualified
    domain name (FQDN) such as www.example.com has= been added to the DNS
    with an IPv4 address record, to be almost imme= diately reachable by
    any host on the Internet.  In this c= ase, these new servers hosts
    become more and more widely accessible as new = networks and new end
    user hosts connect to the Internet over time, = capitalizing on and
    increasing so-called "network effects&quo= t; (also called network
    externalities).  It also means that = the new server hosts do not need
    to know about these new networks and new end u= ser hosts in order to
    make their content and applications available = to them, in essence
    that each end in this end-to-end model is resp= onsible for connecting
    to the Internet and once they have done so the= y can connect to each
    other without additional impediments or middle= networks or
    intervening networks or servers knowing about = these end points and
    whether one is allowed to contact the other.

Hmmm.  This rather lengthy bit of prose appears merely to be= explaining the
basic and long-standing DNS value proposition???

[JL] Ack =96 see previous comments about simplification. At the same t= ime I'm trying to keep the document understandable to wide audience (and on= e of your other notes suggested I need to be somewhat less technical or mor= e descriptive). You may be more familiar with the mechanics of DNS whereas someone else is less so. I'll think abou= t this one=85

    In contrast, the concern is that DNS whitelist= ing may fundamentally
    change this model.  In the altered D= NS whitelisting end-to-end model,
    one end (where the end user is located) cannot= readily connect to the
    other end (where the content is located), with= out parts of the middle
    (recursive resolvers) used by one end (the cli= ent, or end user hosts)
    being known to an intermediary (authoritative = nameservers) and
    approved for access to the resource at the end= .  As new networks
    connect to the Internet over time, those netwo= rks need to contact any
    and all domains which have implemented DNS whi= telisting in order to
    apply to be added to their DNS whitelist, in t= he hopes of making the
    content and applications residing on named ser= ver hosts in those
    domains accessible by the end user hosts on th= at new network.
    Furthermore, this same need to contact all dom= ains implementing DNS
    whitelisting also applies to all pre-existing = (but not whitelisted)
    networks connected to the Internet.

    In the current IPv4 Internet when a new server= host is added to the
    Internet it is generally widely available to a= ll end user hosts and
    networks, when DNS whitelisting of IPv6 resour= ce records is used,

If it is available to the hosts, it is available to the network.

networks, when -> networks. When

[JL] Fixed






Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 1= 0]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    these new server hosts are not accessible to a= ny end user hosts or
    networks until such time as the operator of th= e authoritative DNS

They are still accessible.  The IP-level mechanisms still wo= rk.

They are not reachable when using the domain name.

[JL] Fixed



    servers for those new server hosts expressly a= uthorizes access to
    those new server hosts by adding DNS recursive= resolvers around the
    Internet to the ACL.  This has the p= otential to be a significant

This is a good example of the reason the term ACL is inappropriate:&nb= sp; It implies
a security protection that does not actually exist.  The hos= ts are still accessible.

[JL] I still think the whitelist is comparable to an ACL insofar as it= controls access to AAAA RR responses on the authoritative server, regardle= ss of access by IP address to some destination host.

    change in reachability of content and applicat= ions by end users and
    networks as these end user hosts and networks = transition to IPv6,
    resulting in more (but different) breakage.&nb= sp; A concern expressed is
    that if much of the content that end users are= most interested in is
    not accessible as a result, then end users and= /or networks may resist
    adoption of IPv6 or actively seek alternatives= to it, such as using
    multi-layer network address translation (NAT) = techniques like NAT444
    [I-D.shirasaki-nat444] on a long-term basis.&n= bsp; There is also concern
    that this practice also could disrupt the cont= inued increase in
    Internet adoption by end users if they cannot = simply access new
    content and applications but must instead cont= act the operator of
    their DNS recursive resolver, such as their IS= P or another third
    party, to have their DNS recursive resolver au= thorized for access to
    the content or applications that interests the= m.  Meanwhile, these
    parties say, over 99.9% of the other end users= that are also using
    that same network or DNS recursive resolver ar= e unable to access the
    IPv6-based content, despite their experience b= eing a positive one.

    While in Section 1 the level of IPv6-related i= mpairment has been
    estimated to be as high as 0.078% of Internet = users, which is a

8 hundredths of one percent?

That's considered a high percentage?

[JL] It is. I joked at one of the v6ops WG meetings awhile ago that at= that rate, it'd be cheaper and easier for me (an ISP) to just buy new comp= uters for the affected "impaired" users than to have to navigate = years of whitelisting with a variety of domains. In any case, one recent measurement estimates it at 0.05% now and another = at 0.015%. Despite this, this practice is still generating some interest. I= 'm hoping World IPv6 Day goes well and is informative for the community as = to this percentage on a widespread basis, across a wide variety of web sites. 


Even if it is 8%, is that considered high?

[JL] 8% of the Internet finding google.com or facebook.com inaccessibl= e would be bad for everyone. That could generate several hundred thousand s= upport calls per day to a big ISP.

5.2.  Similarities to DNS Load Balancing

    DNS whitelisting also has some similarities to= DNS load balancing.
    There are of course many ways that DNS load ba= lancing can be
    performed.  In one example, multiple= IP address resource records (A
    and/or AAAA) can be added to the DNS for a giv= en FQDN.  This approach
    is referred to as DNS round robin [RFC1794].&n= bsp; DNS round robin may
    also be employed where SRV resource records ar= e used [RFC2782].

Right, but that's algorithmic rather than involving the manual method,= described
here. So it does not seem comparable.

[JL] Whether I agree with you or not, the WG asked to include it in an= earlier draft. I tried to simply say that there are "some" simil= arities as a qualifier. 

6.  Likely Deployment Scenarios

    In considering how DNS whitelisting may emerge= more widely, there are
    two likely deployment scenarios, which are exp= lored below.

    In either of these deployment scenarios, it is= possible that
    reputable third parties could create and maint= ain DNS whitelists, in
    much the same way that blacklists are used for= reducing email spam.
    In the email context, a mail operator subscrib= es to one or more of
    these lists and as such the operational proces= ses for additions and
    deletions to the list are managed by a third p= arty.  A similar model
    could emerge for DNS whitelisting, whether dep= loyment occurs
    universally or on an ad hoc basis.

The challenges of email whitelists and blacklists should be cited, sin= ce it
provides a rich base of experience for such an effort, at scale.


6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis

    The seemingly most likely deployment scenario = is where some

Most likely?  This is not already established practice?

[JL] It is established at some large domains like google.com (which co= mprise a large % of global Internet traffic). But other domains are now on = the cusp of their IPv6 transition and are pondering whether or not to use w= hitelisting. This document will hopefully be one of many data points in their decision-making.

    authoritative DNS server operators implement D= NS whitelisting but
    many or most others do not do so.  W= hat can make this scenario
    challenging from the standpoint of a DNS recur= sive resolver operator
    is determining which domains implement DNS whi= telisting, particularly
    since a domain may not do so as they initially= transition to IPv6,
    and may instead do so later.  Thus, = a DNS recursive resolver operator



Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 1= 3]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    may initially believe that they can receive AA= AA responses as a
    domain adopts IPv6, but then notice via end us= er reports that they no
    longer receive AAAA responses due to that doma= in adopting DNS
    whitelisting.  Of course, a domain's= IPv6 transition may be
    effectively invisible to recursive server oper= ators due to the effect
    of DNS whitelisting.

This suggests that every listing at the server needs a contact record = for
periodic checks whether to renew the listing.



    In contrast to a universal deployment of DNS w= hitelisting
    Section 6.2, deployment on an ad hoc basis is = likely to be
    significantly more challenging from an operati= onal, monitoring, and

Oh?  Use in small scale is more challenging than use of manu= al exceptions list
at large scale?  That's a very unexpected view.

[JL] I think it is in some regards but thinking it through more fully,= I think you are correct and I have removed this. 

    troubleshooting standpoint.  In this= scenario, a DNS recursive
    resolver operator will have no way to systemat= ically determine
    whether DNS whitelisting is or is not implemen= ted for a domain, since
    the absence of AAAA resource records may simpl= y be indicative that
    the domain has not yet added IPv6 addressing f= or the domain, rather
    than that they have done so but have restricte= d query access via DNS

The premise is that, in large scale use, servers /will/ have a way to =
systematically determine whether it is implemented?  What ar= e the existing
examples of having such a capability for other Internet protocols and = services?

[JL] Perhaps I'm overplaying this point, but you know someone has emai= l service if they have an MX record for example, or a website if the host a= nswers on TCP/80. But as I re-read this it is probably overkill and so I've= deleted it. I have however moved some of the text to a prior section, since determining whether or not doma= ins are whitelisting is still a challenge at scale. 

    whitelisting.  As a result, discover= ing which domains implement DNS
    whitelisting, in order to differentiate them f= rom those that do not,
    is likely to be challenging.

    One benefit of DNS whitelisting being deployed= on an ad hoc basis is
    that only the domains that are interested in d= oing so would have to
    upgrade their authoritative DNS servers in ord= er to implement the
    ACLs necessary to perform DNS whitelisting.

    In this potential deployment scenario, it is a= lso possible that a
    given domain will implement DNS whitelisting t= emporarily.  A domain,
    particularly a highly-trafficked domain, may c= hoose to do so in order
    to ease their transition to IPv6 through a sel= ective deployment and
    minimize any perceived risk in such a transiti= on.

6.2.  Deploying DNS Whitelisting Universally

    The least likely deployment scenario is one wh= ere DNS whitelisting is
    implemented on all authoritative DNS servers, = across the entire
    Internet.  While this scenario seems= less likely than ad hoc
    deployment due to some parties not sharing the= concerns that have so
    far motivated the use of DNS whitelisting, it = is nonetheless
    conceivable that it could be one of the ways i= n which DNS
    whitelisting is deployed.

Significantly, the partial-deployment model casts this mechanism as a = transition
expedient -- as the document reasonably describes it -- whereas univer= sal
deployment casts it as a fundamental change to the architecture.

Given that it would take decades to achieve relatively full deployment= of this
'across the entire Internet', what is the benefit of discussing this h= ighly
unlikely scenario?  Is it really "conceivable"?&nb= sp; I doubt it. If you think
otherwise, the paper needs to explore the deployment and adoption issu= es in much
more detail, because I don't see how it could work.

[JL] Per my previous email responses this has been extensively reworke= d. I feel I should probably leave the universal deployment scenario in ther= e for completeness, but it's been cut down and minimized. I'm open to recon= sidering the question later.

   In order for this deployment scenario to occur, it is lik= ely that DNS
    whitelisting functionality would need to be bu= ilt into all
    authoritative DNS server software, and that al= l operators of
    authoritative DNS servers would have to upgrad= e their software and
    enable this functionality.  It is li= kely that new Internet Draft
    documents would need to be developed which des= cribe how to properly
    configure, deploy, and maintain DNS whitelisti= ng.  As a result, it is

Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 1= 4]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011

    unlikely that DNS whitelisting would, at least= in the next several
    years, become universally deployed.  = ;Furthermore, these DNS
    whitelists are likely to vary on a domain-by-d= omain basis, depending
    upon a variety of factors.  Such fac= tors may include the motivation
    of each domain owner, the location of the DNS = recursive resolvers in
    relation to the source content, as well as var= ious other parameters
    that may be transitory in nature, or unique to= a specific end user
    host type.  It is probably unlikely = that a single clearinghouse for
    managing whitelisting is possible; it will mor= e likely be unique to
    the source content owners and/or domains which= implement DNS
    whitelists.

    While this scenario may be unlikely, it may ca= rry some benefits.
    First, parties performing troubleshooting woul= d not have to determine
    whether or not DNS whitelisting was being used= , as it always would be
    in use.  In addition, if universally= deployed, it is possible that
    the criteria for being added to or removed fro= m a DNS whitelist could
    be standardized across the entire Internet.&nb= sp; Nevertheless, even if
    uniform DNS whitelisting policies were not sta= ndardized, is also
    possible that a central registry of these poli= cies could be developed
    and deployed in order to make it easier to dis= cover them, a key part
    of achieving transparency regarding DNS whitel= isting.

Is any of this paragraph realistic?  Obviously my asking mea= ns I don't it is.
These seem to be of theoretical rather than pragmatic interest. &= nbsp;("If everyone
refuses to shoot, there will be no wars.")

It's true that this is an "implications" paper rather than a= BCP, but still...

[JL] Good point. Paragraph removed.


7.  Implications of DNS Whitelisting

    There are many potential implications of DNS w= hitelisting.  The key
    potential implications are detailed below.

7.1.  Architectural Implications

    DNS whitelisting could be perceived as modifyi= ng the end-to-end model
    and/or the general notion of the architecture = that prevails on the

I'll suggest that perception is not a major issue about a technical to= pic like
this.  (It's not entirely irrelevant, of course, but I suspe= ct it is quite minor.)

The major issue is whether it /actually/ modifies the end-to-end natur= e of the
DNS.  And I think it does, as well as modifying the "sp= ontaneous
interoperability" expectation for most Internet mechanism, since = it requires
prior registration.

[JL] Removed the perception stuff=85



7.2.  Public IPv6 Address Reachability Implications

    The predominant experience of end user hosts a= nd servers on the IPv4-
    addressed Internet today is that when a new se= rver with a public IPv4
    address is added to the DNS, that it is then g= lobally accessible by

This sentence is not quite correct, in strict technical terms. &n= bsp;Since this is a
technical discussion, we need to be precise:  the host is re= achable when the
routing tables make it reachable.  That's strictly a mapper = of IP Address
handling, not name-to-address mapping.

What you mean is that its domain name is immediately useful for reachi= ng it.

[JL] Correction made. 



    IPv4-addressed hosts.  This is a gen= eralization and in Section 5
    there are examples of common cases where this = may not necessarily be
    the case.  For the purposes of this = argument, that concept of
    accessibility can be considered "pervasiv= e reachability".  It has so
    far been assumed that the same expectations of= pervasive reachability
    would exist in the IPv6-addressed Internet.&nb= sp; However, if DNS
    whitelisting is deployed, this will not be the= case since only end
    user hosts using DNS recursive resolvers which= are included in the

again, you mean /name-based/ reachability.

[JL] Fixed. In a way I was grasping at the "spontaneous inte= roperability" notion you mentioned.


Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 1= 6]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    ACL of a given domain using DNS whitelisting w= ould be able to reach
    new servers in that given domain via IPv6 addr= esses.  The expectation
    of any end user host being able to connect to = any server (essentially
    both hosts, just at either end of the network)= , defined here as
    "pervasive reachability", will chang= e to "restricted reachability"
    with IPv6.

    Establishing DNS whitelisting as an accepted p= ractice in the early
    phases of mass IPv6 deployment could well esta= blish it as an integral
    part of how IPv6 DNS resource records are depl= oyed globally.  As a
    result, it is then possible that DNS whitelist= ing could live on for
    decades on the Internet as a key foundational = element of domain name
    management that we will all live with for a lo= ng time.

(that last sentence could benefit from some editing.)

[JL] Ack =96 fixed.

    It is a critical to understand that the concep= t of reachability
    described above depends upon a knowledge or aw= areness of an address
    in the DNS.  Thus, in order to estab= lish reachability to an end
    point, a host is dependent upon looking up an = IP address in the DNS

If this section were started with a sentence like this, then there wou= ld not be
a problem with the other references' being confused with address-based= routing
reachability.

[JL] Great point! I've actually moved the last paragraph to the start = of that section and it makes much more sense. 

    when a FQDN is used.  When DNS white= listing is used, it is quite
    likely the case that an IPv6-enabled end user = host could ping or
    connect to an example server host, even though= the FQDN associated
    with that server host is restricted via a DNS = whitelist.  Since most

First, I suspect that "example" doesn't add meaning to the s= entence.  Second,
pinging and connecting might happen with or without the whitelist entr= y.  So I
do not understand what import there is in this sentence.

[JL] I removed pinging but left connecting. What I'm saying you may st= ill be able to connect to the host via an IP if you cannot use the FQDN (it= won't always be the case, such as on a virtual web server sharing one IP a= cross several sites). I'll reword it a bit though since I see your point.

    Internet applications and hosts such as web se= rvers depend upon the
    DNS, and as end users connect to FQDNs such as= www.example.com and do
    not remember or wish to type in an IP address,= the notion of
    reachability described here should be understo= od to include knowledge
    how to associate a name with a network address= .

Again, this 'premise' statement should introduce the sub-section, not = end it.

[JL] Done (as noted above)


7.3.  Operational Implications

    This section explores some of the operational = implications which may
    occur as a result of, are related to, or becom= e necessary when
    engaging in the practice of DNS whitelisting.<= /div>

7.3.1.  De-Whitelisting May Occur

The more general version of this issue is 'synchronization'. &nbs= p;Entries in the
whitelist need to be synchronized with host status and capabilities.


    It is possible for a DNS recursive resolver ad= ded to a whitelist to
    then be removed from the whitelist, also known= as de-whitelisting.
    Since de-whitelisting can occur, through a dec= ision by the
    authoritative server operator, the domain owne= r, or even due to a
    technical error, an operator of a DNS recursiv= e resolver will have
    new operational and monitoring requirements an= d/or needs as noted in
    Section 7.3.3, Section 7.3.4, Section 7.3.6, a= nd Section 7.5.

7.3.2.  Authoritative DNS Server Operational Implications

    Operators of authoritative servers may need to= maintain an ACL a

a -> on a (?)

[JL] fixed



    server-wide basis affecting all domains, on a = domain-by-domain basis,


Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 1= 7]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    as well as on a combination of the two. &= nbsp;As a result, operational

I'm not really understanding the first sentence.  One proble= m might be that its
discussing an implication of some configuration or usage options that = have not
been previously specified, so that the reference here might be overly = cryptic.

For example, I don't know what "affecting all domains" actua= lly means.  It
almost sounds as if it could mean "everyone gets AAAA records&quo= t; or "no one gets
AAAA records" yet I'm reaonably certain that is /not/ what is mea= nt.

[JL] Yes, that sentence was unclear. It is now:
"Operators of authoritative servers (which are frequent= ly authoritative for multiple domain names) will need to maintain an ACL on= a server-wide basis affecting all domains, or on a domain-by-domain basis.= "

    practices and software capabilities may need to be = developed in order
    to support such functionality.  In a= ddition, processes may need to be
    put in place to protect against inadvertently = adding or removing IP
    addresses, as well as systems and/or processes= to respond to such
    incidents if and when they occur.  F= or example, a system may be
    needed to record DNS whitelisting requests, re= port on their status
    along a workflow, add IP addresses when whitel= isting has been
    approved, remove IP addresses when they have b= een de-whitelisted, log
    the personnel involved and timing of changes, = schedule changes to
    occur in the future, and to roll back any inad= vertent changes.

Might be worth starting with a simple, broad summary statement, possib= ly along
the lines of:

    An AAAA DNS Whitelist serves as a critical inf= rastructure service; to be
useful it needs careful and extensive administration, monitoring and o= peration.
  Each new and essential mechanism creates substantial follo= w-on support costs.

[JL] Thanks =96 added that text.



    Operators may also need implement new forms of= monitoring in order to
    apply change control, as noted briefly in Sect= ion 7.3.4.

7.3.3.  DNS Recursive Resolver Server Operational Implicatio= ns

    Operators of DNS recursive resolvers, which ma= y include ISPs,
    enterprises, universities, governments, indivi= dual end users, and
    many other parties, are likely to need to impl= ement new forms of
    monitoring, as noted briefly in Section 7.3.4.=   But more critically,
    such operators may need to add people, process= es, and systems in
    order to manage large numbers of DNS whitelist= ing applications as
    part of their own IPv6 transition, for all dom= ains that the end users
    of such servers are interested in now or in wh= ich they may be

I think the summary observation is simple and should be stated directl= y:  This
is a manual mechanism that becomes expensive in time and personnel eff= ort as it
scales up.

[JL] Added that



    interested in the future.  As antici= pation of interesting domains is
    likely infeasible, it is more likely that oper= ators may either choose
    to only apply to be whitelisted for a domain b= ased upon one or more
    end user requests, or that they will attempt t= o do so for all domains
    that they can ascertain to be engaging in DNS = whitelisting.

"attempt to do so for all domain that they can ascertain to be en= gaging in DNS
whitelisting"  appears to be saying to do whitelisting = for domains that do
whitelisting.  I don't understand.

[JL] I was going to great effort to badly make a point that you can't = anticipate all domains users will want to access and so will need a way for= users to request whitelisting instead. I've reworded as:
"But more critically, such operators will need to add people, = processes, and systems in order to manage large numbers of DNS Whitelisting= applications. Since there is no common method for determining whether or n= ot a domain is engaged in DNS Whitelisting, operators will have to apply to be whitelisted for a domain based upon one= or more end user requests, which means systems, processes, and personnel f= or handling and responding to those requests will also be necessary."<= /i>


    When operators apply for DNS whitelisting for = all domains, that may

"apply for DNS whitelisting for all domains" -- again I'm no= t understanding what
this means.

[JL] See above

7.3.5.  Implications of Operational Momentum

    It seems plausible that once DNS whitelisting = is implemented it will
    be very difficult to deprecate such technical = and operational
    practices.  This assumption is based= in an understanding of human

in -> on

[JL] Fixed

    nature, not to mention physics.  For= example, as Sir Issac Newton
    noted, "Every object in a state of unifor= m motion tends to remain in
    that state of motion unless an external force = is applied to it" [Laws

Code does not have momenum.  Neither do configurations or li= sts.  This really
isn't about physics.

[JL] But people and processes do have (operational) momentum=85

It is entirely about group psychology, as you note, and the administra= tive
challenges in the logistics of large-scale operational changes (which = probably
/does/ have something to with physics, but it seems a stretch to credi= t Newton.
How about Heisenberg?...)

[JL] Hmmm=85 I don't think it is Heisenberg-related. But it's such an = interesting citation I feel it's almost a personal challenge to figure out = a way to keep it in there. ;-) The way I think about it is that in 5 or 10 = years none of the people working on the details of the IPv6 transition now will still be involved in the day-t= o-day operational work. But DNS Whitelisting could still be in place =96 an= d once something gets a momentum to it (people, processes, and organization= s) it is really, really hard to change that. This seems very much like the physics principle to which I refer but= I'm open to other citations. I envision this possibility:
Q (from new trainee): Why are we doing this DNS Whitelisting thing?
A: Because that's what we have to do for IPv6 access to every new doma= in.
Q: Why? 
A: Because we've been doing it for years and it says to do it here in = this operations manual we have to follow.
Q: Then I guess we should keep doing it? 
A: Yes, we should. It'd be hard to change the standard process, and we= 'd have to escalate it to someone, etc.  

    of Motion].  Thus, once DNS whitelis= ting is implemented it is quite
    likely that it would take considerable effort = to deprecate the
    practice and remove it everywhere on the Inter= net - it will otherwise
    simply remain in place in perpetuity. &nb= sp;To better illustrate this
    point, one could consider one example (of many= ) that there are many
    email servers continuing to attempt to query o= r otherwise check anti-



Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 1= 9]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    spam DNS blocklists which have long ago ceased= to exist.

7.3.6.  Troubleshooting Implications

    The implications of DNS whitelisted present ma= ny challenges, which
    have been detailed in Section 7.  Th= ese challenges may negatively

But this is /still/ section 7.  Can you be more specific?&nb= sp; Or perhaps say
"throughout this section".

[JL] fixed



    affect the end users' ability to troubleshoot,= as well as that of DNS
    recursive resolver operators, ISPs, content pr= oviders, domain owners
    (where they may be different from the operator= of the authoritative
    DNS server for their domain), and other third = parties.  This may make
    the process of determining why a server is not= reachable
    significantly more complex.

7.3.7.  Additional Implications If Deployed On An Ad Hoc Bas= is

    Additional implications, should this be deploy= ed on an ad hoc basis,
    could include scalability problems relating to= operational processes,

I'm pretty sure that scaling problems for this exist in all scenarios,= not just
ad hoc usage.

[JL] True. Simplified to:
"As more domains choose to implement DNS Whitelisting, and mor= e networks become IPv6-capable and request to be whitelisted, scaling up op= erational processes, monitoring, and ACL updates will become more difficult= . The increased rate of change and increased size of whitelists will increase the likelihood of configuration and other= operational errors."

    monitoring, and ACL updates.  In par= ticular, it seems likely that as
    the number of domains that are using DNS white= listing increases, as
    well as the number of IPv6-capable networks re= questing to be
    whitelisted, that there is an increased likeli= hood of configuration
    and other operational errors, especially with = respect to the ACLs
    themselves.

    It is unclear when and if it would be appropri= ate to change from
    whitelisting to blacklisting, and whether or h= ow this could feasibly
    be coordinated across the Internet, which may = be proposed or

Actually the question of coordination is quite clear and rather fundam= ental:

      No.

Anyone believing otherwise needs to cite a successful example, at Inte= rnet scale
and diversity, more recently than the 1983 switch to IP (which didn't = go all
that well anyhow...)

Simple, unambiguous showstoppers should be stated in a simple and dire= ct manner.
  When there is room for debate, softer language makes sense= .  Again, if the
question of coordination really is subject to debate, then the basis n= eeds to be
stated.  (Good luck!)

[JL] That's not encouraging=85 Changed to: 
"It is unclear when and if it would be appropriate to change f= rom whitelisting to blacklisting. It is clear that trying to coordinate thi= s across the Internet is likely be be impossible, so such a change to black= listing would happen on a domain-by-domain basis (if at all)."

    implemented on an ad hoc basis when a majority= of networks (or
    allocated IPv6 address blocks) have been white= listed.  Finally, some
    parties implementing DNS whitelisting consider= this to be a temporary
    measure.  As such, it is not clear h= ow these parties will judge the
    network conditions to have changed sufficientl= y to justify disabling
    DNS whitelisting and/or what the process and t= iming will be in order
    to discontinue this practice.

    One further potential implication is that an e= nd user with only an
    IPv4 address, using a DNS resolver which has n= ot been whitelisted by
    any domains, would not be able to get any AAAA= resource records.  In
    such a case, this could give that end user the= incorrect impression
    that there is no IPv6-based content on the Int= ernet since they are
    unable to discover any IPv6 addresses via the = DNS.

7.4.  Homogeneity May Be Encouraged

    A broad trend which has existed on the Interne= t appears to be a move
    towards increasing levels of heterogeneity.&nb= sp; One manifestation of

increasing levels of heterogeneity -> more heterogeneity

[JL] fixed


(I think heterogeneity does not have 'levels'.)

Substantively:  say the nature of the heterogeneity within t= he initial claim.
For example, there is /less/ heterogeneity of ISPs, given industry
consolidation.  There is less heterogeneity of infrastructur= e equipment such as
routers.  Etc.

[JL] I have gotten lots and lots of questions related to this section,= which led me to conclude that I've done a poor job stating the issue. I wa= s dancing around it but here it is more directly in an updated section (the= new 2nd  and final paragraph of this section):
"Some forms of so-called "network neutrality" princi= ples around the world include the notion that any IP-capable device should = be able to connect to a network, which seems to encourage heterogeneity. Th= ese principles are often explicitly encouraged by application providers given the reasons noted above,= though some of these same providers may also be implementing DNS Whitelist= ing. This is ironic, as one implication of the adoption of DNS Whitelisting= is that it encourages a move back towards homogeneity. This is because some implementers have expressed a preference= for greater levels of control by networks over end user hosts in order to = attempt to enforce technical requirements intended to reduce IPv6-related i= mpairments. This return to an environment of more homogenous and/or controlled end user hosts could have unintended = side effects on and counter-productive implications for future innovation a= t the edges of the network."

    this is in an increasing number, variety, and = customization of end
    user hosts, including home network, operating = systems, client



Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 2= 0]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


    software, home network devices, and personal c= omputing devices.  This
    trend appears to have had a positive effect on= the development and
    growth of the Internet.  A key facet= of this that has evolved is the
    ability of the end user to connect any technic= ally compliant device
    or use any technically compatible software to = connect to the
    Internet.  Not only does this trend = towards greater heterogeneity
    reduce the control which is exerted in the mid= dle of the network,
    described in positive terms in [Tussle in Cybe= rspace], [Rethinking
    the Internet], and [RFC3724], but it can also = help to enable greater
    and more rapid innovation at the edges.

    An unfortunate implication of the adoption of = DNS whitelisting may be
    the encouragement of a reversal of this trend,= which would be a move

the encouragement of -> to encourage

[JL] totally changed this, as noted above.



8.1.  Implement DNS Whitelisting Universally

    One obvious solution is to implement DNS white= listed universally, and
    to do so using some sort of centralized regist= ry of DNS whitelisting
    policies, contracts, processes, or other infor= mation.  This potential
    solution seems unlikely at the current time.

I'm pretty sure that the only thing that is obvious about a premise of= universal
adoption is that it's not practical.  Seriously.

At the least, this section needs to be less cavalier about putting thi= s
alternative forward as a "solution", especially given the ra= ther serious
drawbacks/problems with it.

[JL] Fixed




8.2.  Implement DNS Whitelisting On An Ad Hoc Basis

    If DNS whitelisting is to be adopted, it is li= kely to be adopted on

"is to be"?  I thought it already had a significan= t installed base.

[JL] Fixed. 

    this ad hoc, or domain-by-domain basis. &= nbsp;Therefore, only those
    domains interested in DNS whitelisting would n= eed to adopt the
    practice, though as noted herein discovering t= hat they a given domain
    has done so may be problematic.  Als= o in this scenario, ad hoc use by
    a particular domain may be a temporary measure= that has been adopted
    to ease the transition of the domain to IPv6 o= ver some short-term
    timeframe.

8.3.  Do Not Implement DNS Whitelisting

    As an alternative to adopting DNS whitelisting= , the Internet
    community generally can choose to take no acti= on whatsoever,
    perpetuating the current predominant authorita= tive DNS operational
    model on the Internet, and leave it up to end = users with IPv6-related
    impairments to discover and fix those impairme= nts.


That is, place the burden of fixing a problem on those creating it?

[JL] In a way. It gets back to the question you asked about what level= of impairment justifies this practice. One obvious option is to let end us= ers sort it out (presumably by consulting with their ISPs / network operato= rs). This may be simpler and it's the way solutions to non-IPv6 problems tend to work today.





Livingood          &= nbsp;     Expires August 26, 2011   = ;            [Page 2= 3]
Internet-Draft   IPv6 AAAA DNS Whitelisting Implications&nbs= p;  February 2011


8.3.1.  Solving Current End User IPv6 Impairments

    A further extension of not implementing DNS wh= itelisting, is to also
    endeavor to actually fix the underlying techni= cal problems that have
    prompted the consideration of DNS whitelisting= in the first place, as
    an alternative to trying to apply temporary wo= rkarounds to avoid the
    symptoms of underlying end user IPv6 impairmen= ts.  A first step is
    obviously to identify which users have such im= pairments, which would
    appear to be possible, and then to communicate= this information to
    end users.  Such end user communicat= ion is likely to be most helpful
    if the end user is not only alerted to a poten= tial problem but is
    given careful and detailed advice on how to re= solve this on their
    own, or where they can seek help in doing so.&= nbsp; Section 11 may also be
    relevant in this case.

    One challenge with this option is the potentia= l difficulty of
    motivating members of the Internet community t= o work collectively
    towards this goal, sharing the labor, time, an= d costs related to such
    an effort.  Of course, since just su= ch a community effort is now
    underway for IPv6, it is possible that this wo= uld call for only a
    moderate amount of additional work.

This 'challenge' is at the core of /all/ adoption efforts for Internet= protocols
and services that entail distributed adoption.


    Despite any potential challenges, many in the = Internet community are
    already working towards this goal and/or have = expressed a general
    preference for this approach.

If this is not already an organized effort with a website, sponsoring =
consortium, or the like, it should be.  If it is, then cite = it in this doc!

[JL] Fixed. It is World IPv6 Day and the many efforts related to that.=  



8.3.2.  Gain Experience Using IPv6 Transition Names

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

I do not understand what this means.

What is it for?  What are the results?  How are th= eyused?

[JL] Ack. This has been clarified in the =9604.



9.  Is DNS Whitelisting a Recommended Practice?

    Opinions in the Internet community concerning = whether or not DNS
    whitelisting is a recommended practice are und= erstandably quite
    varied.  However, there is clear con= sensus that DNS whitelisting is
    at best a useful temporary measure which a dom= ain may choose to

If that is a clear consensus, then it makes even less sense to promote= the idea
of universal adoption, given the timescale needed to achieve it.


10.  Security Considerations

    There are no particular security consideration= s if DNS whitelisting
    is not adopted, as this is how the public Inte= rnet works today with A
    resource records.

Or rather, failure to adopt a mechanism like this or repair the underl= ying
problem, for those sites experiencing that problem, will result in a d= enial of
service, albeit not an intentional one.  Still, that's a pre= tty basic security
issue.


d/
--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

--_000_CA084387289FFjasonlivingoodcablecomcastcom_-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABC0E06D9; Sun, 22 May 2011 16:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LixLbTdxctJC; Sun, 22 May 2011 16:50:03 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA02E06A6; Sun, 22 May 2011 16:50:01 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKTdmhKX7Z5E79uLdCd/wu83IxsxJjQaqK@postini.com; Sun, 22 May 2011 16:50:02 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p4MNMLFu012813; Sun, 22 May 2011 16:22:21 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p4MNMGqK008238; Sun, 22 May 2011 16:22:16 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 22 May 2011 16:22:15 -0700 From: Larry Masinter To: "eburger@standardstrack.com" , "draft-ietf-speechsc-mrcpv2@tools.ietf.org" , "dburnett@voxeo.com" , "sarvi@cisco.com" , "rjsparks@nostrum.com" , "speechsc@ietf.org" , "apps-review@ietf.org" , "apps-discuss@ietf.org" , "iesg@ietf.org" Date: Sun, 22 May 2011 16:22:13 -0700 Thread-Topic: apps-team review of draft-ietf-speechsc-mrcpv2-24 Thread-Index: Acv+H96fCgdiI14BSGyp2vy2TwDXaQatfj3Q Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-review] apps-team review of draft-ietf-speechsc-mrcpv2-24 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 23:50:05 -0000 (Sorry for delay in sending this) I was selected as the Applications Area Review Team reviewer for this draft= (for background on apps-review, please see http://www.apps.ietf.org/conten= t/applications-area-review-team). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: apps-team review of draft-ietf-speechsc-mrcpv2-24 Title: Media Resource Control Protocol Version 2 (MRCPv2) Reviewer: Larry Masinter Review Date: 4/25/2011 IETF Last Call Date: (unknown) IESG Telechat Date: (unknown) Summary: I'm very reluctant to recommend this document for publication as = an RFC as standards track or even informational. The document is in need o= f significant editorial work to make it technically reviewable. The most se= rious technical problems I noted are in what seem like untestable normative= requirements (MUST). I have a lot of sympathy for the editors of this document. It has been unde= r development for many years (it is version -24 and version -00 was publish= ed in 2004, 7 years ago), and I know that many of the difficulties of the d= ocument come from trying to address hard fought contentious issues. The do= cument is over 221 pages long.... nearly impossible for anyone to get their= head around. And given how difficult it must have been to come to agreeme= nt on many issues, I'm sure there is a great reluctance to engage in a heav= y massive editing job. I also understand that the protocol described here is widely implemented wi= th several interoperable implementations deployed. As a measure of protocol= quality, then, implementations should attest to the value of the document. I confess to have only spent 6-8 hours trying to review the document before= giving up, and I really only tried to carefully review the first 20 pages;= perhaps the remaining 191 pages are of far superior quality to the first 2= 0 or so I was able to review in detail. However, a scan of the reest isn't = encouraging. EDITORIAL The context and operation of this protocol in the space of other protocols = is really unclear. The relationship between MRCPv2, MRCP, SPEECHSC, RFC4313= , VoiceXML, RTSP, SIP, SDP, SSML, and other protocols and formats cannot b= e teased out from the introductory material. The relationship to HTTP vs. = SIP is really unclear. The simple requirement that terms be defined on first use, and be given ref= erences as either normative or informative ... is not met. Many of the refe= renced items are mysterious or are not defined. "SIP URI", "re-INVITE", "ch= annel identifier". Many technical terms are mis-named, e.g., "HTTP" and "HTTPS" are not URI sc= hemes. While essential information is missing, there seem to be many instances of = redundant information, explained slightly differently, and perhaps inconsis= tently. While the RFC editor might normally be expected to fix up some of the refer= ences, I think doing so here would be nearly impossible without significant= work from the editors. NORMATIVE REQUIREMENTS The document seems to be full of MUST and MAY requirements which do not mak= e sense, are missing essential context, or are provided with preconditions = which cannot be readily computed or known. The client MAY then open a new TCP connection with the server on this port number. which client, which server, under what circumstances? A recorder MUST provide some endpointing capabilities for suppressing silence at the beginning and end of a recording, What are "some" endpointing capabilities? Which roles of participants in th= is protocol are not in conformance with the specification if the recorder's= endpointing capabilities are poor? Is this really a normative requirement? and MAY also suppress silence in the middle of a recording. If such suppression is done, the recorder MUST maintain timing metadata to indicate the actual time stamps of the recorded media. How does the maintenance of timing metadata manifest itself in any visible = effect in the protocol? Examples are called "architectural diagrams". (DTMF Recorder) could also do a semantic interpretation based on semantic tags in the grammar. Is this a normative requirement? Just a description? > MRCPv2 employs a session establishment and management protocol such > as SIP in conjunction with SDP. Is this a "such as" or in fact that SIP and SDP are mandatory and other pro= tocols are allowed? > The client needs a separate MRCPv2 resource control channel to > control each media processing resource under the SIP dialog. The concept of 'channel' isn't clear, where is it defined? What does it entail? .... All servers MUST support TLS. Servers MAY support TCP without TLS in physically secure environments. Is it really "physically" secure that is the requirement? How does the server know that it is in a "secure" environment? Are there other situations where TCP without TLS MAY be supported? ... SUMMARY I've really been unable to do an extensive review of the actual protocol, b= ecause of what I think is a problem with the document quality. I'm confide= nt that a careful overview plus removal of redundant or misleading material= would make the document shorter and clearer, and that a very careful revie= w of the language describing normative requirements would improve implement= ability and interoperability. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D (original review, more details than above but more tentative) This protocol references RFC 2616. But the convention of references [HX.Y] to reference sections of RFC 2616 seems problematic. I will try to review where RFC2616's definitions have been changed or obsoleted. The RFC editor will probably fix up the references style and minor editorial details, but they're annoying. 2.2: I think you mean that the "State-Machine Diagrams" are not normative but are there for illustrative purposes only? Otherwise why are they incomplete? 2.3. URI Schemes: "HTTP" and "HTTPS" are protocols, not URI schemes. You mean the "http" and "https" scheme name. I don't understand the MAY supporting other schemes... either they are allowed or not. What are the "provided they have addressed any security considerations" doesn't seem like a reasonable requiest for conformance. 3. Architecture Maybe this belongs earlier? Or in the introduction? With references to SIP and SDP? Do these requirements appear in any other document? SIP URIs needs reference. The server, through the SDP exchange, provides the client with an unambiguous channel identifier and a TCP port number. What is a "channel identifier"? The client MAY then open a new TCP connection with the server on this port number. This doesn't make too much sense, it's missing some context. When MAY the client open a new connection? Multiple MRCPv2 channels can share a TCP connection between the client and the server. How does this work... aren't they asynchronous? All MRCPv2 messages exchanged between the client and the server carry the specified channel identifier that the server MUST ensure is unambiguous among all MRCPv2 control channels that are active on that server. The client uses this channel identifier to indicate the media processing resource associated with that channel. For information on message framing, see Section 5. Still not clear what a channel identifier is. The session initiation protocol (SIP) also establishes the media sessions between the client (or other source/sink of media) and the MRCPv2 server using SDP m-lines. One or more media processing resources may share a media session under a SIP session, or each media processing resource may have its own media session. The following diagram shows the general architecture of a system that uses MRCPv2. To simplify the diagram only a few resources are shown. How is this a symplification? Is this a "general architecture" or is it an example diagram? Figure 1: Where did RTP come in? Why is the TCP/IP stack even shown? 3.1. MRCPv2 Media Resource Types Are these examples? Exhaustive? Normative requirements? Are these resource types actually named? "Basic Synthesizer". This is the first mention of "SSML". Is "full SSML support" actually defined? (Haven't cross-checked the W3C reference.) Recorder A resource capable of recording audio and providing a URI pointer to the recording. Any other requirements, like access control? A recorder MUST provide some endpointing capabilities for suppressing silence at the beginning and end of a recording, Doesn't make sense for a "MUST" requirement to be described as "some". and MAY also suppress silence in the middle of a recording. If such suppression is done, the recorder MUST maintain timing metadata to indicate the actual time stamps of the recorded media. Unclear why this is a normative requirement at all. DTMF Recognizer A recognition resource capable of extracting and interpreting DTMF digits in a media stream and matching them against a supplied digit grammar It could also do a semantic interpretation based on semantic tags in the grammar. Unclear what "could" means here. Allowed? How would it do this? Speech Recognizer A full speech recognition resource that is capable of receiving a media stream containing audio and interpreting it to recognition results. It also has a natural language semantic interpreter to post-process the recognized data according to the semantic data in the grammar and provide semantic results along with the recognized input. The recognizer may also support enrolled grammars, where the client can enroll and create new personal grammars for use in future recognition operations. Is this a normative requirement, a description of a typical Speech Recognizer, or just an example? Speaker Verifier A resource capable of verifying the authenticity of a claimed identity by matching a media stream containing spoken input to a pre-existing voiceprint. This may also involve matching the caller's voice against more than one voiceprint, also called multi-verification or speaker identification. Does it matter how this works? Whether it does matching against voiceprints or something else? The MRCPv2 server is a generic SIP server, and is thus addressed by a SIP URI. I think you mean "A" and not "The" MRCPv2 server. What does it mean "addressed by"? In what context? 4. MRCPv2 Protocol Basics MRCPv2 requires a connection-oriented transport layer protocol such as TCP or SCTP to guarantee reliable sequencing and delivery of MRCPv2 control messages between the client and the server. In order to meet the requirements for security enumerated in SpeechSC Requirements [RFC4313], clients and servers MUST implement TLS as well. RFC 4313 now has a different name again. Normative requirements should have references. Need reference for "TLS"? One or more connections between the client and the server can be shared among different MRCPv2 channels to the server. The individual messages carry the channel identifier to differentiate messages on different channels. MRCPv2 protocol encoding is text based with mechanisms to carry embedded binary data. This allows arbitrary data like recognition grammars, recognition results, synthesizer speech markup etc. to be carried in MRCPv2 messages. For information on message framing, see Section 5. Doesn't feel like 'protocol basics' to me. 4.1. Connecting to the Server MRCPv2 employs a session establishment and management protocol such as SIP in conjunction with SDP. Is this really "such as"? Maybe you want to allow for some extensibility with other possibilities, but really, is that necessary? Especially since you make reference to SIP-specific operations and not arbitrary "session establishment" protocols? I don't understand the overall flow which makes reference to 4.1. 4.2. Managing Resource Control Channels A unique channel identifier string identifies these resource control channels. The channel identifier is an unambiguous, opaque string followed by an "@", then by a string token specifying the type of resource. So I guess the resource types listed before are exhaustive? The server generates the channel identifier and MUST make sure it does not clash with the identifier of any other MRCP channel currently allocated by that server. Are they globally unique or just relative to a server? Is it clear what a "server" is? MRCPv2 defines the following IANA-registered types of media processing resources. Additional resource types, their associated methods/events and state machines may be added as described below in Section 13. +---------------+----------------------+--------------+ | Resource Type | Resource Description | Described in | +---------------+----------------------+--------------+ | speechrecog | Speech Recognizer | Section 9 | | dtmfrecog | DTMF Recognizer | Section 9 | | speechsynth | Speech Synthesizer | Section 8 | | basicsynth | Basic Synthesizer | Section 8 | | speakverify | Speaker Verification | Section 11 | | recorder | Speech Recorder | Section 10 | +---------------+----------------------+--------------+ Looks like these *are* exhaustive, describes in a previous section, and then updated. Resource Types The SIP INVITE or re-INVITE transaction and the SDP offer/answer exchange it carries contain m-lines describing the resource control channel to be allocated. What's a "m-line"? There MUST be one SDP m-line for each MRCPv2 resource to be used in the session. Where must there be an SDP m-line? In what ocntext? This m-line MUST have a media type field of "application" and a transport type field of either "TCP/MRCPv2" or "TCP/TLS/MRCPv2". Where is the "media type field" ? The "transport type field"? (The usage of SCTP with MRCPv2 may be addressed in a future specification). Future specification of what? What does SCTP have to do with anything? The port number field of the m-line MUST contain the "discard" port of the transport protocol (port 9 for TCP) in the SDP offer from the client and MUST contain the TCP listen port on the server in the SDP answer. This confuses me a lot? Why should the port be 9? For what? The client may then either set up a TCP or TLS connection to that server port or share an already established connection to that port. When MAY the client do this? Are these the only two options? When is this behavior mandated? Since MRCPv2 allows multiple sessions to share the same TCP connection, multiple m-lines in a single SDP document may share the same port field value; "document"? Where do documents come from? MRCPv2 servers MUST NOT assume any relationship between resources using the same port other than the sharing of the communication channel. What does it mean to "assume"? How could it assume something that this "MUST NOT" do? How would you know, even? MRCPv2 resources do not use the port or format field of the m-line to distinguish themselves from other resources using the same channel. This discussion of m-lines is just confusing, then. The client MUST specify the resource type identifier in the resource attribute associated with the control m-line of the SDP offer. The server MUST respond with the full Channel-Identifier (which includes the resource type identifier and an unambiguous string) in the "channel" attribute associated with the control m-line of the SDP answer. To remain backwards compatible with conventional SDP usage, the format field of the m-line MUST have the arbitrarily-selected value of "1". Is the resource type identifier the same in the offer & response, then? Why is it important to "remain backward compatible with conventional SDP usage"? If the value is "1", how is it "arbitrarily-selected"? When the client wants to add a media processing resource to the session, it issues a SIP re-INVITE transaction. Is this clear? Is re-INVITE a SIP operation? Or does this just mean repeating the SIP INVITE. The SDP offer/answer Looks like this uses SIP or SDP in a stylized way. The a=3Dsetup attribute, as described in RFC4145 [RFC4145], MUST be "active" for the offer from the client and MUST be "passive" for the answer from the MRCPv2 server. The a=3Dconnection attribute MUST have a value of "new" on the very first control m-line offer from the client to an MRCPv2 server. Subsequent control m-line offers from the client to the MRCP server MAY contain "new" or "existing", depending on whether the client wants to set up a new connection or share an existing connection, respectively. If the client specifies a value of "new", the server MUST respond with a value of "new". If the client specifies a value of "existing", the server MAY respond with a value of "existing" if it prefers to share an existing connection or can answer with a value of "new", in which case the client MUST initiate a new transport connection. When the client wants to de-allocate the resource from this session, it issues a SIP re-INVITE transaction with the server. The SDP MUST offer the control m-line with port 0. The server MUST then answer the control m-line with a response of port 0. This de-allocates the associated MRCPv2 identifier and resource. The server MUST NOT close the TCP, SCTP or TLS connection if it is currently being shared among multiple MRCP channels. When all MRCP channels that may be sharing the connection are released and/or the associated SIP dialog is terminated, the client or server terminates the connection. All servers MUST support TLS. Servers MAY support TCP without TLS in physically secure environments. Is it really "physically" secure that is the requirement? How does the server know that it is in a "secure" environment? Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A589E0656; Thu, 19 May 2011 06:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TScwLhNi+L2P; Thu, 19 May 2011 06:31:31 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2A872E066A; Thu, 19 May 2011 06:31:29 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D4A0520D2C; Thu, 19 May 2011 09:31:27 -0400 (EDT) Message-ID: <4DD51BAF.7070505@viagenie.ca> Date: Thu, 19 May 2011 09:31:27 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 May 2011 09:42:26 -0700 Cc: apps-review@ietf.org, secdir@ietf.org, iesg@ietf.org, vcarddav@ietf.org, draft-ietf-vcarddav-vcardrev.all@tools.ietf.org Subject: Re: [apps-review] secdir/apps-area/last-call review of draft-ietf-vcarddav-vcardrev-19 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 13:31:32 -0000 On 2011-04-18 12:59, Barry Leiba wrote: > ------------------------------ > 3.1. Character Set > > The character set for vCard is UTF-8 as defined in [RFC3629]. There > is no way to override this. It is invalid to specify a different > character set in the "charset" MIME parameter (see Section 10.1). > > This isn't consistent with section 10.1. UTF-8 is an encoding, not a > character set. Section 10.1 says this, in reference to parameters on > the media type: > > "charset": as defined for text/plain [RFC2046]; encodings other > than UTF-8 [RFC3629] MUST NOT be used. > > That is the correct characterization. The problem is that this is > used inconsistently in general, and there's been an extended > controversy in EAI about this very thing. RFC 3536 specifies > internationalization terminology, and that's currently being updated > by draft-hoffman-rfc3536bis. From that document: > > charset > > A charset is a method of mapping a sequence of octets to a > sequence of abstract characters. A charset is, in effect, a > combination of one or more CCSs with a CES. Charset names are > registered by the IANA according to procedures documented in > [RFC2978]. > > Many protocol definitions use the term "character set" in their > descriptions. The terms "charset" or "character encoding scheme" > and "coded character set" are strongly preferred over the term > "character set" because "character set" has other definitions in > other contexts and this can be confusing. > > I suggest re-wording 3.1 thus (and an informative reference to RFC > 3536 would be reasonable): > > NEW > 3.1. Charset > > The charset [see RFC3536 for internationalization terminology] for vCard > is UTF-8 as defined in [RFC3629]. There is no way to override this. It is > invalid to specify a value other than "UTF-8" in the "charset" MIME > parameter (see Section 10.1). Yes, more precise wording is better. Applied verbatim. > ------------------------------ > > 3.3. ABNF Format Definition > > OLD > ; When parsing a content line, folded lines must first > ; be unfolded according to the unfolding procedure > ; described above. > ; When generating a content line, lines longer than 75 > ; characters SHOULD be folded according to the folding > ; procedure described above. > > NEW > ; When parsing a content line, folded lines must first > ; be unfolded according to the unfolding procedure > ; described in section 3.2. > ; When generating a content line, lines longer than 75 > ; characters SHOULD be folded according to the folding > ; procedure described in section 3.2. > > OLD > A line that begins with a white space character is a continuation of > the previous line, as described above. > > NEW > A line that begins with a white space character is a continuation of > the previous line, as described in section 3.2. Applied. > ------------------------------ > > Section 3.3 says this: > Parameter values > MAY be case sensitive or case insensitive, depending on their > definition. Based on experience with vCard 3 interoperability, it is > RECOMMENDED that property and parameter names be upper-case on > output. > > Some of the parameter definitions ("value" (5.2) and "type" (5.6), for > example) use text strings for their values, and give no guidance on > case. I suggest changing the paragraph in section 3.3: > > NEW > Parameter values > MAY be case-sensitive or case-insensitive, depending on their > definitions. Parameter values that are not explicitly defined > as being case-sensitive are case-insensitive. Based on > experience with vCard 3 interoperability, it is RECOMMENDED > that property names and parameter names be upper-case on output. Added. > ------------------------------ > > 3.4. Property Value Escaping > > OLD > Finally, BACKSLASH characters in values MUST be escaped with a > BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values > MUST be encoded by two characters: a BACKSLASH followed by an 'n' > (ASCII decimal 110). > > This is inconsistent with section 4.1. > > NEW > Finally, BACKSLASH characters in values MUST be escaped with a > BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values > MUST be encoded by two characters: a BACKSLASH followed by either an > 'n' (ASCII decimal 110) or an 'N' (ASCII decimal 78). Fixed. > ------------------------------ > > 4.5. INTEGER > > I note that the ABNF allows "-0" (and, in fact, "-00000000") as a > valid integer. If that's intended, that's fine; I just wanted to > point it out. Yeah it looks like it's allowed in XML Schema (not exactly sure though), and I know it's parsed correctly by just about any programming language standard library, so I'd prefer to leave it the way it is. > ------------------------------ > > 5.9. SORT-AS > > Is this parameter value intended to be case-sensitive? I think so, > and that should be specified. Let's fix the "less/fewer" error, while > we're here. > > OLD > This parameter's value is a comma-separated list which MUST have as > many or less elements as the corresponding property value has > components. > > NEW > This parameter's value is a comma-separated list which MUST have as > many or fewer elements as the corresponding property value has > components. This parameter's value is case-sensitive. Fixed. > ------------------------------ > > 6.3.1. ADR > > Special notes: The structured type value consists of a sequence of > address components. The component values MUST be specified in > their corresponding position. The structured type value > corresponds, in sequence, to the post office box; the extended > address (e.g. apartment or suite number); the street address; the > locality (e.g., city); the region (e.g., state or province); the > postal code; the country name (full name in the language specified > in Section 5.1). When a component value is missing, the > associated component separator MUST still be specified. > > SUGGESTION: > I think this would be easier to read and get right as a compact list, > rather than as a paragraph of text. Maybe like this: > > NEW > Special notes: The structured type value consists of a sequence of > address components. The component values MUST be specified in > their corresponding position. The structured type value > corresponds, in sequence, to > the post office box; > the extended address (e.g. apartment or suite number); > the street address; > the locality (e.g., city); > the region (e.g., state or province); > the postal code; > the country name (full name in the language specified in > Section 5.1). > When a component value is missing, the associated component > separator MUST still be specified. Agreed, but I don't know how to create such formatting with xml2rfc. So I just created a regular, non-compact list: Special notes: The structured type value consists of a sequence of address components. The component values MUST be specified in their corresponding position. The structured type value corresponds, in sequence, to * the post office box; * the extended address (e.g. apartment or suite number); * the street address; * the locality (e.g., city); * the region (e.g., state or province); * the postal code; * the country name (full name in the language specified in Section 5.1). When a component value is missing, the associated component separator MUST still be specified. > ------------------------------ > > 8. Example: Authors' vCards > > There's nothing wrong with leaving Pete Resnick's vCard in there as an > example, but I'll point out that he hasn't been a document editor > since -16 was posted. I'll also point out that these are not > "authors", but "editors". Just sayin'.... HA! I'll remove it. It contained an example of the URL property that was not in my vCard, so I just added a URL property to my vCard. > ------------------------------ > > 9. Security Considerations > > I believe the specified security considerations are adequate, and I > have no issues with them. :) > ------------------------------ > > 10.1. MIME Type Registration > > Person & email address to contact for further information: Simon > Perreault > > Section 10.2.1 specifies the creation of a mailing list, > . Perhaps that should be the contact email address > for the MIME type registration as well. Agreed. I put "vCard discussion mailing list ". > ------------------------------ > > 10.2.1. Registration Procedure > > Nit: change "Standard Tracks RFC" to "Standards Track RFC", throughout. Fixed. > ------------------------------ > > That's all.... Thanks a lot! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF84BE066C for ; Mon, 16 May 2011 02:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GZ5NYuFXIta for ; Mon, 16 May 2011 02:22:05 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 16397E0658 for ; Mon, 16 May 2011 02:22:04 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id p4G9LnO2021795; Mon, 16 May 2011 10:21:49 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p4G9LntG025768; Mon, 16 May 2011 10:21:49 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p4G9LmfB007604; Mon, 16 May 2011 10:21:48 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id p4G9LmKl007600; Mon, 16 May 2011 10:21:48 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: SM References: <6.2.5.6.2.20110416044709.056adc60@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 16 May 2011 10:21:48 +0100 In-Reply-To: (Henry S. Thompson's message of "Sun, 15 May 2011 16:33:00 +0100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-xcon-ccmp-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 09:22:06 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ht writes: > SM writes: > >> The review of draft-ietf-xcon-ccmp-12 [1] has been assigned to you > > Here's my draft response. This is the first review I've done for the > IETF, and so I'm sending it only to the list in the first instance -- > if some others here could briefly review my review, and let me know if > it's along the lines you would expect, takes the right tone, etc., I'd > be very grateful. I got useful feedback from SM and have shipped the review. ht =2D --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFN0OyskjnJixAXWBoRAl9ZAJwOgMw6DXN2YJ5PM4lmcY460L/68QCeN+uP HBkTm68kWZrLqAIa3IUuYeY=3D =3D9JZn =2D----END PGP SIGNATURE----- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA1E06CB for ; Sun, 15 May 2011 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilRta84KJNMS for ; Sun, 15 May 2011 11:15:02 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id C8CEBE068C for ; Sun, 15 May 2011 11:15:02 -0700 (PDT) Received: from subman.elandsys.com ([41.136.238.22]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p4FIErH0028021; Sun, 15 May 2011 11:14:59 -0700 Message-Id: <6.2.5.6.2.20110515104508.03845158@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 May 2011 11:15:46 -0700 To: "Henry S. Thompson" From: SM In-Reply-To: References: <6.2.5.6.2.20110416044709.056adc60@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-xcon-ccmp-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 18:15:03 -0000 Hi Henry, At 08:33 15-05-2011, Henry S. Thompson wrote: >Here's my draft response. This is the first review I've done for the >IETF, and so I'm sending it only to the list in the first instance -- >if some others here could briefly review my review, and let me know if >it's along the lines you would expect, takes the right tone, etc., I'd >be very grateful. In particular, if it's really not appropriate at >this stage in the process to raise the kind of design questions I ask >below wrt 4.2 and 4.3, I'll just remove them. It is appropriate to raise any questions which can help improve the document. I suggest leaving the questions. The first review is usually the difficult one. What I generally like to get from a review is a different perspective and you provided that. You struck the right tone. Some people take a direct approach, some have a diplomatic approach and some people have their own style. >Summary: [Provide a one-sentence summary of the review. Examples >include "This draft is ready for publication as an Experimental RFC", >"This draft is almost ready for publication as an Informational RFC >but has a few issues that should be fixed before publication", and >"This draft is not ready for publication as a Proposed Standard and >should be revised before publication".] There are several alternatives available here. The reviewer should pick one of them. You can diverge from the template as the examples are there as guidance. >Nits: [list editorial issues such as typographical errors, preferably >by section number] The reviewer does not have to look for editorial issues. If you find them, list them here. Otherwise, you can omit this section or leave it empty. If you are comfortable with the review, you can post it after fixing the two points I commented on. If you need a clarification on any of my comments, please do not hesitate to ask me. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31AE06CA for ; Sun, 15 May 2011 08:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnRRsmye0Bok for ; Sun, 15 May 2011 08:33:33 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id BC49CE0651 for ; Sun, 15 May 2011 08:33:31 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id p4FFX2YM016805; Sun, 15 May 2011 16:33:02 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p4FFX1NM024592; Sun, 15 May 2011 16:33:01 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p4FFX1gQ022208; Sun, 15 May 2011 16:33:01 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id p4FFX0dN022204; Sun, 15 May 2011 16:33:00 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: SM References: <6.2.5.6.2.20110416044709.056adc60@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Sun, 15 May 2011 16:33:00 +0100 In-Reply-To: <6.2.5.6.2.20110416044709.056adc60@elandnews.com> (SM's message of "Sat, 16 Apr 2011 04:50:53 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-xcon-ccmp-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 15:33:34 -0000 SM writes: > The review of draft-ietf-xcon-ccmp-12 [1] has been assigned to you Here's my draft response. This is the first review I've done for the IETF, and so I'm sending it only to the list in the first instance -- if some others here could briefly review my review, and let me know if it's along the lines you would expect, takes the right tone, etc., I'd be very grateful. In particular, if it's really not appropriate at this stage in the process to raise the kind of design questions I ask below wrt 4.2 and 4.3, I'll just remove them. ht [1] https://datatracker.ietf.org/doc/draft-ietf-xcon-ccmp/ ================================= I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-xcon-ccmp-13 Title: Centralized Conferencing Manipulation Protocol Reviewer: Henry S. Thompson Review Date: 2011-05-13 Summary: [Provide a one-sentence summary of the review. Examples include "This draft is ready for publication as an Experimental RFC", "This draft is almost ready for publication as an Informational RFC but has a few issues that should be fixed before publication", and "This draft is not ready for publication as a Proposed Standard and should be revised before publication".] Major Issues: 4.2 Data Management 1) The approach to detecting competing updates and their consequences specified here seems unnecessarily complex. Was the alternative of including version numbers in _update_ messages (so that the server could reject any update whose target version had been superseded) considered and rejected? If so, perhaps a brief explanation of why it was rejected might be helful at this point. 2) In a related point, the statement at the end of this section that "a client subscribed to . . . notifications . . . will always have the most up-to-date version" is clearly false, in-so-far as it implies that such a client is guaranteed success for any update, as there is clearly a race condition here. 4.3 Data Model Compliance 1) Again this approach seems unnecessarily complex -- why does the data model have to constrain the initiation of a conference in this way. why not simply have messages which request new conference or new user IDs? 2) I'm also confused by the fact that _elements_ described here as "mandatory" are not required by the schema. Specifically in 5.1 we will see that the 'confUserID' and 'confObjID' elements, which correspond precisely to XCON-USERID and XCON-URI which are described here as mandatory, appear in message type definitions as minOccurs="0", i.e. as optional. If they are optional, why is the above gensym complexity needed? If they are not optional, why doesn't the schema say so? 3) It is unusual to refer to aspects of a data model with words such as 'element' and 'attribute', which are better reserved for use with respect to _XML serializations_ of data model instances. Ah, I see by looking at draft-ietf-xcon-common-data-model that the XCON data model is defined as an XML document. It's undoubtedly too late to do anything about that, but confounding data models and XML serializations is usually considered to be a mistake. . . 11. XML Schema An http URI should be provided where this schema document can be found on its own, and an update policy for it (or, preferably, _two_ URIs, one for exactly this schema document, and one which will be updated if this document is revised or superseded). (Likewise for DataModel.xsd and rfc4575.xsd.) 12.5 CCMP Protocol Registry Why are these registries needed? No role is specified for them anywhere in the body of the document. Registries are not free, and if all the information in the registry is also in the schemas Minor Issues: 6.2. Alice gets detailed information about a specific blueprint The blueprintResponse message is not schema-valid per ccmp.xsd. On lines 32 and 33 of the example read confirm The problem really lies in DataModel.xsd -- whereas (correctly) ccmp.xsd uses xs:token as the base type for enumerated types, DataModel.xsd (in draft-ietf-xcon-common-data-model) uses xs:string, and the string value of the above element is "confirm ", which is not one of the allowed values. The example should be corrected, or, for preference, the schema in draft-ietf-xcon-common-data-model should be changed to use xs:token as the base type for join-handling-type and all other enumerated types. A similar problem occurs in the response in 6.3 (floor-request-handling) 6.9 Alice exploits a CCMP server extension For compatibility with the actual response given, the extension schema document should have a target namespace, as follows: Or, better, the example _and_ the schema should be changed to read as follows: xcon-userid:Alice@example.com xcon:8977794@example.com retrieve 200 success confSummaryRequest Alice's conference active true audio Otherwise I've checked all the schemas for conformance and the examples for schema-validity. 12.2 XML Schema Registration Should include pointers to the RFCs which include the text of the schema documents named as "DataModel.xsd" and "rfc4575.xsd" in the schema docuemnt given in section 11. 12.3 Media Type Registration It seems unlikely that the proposed extension of 'ccmpxml' will see much use---4 characters seems to be the practical limit for extensions. Nits: [list editorial issues such as typographical errors, preferably by section number] -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17799E06F2 for ; Mon, 9 May 2011 14:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR67buOzsQLO for ; Mon, 9 May 2011 14:43:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3631BE06CF for ; Mon, 9 May 2011 14:43:49 -0700 (PDT) Received: from [192.168.43.47] (m490536d0.tmodns.net [208.54.5.73]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p49K00U9021988 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 13:00:08 -0700 Message-ID: <4DC847B5.5070106@dcrocker.net> Date: Mon, 09 May 2011 12:59:49 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: SM References: <4DC821FB.2050904@dcrocker.net> <6.2.5.6.2.20110509122236.04871058@elandnews.com> In-Reply-To: <6.2.5.6.2.20110509122236.04871058@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 09 May 2011 13:00:09 -0700 (PDT) Cc: dcrocker@bbiw.net, Apps Review Subject: Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 21:43:50 -0000 On 5/9/2011 12:44 PM, SM wrote: > Hi Dave, > At 10:18 09-05-2011, Dave CROCKER wrote: >> (This is an "official" and significantly extended version of an informal and >> narrow review I posted earlier. /d) > > Thanks for doing the review. > > I didn't notice any recommendation about whether the draft should be published > or not. Out of curiosity, what would you recommend? The paper needs quite a bit of work. I believe it all falls into the category of "cleanup" rather than "re-thinking", but doing the cleanup might uncover some issues that fall into the latter category. That said, the paper appears to be documenting existing practice, in addition to exploring 'enhancements' and implications, and it's always good to publish such things. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE085E08AB for ; Mon, 9 May 2011 13:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfTaoANT5C4f for ; Mon, 9 May 2011 13:14:01 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 50081E086D for ; Mon, 9 May 2011 13:14:00 -0700 (PDT) Received: from subman.elandsys.com ([41.136.235.25]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p49JigR8025194; Mon, 9 May 2011 12:44:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1304970295; bh=TSqqLatDK8ZzL4gHgmpnwdC00h0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=F5TrqtHW7jWEf+3mOUh1JSs++RwV+4tLl9j0KqaGhLUFI7vfKk5igNC064cUr0M73 v7txWr4B35FZ/mKqSHT8+l39zXrA/XifHT07oKpNbRljf/wB2aeZ+q1pN/NdqWopzn wBnbP2tVzkzaZhtKVnw+19Jw6sQoxfIRP7mLDNMs= Message-Id: <6.2.5.6.2.20110509122043.0423ae60@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 May 2011 12:22:00 -0700 To: "Henry S. Thompson" From: SM In-Reply-To: References: <6.2.5.6.2.20110416044709.056adc60@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-xcon-ccmp-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 20:14:02 -0000 Hi Henry, At 10:38 09-05-2011, Henry S. Thompson wrote: >Should be done by the end of this week, sorry for delay. Thanks. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB42E06EC for ; Mon, 9 May 2011 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG9+5wkyYV1e for ; Mon, 9 May 2011 12:45:43 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0D34DE0682 for ; Mon, 9 May 2011 12:45:21 -0700 (PDT) Received: from subman.elandsys.com ([41.136.235.25]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p49JigRA025194; Mon, 9 May 2011 12:45:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1304970308; bh=KaJ7JbA1/HMeqWdg6Mq6l7YcGi0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=O8YJUO7388t2wmld5vAyjXkKs8SMGbIGZXKL/ZiP+GRg+JMa28CBWoZiOrT7E2JWZ SKLt0SGCytsVIxMudVle+LCjGpNSzdToLdEUQreFp1XiaWv2fTu3SaswYozGy18y7U w3niCvd+1mweJP25xBib2NPQBN2GJfX0MQFKKkuM= Message-Id: <6.2.5.6.2.20110509122236.04871058@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 09 May 2011 12:44:01 -0700 To: dcrocker@bbiw.net From: SM In-Reply-To: <4DC821FB.2050904@dcrocker.net> References: <4DC821FB.2050904@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Apps Review Subject: Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:45:45 -0000 Hi Dave, At 10:18 09-05-2011, Dave CROCKER wrote: >(This is an "official" and significantly extended version of an >informal and narrow review I posted earlier. /d) Thanks for doing the review. I didn't notice any recommendation about whether the draft should be published or not. Out of curiosity, what would you recommend? FWIW, I did not take a position as the draft was already on the list of assignments. One of the questions that I did not cover in my comments was the Applications Area perspective. Due to lack of time, I am not expanding on this. If the team thinks that it worth starting a discussion about IPv6 and applications, feel free to start a new thread. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E70E092A for ; Mon, 9 May 2011 10:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6D-Ee8R2mQj for ; Mon, 9 May 2011 10:38:54 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 12434E0922 for ; Mon, 9 May 2011 10:38:51 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id p49Hc9f6004494; Mon, 9 May 2011 18:38:14 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p49Hc9Si012987; Mon, 9 May 2011 18:38:09 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id p49Hc9Hb019910; Mon, 9 May 2011 18:38:09 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.13.8/8.13.8/Submit) id p49Hc8ej019906; Mon, 9 May 2011 18:38:08 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: SM References: <6.2.5.6.2.20110416044709.056adc60@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 09 May 2011 18:38:08 +0100 In-Reply-To: <6.2.5.6.2.20110416044709.056adc60@elandnews.com> (SM's message of "Sat, 16 Apr 2011 04:50:53 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-xcon-ccmp-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:38:59 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SM writes: > The review of draft-ietf-xcon-ccmp-12 has been assigned to you and is > due before April 28. Should be done by the end of this week, sorry for delay. ht =2D --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFNyCaAkjnJixAXWBoRAs22AJ47SHqtsdynjKbJ0Joo5J2ehHQkUACePqcG Bkptt27V6Ju5H6turK+EWXw=3D =3DzdyC =2D----END PGP SIGNATURE----- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2307CE088A; Mon, 9 May 2011 10:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3X9cPry4hYu; Mon, 9 May 2011 10:19:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7257E0829; Mon, 9 May 2011 10:19:03 -0700 (PDT) Received: from [192.168.1.5] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p49HIr8t018539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 10:18:58 -0700 Message-ID: <4DC821FB.2050904@dcrocker.net> Date: Mon, 09 May 2011 10:18:51 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF Discussion Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 09 May 2011 10:19:00 -0700 (PDT) Cc: "v6ops@ietf.org" , Jason Livingood , Apps Review Subject: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)* X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 17:19:08 -0000 (This is an "official" and significantly extended version of an informal and narrow review I posted earlier. /d) Howdy. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Review (v2): Title: IPv6 AAAA DNS Whitelisting Implications I-D: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 By: D. Crocker Date: <> Summary ======= This draft covers a a dual-stack problem in which a target host's DNS entry contains records for IPv4 and IPv6, but returning IPv6 information to a DNS client can cause problems. The paper discusses for resolving this through use of a a DNS-based mechanism that manually lists response preferences to select which DNS records to return. The paper describes the mechanism and explores various effects and possibilities of its use, including the difference between using it selectively among a smaller number of sites, versus universally. The draft is a serious effort to explore the use of such a mechanism and it touches many different issues. It is generally well-organized and clearly written, although it very much needs the aid of a professional technical editor. The writing often assumes too much knowledge by the reader. The paper's exploration of universal adoption seems to vary between considering that goal practical versus considering it only as a matter of completeness for discussing the full range of possibilities. That is, it is not clear whether the paper views this alternative as practically possible and even preferred, versus only a matter for academic thoroughness. The paper needs to take a basic position about feasibility, explain it in terms of comparable adoption efforts at Internet-scale, and then make its treatment of universal adoption a bit more consistent. When introducing terms, mechanisms, configurations and scenarios, the paper needs to be more careful to describe them adequately for a reader new to the topic. This is not a matter of having a tutorial about the DNS, but rather a tutorial for this type of mechanism and when and how it can be used. As a specific example, the document cites "domain-by-domain" use, but I am not clear how that would work, in terms of configuration and cross-net information exchange. One question is how the server knows the 'domain' of the client? The document should careful to distinguish what is existing practice, versus what is being explored as added possibilities. The difference in concreteness and certitude between the two is substantial. The document's use of the term whitelisting appears to continue an existing, recent use, for this type of mechanism. Unfortunately it directly conflicts with long-standing use of the term by the anti-abuse community for whitelisting in the DNS. Its use here also seems to be a mismatch with the word's dictionary semantics, which is most naturally used to distinguish yes/no choices, rather than either/or choices. So there is no intuitive sense of "goodness" (whitelist = yes) or "badness" (blacklist) for this use. The word "preferences" seems more in line with the meaning of the mechanism. Detailed Comments ================= > Abstract > > The objective of this document is to describe what the whitelisting > of DNS AAAA resource records is, hereafter referred to as DNS RRs are whitelisted? Isn't it the addresses and not the records that are whitelisted? Does this mean putting whitelisting records into the DNS or does it mean something else? Comcast's own considerable expertise notwithstanding, has this doc been vetted with a range of organizations that actually DO whitelisting? Has it been circulated through MAAWG and APWG? Any comments from Spamhaus? The Acknowledgements list does not seem to indicate a range of whitelist ops folks whose names I know. (But then, I only know a few...) > 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. I suspect that product marketers won't have much interest in this. I suspect that the target for this is anti-abuse technical and operations staff. In any event, the targetting statement should be more precise. > 1. Introduction > > This document describes the emerging practice of whitelisting of DNS One natural, semantic problem with the term 'whitelist' is that it does not really match the function being performed. The white/black distinction implies goodness -- or as Wikipedia says, "priviledge". Instead, the use here is for preference or priority. What would a "blacklist" be, here? Also note it is not obvious what it means to be whitelisted, here? Does it mean to choose the AAAA records or the A records? This is more like a 'Preference' or 'Configuration' list. At the least, the name for this should be IPv6 Resolver Whitelisting. It makes clear /what/ is being "whitelisted". > AAAA resource records (RRs), which contain IPv6 addresses, hereafter > referred to as DNS whitelisting. The document explores the This provides a name, but not a function. That is, it does not say what this mechanisms actually /does/ or is /for/. > implications of this emerging practice are and what alternatives may > exist. > > The practice of DNS whitelisting appears to have first been used by > major web content sites (sometimes described herein as "highly- It's use for email anti-abuse dates back farther. Specifically within the context of the DNS, the term whitelisting is therefore made ambiguous. A google query for "whitelist dns" also demonstrates the history and current ambiguity. > trafficked domains" or "major domains"). These web site operators, > or domain operators, observed that when they added AAAA resource > records to their authoritative DNS servers in order to support IPv6 > access to their content that a small fraction of end users had slow > or otherwise impaired access to a given web site with both AAAA and A > resource records. The fraction of users with such impaired access > has been estimated to be roughly 0.078% of total Internet users > [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6 > Brokenness]. Thus, in an example Internet Service Provider (ISP) > network of 10 million users, approximately 7,800 of those users may > experience such impaired access. At a minimum, these sorts of statistics need to be normalized across IPv6 users/traffic, given how small a percentage that is, in total users and total traffic. If that's what is meant it should be stated. If it isn't, the statistic should be recalculated and explained a bit more precisely. > As a result of this impairment affecting end users of a given domain, > a few major domains have either implemented DNS whitelisting or are > considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations]. > When implemented, DNS whitelisting in practice means that a domain's > authoritative DNS will return a AAAA resource record to DNS recursive > resolvers [RFC1035] on the whitelist, while returning no AAAA > resource records to DNS resolvers which are not on the whitelist. It This explanation of the function should be offered sooner and should be summarized in the Abstract. > is important to note that these major domains are motivated by a > desire to maintain a high-quality user experience for all of their Rather than being important to note, this sentence sounds oddly like marketing hype, in a technical specification. It is gratuitous because specified features are never added to /lower/ the quality of the user experience, for example. In addition, the mechanism also affects client activity that has no user directly involved. > users. By engaging in DNS whitelisting, they are attempting to > shield users with impaired access from the symptoms of those > impairments. The /technical/ statement that should be here is that they are attempting to provide a work-around for problematic behaviors in dual-stack IPv4/IPv6 environments. The paper should make more clear exactly where the problem lies and when. If it can occur for a number of reasons, explaining each of those scenarios would be useful. > Critics of the practice of DNS whitelisting have articulated several > concerns. Among these are that: > > o DNS whitelisting is a very different behavior from the current > practice concerning the publishing of IPv4 address resource > records, > > o that it may create a two-tiered Internet, > > o that policies concerning whitelisting and de-whitelisting are > opaque, > > > > > > Livingood Expires August 26, 2011 [Page 5] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > o that DNS whitelisting reduces interest in the deployment of IPv6, > > o that new operational and management burdens are created, well, yeah... in fact it should be noted that the burdens are particularly onerous at scale. > o and that the costs and negative implications of DNS whitelisting > outweigh the perceived benefits, compared to fixing underlying > impairments. and it doesn't scale. and it violates an extremely basic premise of cross-Internet interoperability by requiring prior arrangement. > This document explores the reasons and motivations for DNS > whitelisting. It also explores the outlined concerns regarding this > practice. Readers will hopefully better understand what DNS > whitelisting is, why some parties are implementing it, and what > criticisms of the practice exist. > > > 2. How DNS Whitelisting Works How IPv6 AAAA DNS Whitelisting Works. (Anti-spam DNS Whitelisting works rather differently...) > DNS whitelisting is implemented in authoritative DNS servers. These > servers implement IP address-based restrictions on AAAA query > responses. So far, DNS whitelisting has been primarily implemented > by web server operators deploying IPv6-enabled services. For a given Really? This is web-specific? The same restrictions are not applied for other applications? So if the same client-side hosts attempt to contact the server for email or xmpp, they won't get the same handling? > operator of a website, such as www.example.com, the operator > essentially applies an access control list (ACL) on the authoritative > DNS servers for the domain example.com. The ACL is populated with An ACL usually is a yes/no mechanism. Here, however, the mechanism is for asserting a preference for IPv6 over IPv4. That does not seem to match the definition of ACL that I'm used to, unless the semantic is defined as denying IPv4 access to the listed clients. The term ACL is particularly odd to use if the mechanism pertains to responses rather than queries. > the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive Either address type can be listed? So this really is a pure 'preferences' mechanism? Which settings count as whitelisting? Do any count as blacklisting? > resolvers on the Internet, which have been authorized to receive AAAA > resource record responses. These DNS recursive resolvers are > operated by third parties, such as ISPs, universities, governments, > businesses, and individual end users. If a DNS recursive resolver IS > NOT matched in the ACL, then AAAA resource records will NOT be sent > in response to a query for a hostname in the example.com domain. This configuration appears to ensure the maximum barrier to adoption for IPv6, since it means that IPv6 will not work automatically. It will only work for hosts that are manually configured to receive responses with v6 records. That's a rather major implication. It's a default that is probably meant to apply during the very early stages of adoption, when there are few users of the newer mechanism. It's probably worth discussing it in more detail, including discussing when to change the default... > However, if a DNS recursive resolver IS matched in the ACL, then AAAA > resource records will be sent in response to a query for a given > hostname in the example.com domain. While these are not network- > layer access controls they are nonetheless access controls that are a > factor for end users and other parties like network operators, > especially as networks and hosts transition from one network address > family to another (IPv4 to IPv6). Also, all of this clarifies the function of this listing mechanism and suggests a very different name, to be more precise and accurate in naming it: IPv6 DNS Response Preference List. > 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. The large majority of > DNS resolvers on the Internet will therefore receive only A resource > records containing IPv4 addresses. Thus, quite simply, the > authoritative server hands out different answers depending upon who > is asking; with IPv4 and IPv6 resource records for some on the > authorized whitelist, and only IPv4 resource records for everyone > else. See Section 2.1 and Figure 1 for a description of how this > > > > Livingood Expires August 26, 2011 [Page 6] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > works. > > 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. > > 2.1. Description of the Operation of DNS Whitelisting > > The system logic of DNS whitelisting is as follows: > > 1. The authoritative DNS server for example.com receives DNS queries > for the A (IPv4) and AAAA (IPv6) address resource records for the > FQDN www.example.com, for which AAAA (IPv6) resource records > exist. This means that the mechanism is /only/ triggered when /both/ address records are queried? A query for only one type of address record won't trigger the list lookup? I think that doesn't match other statements in the document. > 2. The authoritative DNS server examines the IP address of the DNS > recursive resolver sending the AAAA (IPv6) query. "examines"? Examines it for what? What does this step mean? > 3. The authoritative DNS server checks this IP address against the > access control list (ACL) that is the DNS whitelist. > > 4. If the DNS recursive resolver's IP address IS matched in the ACL, > then the response to that specific DNS recursive resolver can > contain AAAA (IPv6) address resource records. Oh. This is not about whether to send responses /over/ v6 vs. v4? This is whether to /include/ a particular type of RR in responses??? In that case an appropriate name for this mechanism is more like: DNS Response Content Preference List And this seems even less like an ACL than it did before. (I assume the justification is that access is being prevented by virtue of not supplying the address, but still...) > 5. If the DNS recursive resolver's IP address IS NOT matched in the > ACL, then the response to that specific DNS recursive resolver > cannot contain AAAA (IPv6) address resource records. In this > case, the server should return a response with the response code > (RCODE) being set to 0 (No Error) with an empty answer section > for the AAAA record query. > > > > > > > > > > > > > > > > Livingood Expires August 26, 2011 [Page 7] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > --------------------------------------------------------------------- > A query is sent from a DNS recursive resolver that IS NOT on the DNS > whitelist: > > Request Request > www.example.com www.example.com > AAAA +-------------+ AAAA +-----------------+ > ++--++ ---------> | RESOLVER | ---------> | www.example.com | > || || A | **IS NOT** | A | IN A exists | > +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | > +--------+ A | example.com | A | | > Host <--------- | WHITELIST | <--------- | | > Computer A Record +-------------+ A Record +-----------------+ > Response DNS Recursive Response example.com > (only IPv4) Resolver (only IPv4) Authoritative > #1 Server > --------------------------------------------------------------------- > A query is sent from a DNS recursive resolver that IS on the DNS > whitelist: > > Request Request > www.example.com www.example.com > AAAA +-------------+ AAAA +-----------------+ > ++--++ ---------> | RESOLVER | ---------> | www.example.com | > || || A | **IS** | A | IN A exists | > +-++--++-+ ---------> | ON | ---------> | IN AAAA exists | > +--------+ AAAA | example.com | AAAA | | > Host <--------- | WHITELIST | <--------- | | > Computer A | | A | | > <--------- | | <--------- | | > A and AAAA +-------------+ A and AAAA +-----------------+ > Record DNS Recursive Record example.com > Responses Resolver Responses Authoritative > (IPv4+IPv6) #2 (IPv4+IPv6) Server > --------------------------------------------------------------------- > > Figure 1: DNS Whitelisting - Functional Diagram This diagram is confusing to me. I suspect that a protocol exchange sequence format, in the style of: Host Resolver 1 Authoritative ----------> ---------> <--------- <---------- will be considerably more helpful. > 3. What Problems Are Implementers Trying To Solve? This is a very useful section and it is probably worth moving it higher, to precede the 'how it works' section. > 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). By the way, what does 'impaired v6 access' mean? I think there needs to be a simple, direct description of what occurs without this mechanism. For example, perhaps you mean that a host can send DNS queries using IPv6 but cannot receive DNS responses over IPv6? Perhaps you mean that the host can send IPv6 but cannot receive it. (That's a different scale and scope of problem from the first example I gave.) This brief, summary problem statement should be included in the Abstract, to make /much/ more clear what this mechanism is for. > 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. It would affect access to all or most dual > > > > Livingood Expires August 26, 2011 [Page 8] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > stack services to which the user attempts to connect. This negative > end user experience can range from someone slower than usual (as > compared to native IPv4-based access), to extremely slow, to no > access to the domain whatsoever. Rather than repeat that this is about end-users, it sounds more that this is about whether a service works or does not work, whether a user is directly present or not. > While one can debate whether DNS whitelisting is the optimal solution > to the end user experience problem, it is quite clear that DNS > whitelisting implementers are interested in maximizing the > performance of their services for end users as a primary motivation > for implementation. You keep citing 'performance' but haven't described what sort of performance degradation takes place. Is this really about relatively better or worse performance -- and if so, how -- or is this about working or not working? Also rather than saying what implementers are interested in, it's probably more helpful to note that the practice is now significantly established and therefore worth documenting, independent of its possible controversy. > At least one highly-trafficked domain has noted that they have > received requests to not send DNS responses with AAAA resource > records to particular resolvers. In this case, the operators of "At least one" seems a rather tiny statistic. Perhaps the actual statistic is significantly larger? > those recursive resolvers have expressed a concern that their IPv6 I suspect that it's not resolvers that are doing the expressing, since their vocabulary is usually too limited... > network infrastructure is not yet ready to handle the large traffic > volume which may be associated with the hosts in their network > connecting to the websites of these domains. This concern is clearly So even though the site allows v6 DNS queries to go out from a host, it can't really support having the host use v6? Wow. I do understand why service providers often have to work around silliness at the client side, but this problem at the client side seems particularly egregious. > a temporary consideration relating to the deployment of IPv6 network > infrastructure on the part of networks with end user hosts, rather > than a long-term concern. These end user networks may also have Again this goal of short-term usage is worth noting earlier, including in the Abstract. > other tools at their disposal in order to address this concern, > including applying rules to network equipment such as routers and > firewalls (this will necessarily vary by the type of network, as well > as the technologies used and the design of a given network), as well > as configuration of their recursive resolvers (though modifying or > suppressing AAAA resource records in a DNSSEC-signed domain on a > Security-Aware Resolver will be problematic Section 10.1). > > Some implementers with highly-trafficked domains have explained that > DNS whitelisting is a necessary, though temporary, risk reduction > tactic intended to ease their transition to IPv6 and minimize any > perceived risk in such a transition. As a result, they perceive this > as a tactic to enable them to incrementally enable IPv6 connectivity > to their domains during the early phases of their transition to IPv6. > > Finally, some domains, have run IPv6 experiments whereby they added > AAAA resource records and observed and measured errors [Heise Online > Experiment], which should be important reading for any domain > contemplating either the use of DNS whitelisting or simply adding > IPv6 addressing to their site. > > > 4. Concerns Regarding DNS Whitelisting > > 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 I think the implications are not conditional; they exist rather than being potential. The 'potential' is that what is implicated will come to pass. > > Livingood Expires August 26, 2011 [Page 9] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > enumerated here and in Section 7. Pro forma question: Why are implications discussed in multiple places? > Some parties in the Internet community, including ISPs, are concerned This style of text personalizes the issues unnecessarily (IMO). It does not really matter who holds the concerns, or else they'd be described more precisely. I suggest merely noting that there are concerns and then listing and discussing the concerns, rather than adding text to attribute the concerns to others, even if the conclusion of your text is that a particular concern is not valid. > that the practice of DNS whitelisting for IPv6 address resource > records represents a departure from the generally accepted practices > regarding IPv4 address resource records in the DNS on the Internet > [Whitelisting Concerns]. These parties explain their belief that for "These parties explain their belief" is an example of personalization that is not needed. This isn't about the believers. It is about possible problems. > A resource records, containing IPv4 addresses, once an authoritative > server operator adds the A record to the DNS, then any DNS recursive > resolver on the Internet can receive that A record in response to a This does not appear to be a grammatically valid sentence. My guess is that deleting "A resource... addresses" fixes this. And by the way, the document's reference to "recursive" resolvers is mostly likely incorrect. The problem is not restricted only to that very specific type of resolver, is it? If in fact it /is/ specific to them -- and your following text describes an indirect effects scenario where it might be -- I suggest calling out the configuration at the beginning, along the lines of: One way the problem with returning AAAA records can be experienced is when recursive resolvers are used. Although that resolver might support IPv6, its client hosts might not. So, returning an AAAA record will mean that these limited hosts will be given an unusable address. And this type of description belongs in the text describing the motivating problem(s), rather than buried in the 'concerns' discussion. (The text, here, pertains to A records, but the problem I've described uses the same configuration but for AAAA records with mixed v6 support.) > query. By extension, this means that any of the hosts connected to > any of these DNS recursive resolvers can receive the IPv4 address > resource records for a given FQDN. This enables new server hosts > which are connected to the Internet, and for which a fully qualified > domain name (FQDN) such as www.example.com has been added to the DNS > with an IPv4 address record, to be almost immediately reachable by > any host on the Internet. In this case, these new servers hosts > become more and more widely accessible as new networks and new end > user hosts connect to the Internet over time, capitalizing on and > increasing so-called "network effects" (also called network > externalities). It also means that the new server hosts do not need > to know about these new networks and new end user hosts in order to > make their content and applications available to them, in essence > that each end in this end-to-end model is responsible for connecting > to the Internet and once they have done so they can connect to each > other without additional impediments or middle networks or > intervening networks or servers knowing about these end points and > whether one is allowed to contact the other. Hmmm. This rather lengthy bit of prose appears merely to be explaining the basic and long-standing DNS value proposition??? > In contrast, the concern is that DNS whitelisting may fundamentally > change this model. In the altered DNS whitelisting end-to-end model, > one end (where the end user is located) cannot readily connect to the > other end (where the content is located), without parts of the middle > (recursive resolvers) used by one end (the client, or end user hosts) > being known to an intermediary (authoritative nameservers) and > approved for access to the resource at the end. As new networks > connect to the Internet over time, those networks need to contact any > and all domains which have implemented DNS whitelisting in order to > apply to be added to their DNS whitelist, in the hopes of making the > content and applications residing on named server hosts in those > domains accessible by the end user hosts on that new network. > Furthermore, this same need to contact all domains implementing DNS > whitelisting also applies to all pre-existing (but not whitelisted) > networks connected to the Internet. > > In the current IPv4 Internet when a new server host is added to the > Internet it is generally widely available to all end user hosts and > networks, when DNS whitelisting of IPv6 resource records is used, If it is available to the hosts, it is available to the network. networks, when -> networks. When > > > > Livingood Expires August 26, 2011 [Page 10] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > these new server hosts are not accessible to any end user hosts or > networks until such time as the operator of the authoritative DNS They are still accessible. The IP-level mechanisms still work. They are not reachable when using the domain name. > servers for those new server hosts expressly authorizes access to > those new server hosts by adding DNS recursive resolvers around the > Internet to the ACL. This has the potential to be a significant This is a good example of the reason the term ACL is inappropriate: It implies a security protection that does not actually exist. The hosts are still accessible. > change in reachability of content and applications by end users and > networks as these end user hosts and networks transition to IPv6, > resulting in more (but different) breakage. A concern expressed is > that if much of the content that end users are most interested in is > not accessible as a result, then end users and/or networks may resist > adoption of IPv6 or actively seek alternatives to it, such as using > multi-layer network address translation (NAT) techniques like NAT444 > [I-D.shirasaki-nat444] on a long-term basis. There is also concern > that this practice also could disrupt the continued increase in > Internet adoption by end users if they cannot simply access new > content and applications but must instead contact the operator of > their DNS recursive resolver, such as their ISP or another third > party, to have their DNS recursive resolver authorized for access to > the content or applications that interests them. Meanwhile, these > parties say, over 99.9% of the other end users that are also using > that same network or DNS recursive resolver are unable to access the > IPv6-based content, despite their experience being a positive one. > > 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 8 hundredths of one percent? That's considered a high percentage? Even if it is 8%, is that considered high? > 5.2. Similarities to DNS Load Balancing > > DNS whitelisting also has some similarities to DNS load balancing. > There are of course many ways that DNS load balancing can be > performed. In one example, multiple IP address resource records (A > and/or AAAA) can be added to the DNS for a given FQDN. This approach > is referred to as DNS round robin [RFC1794]. DNS round robin may > also be employed where SRV resource records are used [RFC2782]. Right, but that's algorithmic rather than involving the manual method, described here. So it does not seem comparable. > 6. Likely Deployment Scenarios > > In considering how DNS whitelisting may emerge more widely, there are > two likely deployment scenarios, which are explored below. > > In either of these deployment scenarios, it is possible that > reputable third parties could create and maintain DNS whitelists, in > much the same way that blacklists are used for reducing email spam. > In the email context, a mail operator subscribes to one or more of > these lists and as such the operational processes for additions and > deletions to the list are managed by a third party. A similar model > could emerge for DNS whitelisting, whether deployment occurs > universally or on an ad hoc basis. The challenges of email whitelists and blacklists should be cited, since it provides a rich base of experience for such an effort, at scale. > 6.1. Deploying DNS Whitelisting On An Ad Hoc Basis > > The seemingly most likely deployment scenario is where some Most likely? This is not already established practice? > authoritative DNS server operators implement DNS whitelisting but > many or most others do not do so. What can make this scenario > challenging from the standpoint of a DNS recursive resolver operator > is determining which domains implement DNS whitelisting, particularly > since a domain may not do so as they initially transition to IPv6, > and may instead do so later. Thus, a DNS recursive resolver operator > > > > Livingood Expires August 26, 2011 [Page 13] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > may initially believe that they can receive AAAA responses as a > domain adopts IPv6, but then notice via end user reports that they no > longer receive AAAA responses due to that domain adopting DNS > whitelisting. Of course, a domain's IPv6 transition may be > effectively invisible to recursive server operators due to the effect > of DNS whitelisting. This suggests that every listing at the server needs a contact record for periodic checks whether to renew the listing. > > In contrast to a universal deployment of DNS whitelisting > Section 6.2, deployment on an ad hoc basis is likely to be > significantly more challenging from an operational, monitoring, and Oh? Use in small scale is more challenging than use of manual exceptions list at large scale? That's a very unexpected view. > troubleshooting standpoint. In this scenario, a DNS recursive > resolver operator will have no way to systematically determine > whether DNS whitelisting is or is not implemented for a domain, since > the absence of AAAA resource records may simply be indicative that > the domain has not yet added IPv6 addressing for the domain, rather > than that they have done so but have restricted query access via DNS The premise is that, in large scale use, servers /will/ have a way to systematically determine whether it is implemented? What are the existing examples of having such a capability for other Internet protocols and services? > whitelisting. As a result, discovering which domains implement DNS > whitelisting, in order to differentiate them from those that do not, > is likely to be challenging. > > One benefit of DNS whitelisting being deployed on an ad hoc basis is > that only the domains that are interested in doing so would have to > upgrade their authoritative DNS servers in order to implement the > ACLs necessary to perform DNS whitelisting. > > In this potential deployment scenario, it is also possible that a > given domain will implement DNS whitelisting temporarily. A domain, > particularly a highly-trafficked domain, may choose to do so in order > to ease their transition to IPv6 through a selective deployment and > minimize any perceived risk in such a transition. > > 6.2. Deploying DNS Whitelisting Universally > > The least likely deployment scenario is one where DNS whitelisting is > implemented on all authoritative DNS servers, across the entire > Internet. While this scenario seems less likely than ad hoc > deployment due to some parties not sharing the concerns that have so > far motivated the use of DNS whitelisting, it is nonetheless > conceivable that it could be one of the ways in which DNS > whitelisting is deployed. Significantly, the partial-deployment model casts this mechanism as a transition expedient -- as the document reasonably describes it -- whereas universal deployment casts it as a fundamental change to the architecture. Given that it would take decades to achieve relatively full deployment of this 'across the entire Internet', what is the benefit of discussing this highly unlikely scenario? Is it really "conceivable"? I doubt it. If you think otherwise, the paper needs to explore the deployment and adoption issues in much more detail, because I don't see how it could work. > In order for this deployment scenario to occur, it is likely that DNS > whitelisting functionality would need to be built into all > authoritative DNS server software, and that all operators of > authoritative DNS servers would have to upgrade their software and > enable this functionality. It is likely that new Internet Draft > documents would need to be developed which describe how to properly > configure, deploy, and maintain DNS whitelisting. As a result, it is > > > > Livingood Expires August 26, 2011 [Page 14] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > unlikely that DNS whitelisting would, at least in the next several > years, become universally deployed. Furthermore, these DNS > whitelists are likely to vary on a domain-by-domain basis, depending > upon a variety of factors. Such factors may include the motivation > of each domain owner, the location of the DNS recursive resolvers in > relation to the source content, as well as various other parameters > that may be transitory in nature, or unique to a specific end user > host type. It is probably unlikely that a single clearinghouse for > managing whitelisting is possible; it will more likely be unique to > the source content owners and/or domains which implement DNS > whitelists. > > While this scenario may be unlikely, it may carry some benefits. > First, parties performing troubleshooting would not have to determine > whether or not DNS whitelisting was being used, as it always would be > in use. In addition, if universally deployed, it is possible that > the criteria for being added to or removed from a DNS whitelist could > be standardized across the entire Internet. Nevertheless, even if > uniform DNS whitelisting policies were not standardized, is also > possible that a central registry of these policies could be developed > and deployed in order to make it easier to discover them, a key part > of achieving transparency regarding DNS whitelisting. Is any of this paragraph realistic? Obviously my asking means I don't it is. These seem to be of theoretical rather than pragmatic interest. ("If everyone refuses to shoot, there will be no wars.") It's true that this is an "implications" paper rather than a BCP, but still... > > 7. Implications of DNS Whitelisting > > There are many potential implications of DNS whitelisting. The key > potential implications are detailed below. > > 7.1. Architectural Implications > > DNS whitelisting could be perceived as modifying the end-to-end model > and/or the general notion of the architecture that prevails on the I'll suggest that perception is not a major issue about a technical topic like this. (It's not entirely irrelevant, of course, but I suspect it is quite minor.) The major issue is whether it /actually/ modifies the end-to-end nature of the DNS. And I think it does, as well as modifying the "spontaneous interoperability" expectation for most Internet mechanism, since it requires prior registration. > 7.2. Public IPv6 Address Reachability Implications > > The predominant experience of end user hosts and servers on the IPv4- > addressed Internet today is that when a new server with a public IPv4 > address is added to the DNS, that it is then globally accessible by This sentence is not quite correct, in strict technical terms. Since this is a technical discussion, we need to be precise: the host is reachable when the routing tables make it reachable. That's strictly a mapper of IP Address handling, not name-to-address mapping. What you mean is that its domain name is immediately useful for reaching it. > IPv4-addressed hosts. This is a generalization and in Section 5 > there are examples of common cases where this may not necessarily be > the case. For the purposes of this argument, that concept of > accessibility can be considered "pervasive reachability". It has so > far been assumed that the same expectations of pervasive reachability > would exist in the IPv6-addressed Internet. However, if DNS > whitelisting is deployed, this will not be the case since only end > user hosts using DNS recursive resolvers which are included in the again, you mean /name-based/ reachability. > > > > Livingood Expires August 26, 2011 [Page 16] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > ACL of a given domain using DNS whitelisting would be able to reach > new servers in that given domain via IPv6 addresses. The expectation > of any end user host being able to connect to any server (essentially > both hosts, just at either end of the network), defined here as > "pervasive reachability", will change to "restricted reachability" > with IPv6. > > Establishing DNS whitelisting as an accepted practice in the early > phases of mass IPv6 deployment could well establish it as an integral > part of how IPv6 DNS resource records are deployed globally. As a > result, it is then possible that DNS whitelisting could live on for > decades on the Internet as a key foundational element of domain name > management that we will all live with for a long time. (that last sentence could benefit from some editing.) > It is a critical to understand that the concept of reachability > described above depends upon a knowledge or awareness of an address > in the DNS. Thus, in order to establish reachability to an end > point, a host is dependent upon looking up an IP address in the DNS If this section were started with a sentence like this, then there would not be a problem with the other references' being confused with address-based routing reachability. > when a FQDN is used. When DNS whitelisting is used, it is quite > likely the case that an IPv6-enabled end user host could ping or > connect to an example server host, even though the FQDN associated > with that server host is restricted via a DNS whitelist. Since most First, I suspect that "example" doesn't add meaning to the sentence. Second, pinging and connecting might happen with or without the whitelist entry. So I do not understand what import there is in this sentence. > Internet applications and hosts such as web servers depend upon the > DNS, and as end users connect to FQDNs such as www.example.com and do > not remember or wish to type in an IP address, the notion of > reachability described here should be understood to include knowledge > how to associate a name with a network address. Again, this 'premise' statement should introduce the sub-section, not end it. > > 7.3. Operational Implications > > This section explores some of the operational implications which may > occur as a result of, are related to, or become necessary when > engaging in the practice of DNS whitelisting. > > 7.3.1. De-Whitelisting May Occur The more general version of this issue is 'synchronization'. Entries in the whitelist need to be synchronized with host status and capabilities. > It is possible for a DNS recursive resolver added to a whitelist to > then be removed from the whitelist, also known as de-whitelisting. > Since de-whitelisting can occur, through a decision by the > authoritative server operator, the domain owner, or even due to a > technical error, an operator of a DNS recursive resolver will have > new operational and monitoring requirements and/or needs as noted in > Section 7.3.3, Section 7.3.4, Section 7.3.6, and Section 7.5. > > 7.3.2. Authoritative DNS Server Operational Implications > > Operators of authoritative servers may need to maintain an ACL a a -> on a (?) > server-wide basis affecting all domains, on a domain-by-domain basis, > > > Livingood Expires August 26, 2011 [Page 17] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > as well as on a combination of the two. As a result, operational I'm not really understanding the first sentence. One problem might be that its discussing an implication of some configuration or usage options that have not been previously specified, so that the reference here might be overly cryptic. For example, I don't know what "affecting all domains" actually means. It almost sounds as if it could mean "everyone gets AAAA records" or "no one gets AAAA records" yet I'm reaonably certain that is /not/ what is meant. > practices and software capabilities may need to be developed in order > to support such functionality. In addition, processes may need to be > put in place to protect against inadvertently adding or removing IP > addresses, as well as systems and/or processes to respond to such > incidents if and when they occur. For example, a system may be > needed to record DNS whitelisting requests, report on their status > along a workflow, add IP addresses when whitelisting has been > approved, remove IP addresses when they have been de-whitelisted, log > the personnel involved and timing of changes, schedule changes to > occur in the future, and to roll back any inadvertent changes. Might be worth starting with a simple, broad summary statement, possibly along the lines of: An AAAA DNS Whitelist serves as a critical infrastructure service; to be useful it needs careful and extensive administration, monitoring and operation. Each new and essential mechanism creates substantial follow-on support costs. > Operators may also need implement new forms of monitoring in order to > apply change control, as noted briefly in Section 7.3.4. > > 7.3.3. DNS Recursive Resolver Server Operational Implications > > Operators of DNS recursive resolvers, which may include ISPs, > enterprises, universities, governments, individual end users, and > many other parties, are likely to need to implement new forms of > monitoring, as noted briefly in Section 7.3.4. But more critically, > such operators may need to add people, processes, and systems in > order to manage large numbers of DNS whitelisting applications as > part of their own IPv6 transition, for all domains that the end users > of such servers are interested in now or in which they may be I think the summary observation is simple and should be stated directly: This is a manual mechanism that becomes expensive in time and personnel effort as it scales up. > interested in the future. As anticipation of interesting domains is > likely infeasible, it is more likely that operators may either choose > to only apply to be whitelisted for a domain based upon one or more > end user requests, or that they will attempt to do so for all domains > that they can ascertain to be engaging in DNS whitelisting. "attempt to do so for all domain that they can ascertain to be engaging in DNS whitelisting" appears to be saying to do whitelisting for domains that do whitelisting. I don't understand. > > When operators apply for DNS whitelisting for all domains, that may "apply for DNS whitelisting for all domains" -- again I'm not understanding what this means. > 7.3.5. Implications of Operational Momentum > > It seems plausible that once DNS whitelisting is implemented it will > be very difficult to deprecate such technical and operational > practices. This assumption is based in an understanding of human in -> on > nature, not to mention physics. For example, as Sir Issac Newton > noted, "Every object in a state of uniform motion tends to remain in > that state of motion unless an external force is applied to it" [Laws Code does not have momenum. Neither do configurations or lists. This really isn't about physics. It is entirely about group psychology, as you note, and the administrative challenges in the logistics of large-scale operational changes (which probably /does/ have something to with physics, but it seems a stretch to credit Newton. How about Heisenberg?...) > of Motion]. Thus, once DNS whitelisting is implemented it is quite > likely that it would take considerable effort to deprecate the > practice and remove it everywhere on the Internet - it will otherwise > simply remain in place in perpetuity. To better illustrate this > point, one could consider one example (of many) that there are many > email servers continuing to attempt to query or otherwise check anti- > > > > Livingood Expires August 26, 2011 [Page 19] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > spam DNS blocklists which have long ago ceased to exist. > > 7.3.6. Troubleshooting Implications > > The implications of DNS whitelisted present many challenges, which > have been detailed in Section 7. These challenges may negatively But this is /still/ section 7. Can you be more specific? Or perhaps say "throughout this section". > affect the end users' ability to troubleshoot, as well as that of DNS > recursive resolver operators, ISPs, content providers, domain owners > (where they may be different from the operator of the authoritative > DNS server for their domain), and other third parties. This may make > the process of determining why a server is not reachable > significantly more complex. > > 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, I'm pretty sure that scaling problems for this exist in all scenarios, not just ad hoc usage. > monitoring, and ACL updates. In particular, it seems likely that as > the number of domains that are using DNS whitelisting increases, as > well as the number of IPv6-capable networks requesting to be > whitelisted, that there is an increased likelihood of configuration > and other operational errors, especially with respect to the ACLs > themselves. > > It is unclear when and if it would be appropriate to change from > whitelisting to blacklisting, and whether or how this could feasibly > be coordinated across the Internet, which may be proposed or Actually the question of coordination is quite clear and rather fundamental: No. Anyone believing otherwise needs to cite a successful example, at Internet scale and diversity, more recently than the 1983 switch to IP (which didn't go all that well anyhow...) Simple, unambiguous showstoppers should be stated in a simple and direct manner. When there is room for debate, softer language makes sense. Again, if the question of coordination really is subject to debate, then the basis needs to be stated. (Good luck!) > implemented on an ad hoc basis when a majority of networks (or > allocated IPv6 address blocks) have been whitelisted. Finally, some > parties implementing DNS whitelisting consider this to be a temporary > measure. As such, it is not clear how these parties will judge the > network conditions to have changed sufficiently to justify disabling > DNS whitelisting and/or what the process and timing will be in order > to discontinue this practice. > > One further potential implication is that an end user with only an > IPv4 address, using a DNS resolver which has not been whitelisted by > any domains, would not be able to get any AAAA resource records. In > such a case, this could give that end user the incorrect impression > that there is no IPv6-based content on the Internet since they are > unable to discover any IPv6 addresses via the DNS. > > 7.4. Homogeneity May Be Encouraged > > A broad trend which has existed on the Internet appears to be a move > towards increasing levels of heterogeneity. One manifestation of increasing levels of heterogeneity -> more heterogeneity (I think heterogeneity does not have 'levels'.) Substantively: say the nature of the heterogeneity within the initial claim. For example, there is /less/ heterogeneity of ISPs, given industry consolidation. There is less heterogeneity of infrastructure equipment such as routers. Etc. > this is in an increasing number, variety, and customization of end > user hosts, including home network, operating systems, client > > > > Livingood Expires August 26, 2011 [Page 20] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > software, home network devices, and personal computing devices. This > trend appears to have had a positive effect on the development and > growth of the Internet. A key facet of this that has evolved is the > ability of the end user to connect any technically compliant device > or use any technically compatible software to connect to the > Internet. Not only does this trend towards greater heterogeneity > reduce the control which is exerted in the middle of the network, > described in positive terms in [Tussle in Cyberspace], [Rethinking > the Internet], and [RFC3724], but it can also help to enable greater > and more rapid innovation at the edges. > > An unfortunate implication of the adoption of DNS whitelisting may be > the encouragement of a reversal of this trend, which would be a move the encouragement of -> to encourage > 8.1. Implement DNS Whitelisting Universally > > One obvious solution is to implement DNS whitelisted universally, and > to do so using some sort of centralized registry of DNS whitelisting > policies, contracts, processes, or other information. This potential > solution seems unlikely at the current time. I'm pretty sure that the only thing that is obvious about a premise of universal adoption is that it's not practical. Seriously. At the least, this section needs to be less cavalier about putting this alternative forward as a "solution", especially given the rather serious drawbacks/problems with it. > 8.2. Implement DNS Whitelisting On An Ad Hoc Basis > > If DNS whitelisting is to be adopted, it is likely to be adopted on "is to be"? I thought it already had a significant installed base. > this ad hoc, or domain-by-domain basis. Therefore, only those > domains interested in DNS whitelisting would need to adopt the > practice, though as noted herein discovering that they a given domain > has done so may be problematic. Also in this scenario, ad hoc use by > a particular domain may be a temporary measure that has been adopted > to ease the transition of the domain to IPv6 over some short-term > timeframe. > > 8.3. Do Not Implement DNS Whitelisting > > As an alternative to adopting DNS whitelisting, the Internet > community generally can choose to take no action whatsoever, > perpetuating the current predominant authoritative DNS operational > model on the Internet, and leave it up to end users with IPv6-related > impairments to discover and fix those impairments. > That is, place the burden of fixing a problem on those creating it? > > > > > Livingood Expires August 26, 2011 [Page 23] > > Internet-Draft IPv6 AAAA DNS Whitelisting Implications February 2011 > > > 8.3.1. Solving Current End User IPv6 Impairments > > A further extension of not implementing DNS whitelisting, is to also > endeavor to actually fix the underlying technical problems that have > prompted the consideration of DNS whitelisting in the first place, as > an alternative to trying to apply temporary workarounds to avoid the > symptoms of underlying end user IPv6 impairments. A first step is > obviously to identify which users have such impairments, which would > appear to be possible, and then to communicate this information to > end users. Such end user communication is likely to be most helpful > if the end user is not only alerted to a potential problem but is > given careful and detailed advice on how to resolve this on their > own, or where they can seek help in doing so. Section 11 may also be > relevant in this case. > > 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. This 'challenge' is at the core of /all/ adoption efforts for Internet protocols and services that entail distributed adoption. > Despite any potential challenges, many in the Internet community are > already working towards this goal and/or have expressed a general > preference for this approach. If this is not already an organized effort with a website, sponsoring consortium, or the like, it should be. If it is, then cite it in this doc! > > 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. I do not understand what this means. What is it for? What are the results? How are theyused? > 9. Is DNS Whitelisting a Recommended Practice? > > Opinions in the Internet community concerning whether or not DNS > whitelisting is a recommended practice are understandably quite > varied. However, there is clear consensus that DNS whitelisting is > at best a useful temporary measure which a domain may choose to If that is a clear consensus, then it makes even less sense to promote the idea of universal adoption, given the timescale needed to achieve it. > 10. Security Considerations > > There are no particular security considerations if DNS whitelisting > is not adopted, as this is how the public Internet works today with A > resource records. Or rather, failure to adopt a mechanism like this or repair the underlying problem, for those sites experiencing that problem, will result in a denial of service, albeit not an intentional one. Still, that's a pretty basic security issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564C1E06EF for ; Mon, 2 May 2011 08:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyNGtDl+dx9b for ; Mon, 2 May 2011 08:59:13 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 845A1E06CB for ; Mon, 2 May 2011 08:59:13 -0700 (PDT) Received: from subman.elandsys.com ([41.136.239.73]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p42FwvYq020964; Mon, 2 May 2011 08:59:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1304351945; bh=25Nz+bT38PMyvQ2Aj28ysk3G+8k=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=FLyS99nggpI6ncBSjLUSry+sr0TOvRqggylmM+o3Uh6eIc1tnEPvd4ijq1iH+BzIk 0YBFkbI5/QB07vYyOnYqe9WEVupAsDzrYP1phT2+4JB/MqyBOXR2HuueFPuOznGWT8 2G4Q53CkAlZjxnO+G075W+j0LsNvQyfkpIxIKaBw= Message-Id: <6.2.5.6.2.20110502084902.05311de0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 02 May 2011 08:52:07 -0700 To: Dave CROCKER From: SM In-Reply-To: <4DBEBD8D.1080209@bbiw.net> References: <4DBB4A83.7010408@dcrocker.net> <6.2.5.6.2.20110430123750.02f98dd0@resistor.net> <4DBEBD8D.1080209@bbiw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2011 15:59:14 -0000 Hi Dave, At 07:19 02-05-2011, Dave CROCKER wrote: >>I have this document on the list of assignments to be made. I generally avoid >>doing a review of a document on which I have previously commented. Would you >>like to take on the assignment? > >ok. Thanks. BTW, I made a mistake and copied my previous message to ietf@ instead of apps-review. Best regards, -sm