Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 22 Nov 2011 13:08:58 +0000

Thanks for the feedback, Wes. See comments inline below. This will all be in a –08 shortly.

- Jason

On 10/14/11 12:30 PM, "George, Wes" <[email-masked]<mailto:[email-masked]>> wrote:

Section 4 – I’m not sure I’d call these “transition techniques” – they are really more methods to resolve or reduce the risk of impaired IPv6 connectivity. Transition techniques is unfortunately a pretty overloaded term right now, but usually refers to methods to enable IPv6 capability, especially in the case where one or more elements in the path don’t properly support IPv6, rather than to manage impairment, and I think this will cause confusion.

Ack. Changed to "Potential Migration Tactics".

4.2/5.2 – might call these protocol (or address-family)-specific FQDNS instead of IPv6 transition names. Again, transition is sort of an overloaded term.

Ack. Changed in the text to use 'address-family-specific names' and in the title as using 'IPv6-Specific Names'.

I think this document is remiss in not mentioning Happy Eyeballs as another method to prevent end-user impact due to impaired IPv6 connectivity.

Ack. This reference has been added.

4.4 – you say “It is unclear
   when and if it may be appropriate for a domain to change from
   whitelisting to blacklisting.  Nor is it clear how implementers will
   judge the network conditions to have changed sufficiently to justify
   disabling such controls.”
I’m concerned with leaving it at that. This is a good place to put in a warning that these, especially whitelists, should not be considered an open-ended deployment, and that before deploying blacklist/whitelist, content providers/domain owners should have concrete criteria and means for consistently (if not continuously) testing those criteria so that it is clear when the risk of impairment has dropped below their threshold and this can be removed. In other words, I would like us to say “black/whitelisting shouldn’t be used for longer than is necessary” while still acknowledging that everyone has a slightly different value of necessary.

I understand your concern and have previously attempted more direct language on the duration of these migration tactics. But ultimately the WG, especially in consultation with implementers, was not able to reach consensus on anything beyond the text in 4.4. I am comfortable with it as-is with the consensus position.

Thanks
Jason

---

From: "George, Wes" <[email-masked]>
Date: Tue, 22 Nov 2011 14:05:36 -0500

From: Livingood, Jason [mailto:[email-masked]]
Sent: Tuesday, November 22, 2011 8:09 AM
To: George, Wes; [email-masked]
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
4.4 - you say "It
is unclear
   when and if it may be appropriate for a domain to change from
   whitelisting to blacklisting.  Nor is it clear how implementers will
   judge the network conditions to have changed sufficiently to justify
   disabling such controls."
I'm concerned with leaving it at that. This is a good place to put in a warning that these, especially whitelists, should not be considered an open-ended deployment, and that before deploying blacklist/whitelist, content providers/domain owners should have concrete criteria and means for consistently (if not continuously) testing those criteria so that it is clear when the risk of impairment has dropped below their threshold and this can be removed. In other words, I would like us to say "black/whitelisting shouldn't be used for longer than is necessary" while still acknowledging that everyone has a slightly different value of necessary.

[WEG] For clarification, I'm not suggesting that you recommend a timeline/duration, and I'm not surprised that you were unable to obtain consensus on that. I fully agree that everyone's timeline is going to be different. My problem is with the fact that this simply states "it's unclear" instead of acknowledging that everyone's timeline will be different and making a recommendation that you should re-evaluate every so often in order to determine what *your* specific timeline is - that is, when it is appropriate to change from whitelisting to blacklisting, or to eliminate blacklisting altogether. I see that the rev went out already, but  perhaps if this alternate text makes sense, you can spin a rev fairly easily:
"This document does not recommend a specific timeline to move from whitelisting to blacklisting or to completely open access. This is because each domain has different needs, customers, and other considerations that inform that decision. However, it is important to note that whitelisting might not always be an appropriate open-ended [long-term?] solution, and implementers should at least consider the quantitative metrics or criteria by which they measure the success or failure of blacklisting, whitelisting, or open access. It is good practice to periodically review those metrics to determine whether whitelisting or blacklisting is still necessary. If removing these mechanisms can be done without adversely effecting the end-user experience, it may make sense to do so, as removal is likely to reduce the complexity of the implementation."

Thanks
Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.