Subject: Re: [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D

From: Ray Hunter <[email-masked]>
Date: Wed, 20 Jul 2011 10:14:18 +0200

I have read this updated document  
(draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06)

I have no substantial comments on content, and support the reorganized 
structure.

Neither of the following two minor comments should be considered any 
reason to delay the draft if they can't be honored or incorporated.

1. Is it worth mentioning the risk to CGN on de-whitelisting in 7.3.1? 
These are expensive devices with potentially limited capacity. There has 
also been a desire expressed by some providers on the v6ops list to be 
able to reduce IPv4 traffic gradually over time, so that IPv4 and CGN 
can be turned off in a controlled manner.

Suggestion:

s/IPv4 network links/IPv4 network links and devices, especially those facilitating the IPv4 to IPv6 transition,/

2. suggest relocating the entire paragraph containing the example in 4.2 
"In this case, a DNS recursive resolver operator expressed a short-term 
concern that their IPv6 network infrastructure was not yet ready to 
handle the large traffic volume that may be associated with the hosts in 
their network connecting to the websites of these domains." as-is to 
section 4.1 volume based concerns.

regards,
RayH
> Subject:
> [v6ops] Feedback on latest v6-aaaa-whitelisting-implications I-D
> From:
> "Livingood, Jason" <[email-masked]>
> Date:
> Mon, 18 Jul 2011 20:38:12 +0000
>
> To:
> "[email-masked]" <[email-masked]>
>
> Precedence:
> list
> MIME-Version:
> 1.0
> Message-ID:
> <[email-masked]>
> Content-Type:
> multipart/alternative; 
> boundary="_000_CA4A11FC2FF89jasonlivingoodcablecomcastcom_"
> Message:
> 2
>
>
> Since this document achieved rough consensus and passed WGLC in v6ops, 
> it went on to IESG and IETF review. The IESG asked for a number of 
> changes, including that some sections be reorganized to better present 
> the information in the document. In addition, sections attempting to 
> describe the motivations of implementers was also expanded (such as 
> Section 4.1 on volume-based concerns at 
> http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.1, 
> plus Section 4.3 at 
> http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-4.3). 
>
>
> I believe that overall this had the effect of improving the document. 
> /Nevertheless, the WG chairs and I feel it is appropriate to have the 
> WG look at this document again to see if there's additional feedback 
> based on the updated document. /To this end, I'm on the WG agenda on 
> 26 July and ask for any additional feedback 
> (http://www.ietf.org/proceedings/81/agenda/v6ops.html).
>
> The latest document is available at: 
> http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06
>
> One note for the next --07 update (per the request of an IESG member):
> - Possibly remove the last sentence of Section 5.1 
> (http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-06#section-5.1). 
> That sentence was suggested by one IESG member and another had 
> concerns with that. So I'm trying to sort through that now (I've 
> suggested removing the last sentence).
>
>

> Regards,
> Jason

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Jul 2011 17:46:46 +0900

-1, still.

Section 4.3 seems like fluff; I hadn't noticed that bit before.

The second paragraph of section 3.2 seems irrelevant.

The conclusion at the end of section 3.2 that whitelisting represents some
form of access control is still completely wrong.  What CDNs do is not about
geography: it's about client experience.  AAAA policy is fundamentally no
different.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 20 Jul 2011 13:05:04 +0000

On 7/20/11 4:46 AM, "Erik Kline" <[email-masked]<mailto:[email-masked]>> wrote:

-1, still.

[JL] I added Section 4.3 following a conversation with Milo at Google (at a BITAG meeting in Boulder a couple months ago). If you guys don't feel it is important, I'm happy to remove it — it was solely intended to better help folks understand the position that content providers like Google, Yahoo, Microsoft, and others are under. The key thing Milo was trying to get across was that when a service is free, if there's an issue (such as an IPv6-related impairment) someone can just easily switch to a competing service, whereas if it was a paid service the end user is more likely to call the provider to sort through the issue and less likely to switch to a competitor.

[JL] Let me know what you'd like to do here — this was just intended to better explain concerns and motivations of domains that whitelist.

[JL] I think that was a suggested paragraph by someone in the WG and am happy to remove it if the WG wishes. I will add this to the list of questions I raise with the WG next week to get a sense of the room, but if people are okay removing that paragraph, please say so here.

The conclusion at the end of section 3.2 that whitelisting represents some form of access control is still completely wrong.  What CDNs do is not about geography: it's about client experience.  AAAA policy is fundamentally no different.

[JL] I don't disagree with you that whitelisting is about the client experience in one sense. But certainly whitelisting controls access to AAAA RRs, which means it is a form of policy or access control (to records).

- Jason

---

From: Erik Kline <[email-masked]>
Date: Wed, 20 Jul 2011 23:08:32 +0900

> [JL] I don't disagree with you that whitelisting is about the client
> experience in one sense. But certainly whitelisting controls access to AAAA
> RRs, which means it is a form of policy or access control (to records).
> - Jason

That's really not how it read.  That seems awfully...I don't know
what.  The implication of a phrase like "access control", in this
general context, to me seems like controlling access to the content.
This clearly sounds like the kind of thing that would invite legal or
regulatory investigation, as some of your other documents have
intimated.

I haven't read the latest version of your same document for BITAG yet.
 Does it contain similarly potentially misleading language?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 20 Jul 2011 17:14:56 -0700

> RRs, which means it is a form of policy or access control (to records).

Whitelisting is not a form of access control. It is a way of improving the
performance and reliability of a service.

In the same way that major websites can return IP (v4 or v6) addresses of
servers that are geographically close to users to offer the best
performance, they can choose not to return IPv6 addresses to users that will
have performance or reliability problems (e.g., broken IPv6).

In both cases, the resource that is requested (e.g., a HTTP URL) is
available regardless of where the server is or what protocol family is used.
So "access control" is not an appropriate description. It should be removed
from the document.

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jul 2011 21:15:25 -0400

On Jul 20, 2011, at 8:14 PM, Lorenzo Colitti wrote:

> On Wed, Jul 20, 2011 at 6:05 AM, Livingood, Jason <[email-masked]> wrote:
> Whitelisting is not a form of access control. It is a way of improving the performance and reliability of a service.

I agree that "access control" is a misleading description of the effect of whitelisting.   Jason, I think I understand why you want to call it that.   But use of the term "access control" in that way is likely to convey the wrong impression.

Keith