Subject: [v6ops] draft-chown-v6ops-call-to-arms WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 1 May 2011 11:00:06 -0700

This is to initiate a two week working group last call of draft-chown-v6ops-call-to-arms. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 2 May 2011 18:38:34 +0000

Overall, I think that this document is quite good. My main concern is that even between now and June, it really should be a living
document rather than the static document that an IETF draft that moves towards RFC becomes. 
If it is meant to aggregate some of this info for the wider audience that sometimes sees IETF drafts, I might recommend adding
informative references to locations where more info is available and it is likely to be continually updated, such as ARIN’s
getipv6.info website, RIPE’s IPv6actnow.org, etc I’m sure that there are others, but I think you get the idea. Might also make sense
to include a reference to any wiki that ISOC is working on in preparation for the day as well. 
For example, http://getipv6.info/index.php/Customer_problems_that_could_occur has a good set of common issues and problems that
would make a nice companion to section 2.

In section 3, you might want to break instrumentation up into two categories, one for those enabling IPv6 on content sites and
another for those who have IPv6-enabled networks, as the instrumentation may be a good bit different for each, but having both types
of data will be very important. Right now, the reference to "particularly useful if your site is turning on AAAA records..." makes
it seem like the operator perspective (what worked, what didn't, who called and why) is less useful, when in reality that may turn
out to be much more useful data in aggregate. I see that you briefly cover this in 3.6, but that section is pretty light in terms of
ideas on how to categorize things, the right questions to be asking, etc. Think of it in terms of operators needing to prepare their
front-line customer service techs for this date - what do they need to know, what should they ask, track, etc?
Overall, I would think that this section would be most valuable if it proposes a minimum set of data that is important plus
additional "nice to have" info, along with some format recommendations so that eventually people can do more in-depth research and
analysis of the data available across many different organizations. 

One specific nit, sections 2.2 and 2.4:
I wonder about referring to specific tunnel brokers, even as examples, rather than making a more generic reference to something
like: http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers  (or another more robust wiki that lists more than 3) in lieu of
explanation as to what a tunnel broker is and does.
Then in the section on PMTUD (2.4), again there’s a specific reference to HE and Sixxs that I’m not sure adds value compared with
saying that “it’s good practice for tunnel brokers to set their MTUs to default to 1280, probably due to…”

Thanks

Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Sunday, May 01, 2011 2:00 PM
To: [email-masked]
Cc: [email-masked]; Ron Bonica
Subject: [v6ops] draft-chown-v6ops-call-to-arms WGLC

This is to initiate a two week working group last call of draft-chown-v6ops-call-to-arms. Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing
with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important comment to make.

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 May 2011 23:35:47 -0700

> document rather than the static document that an IETF draft that moves towards RFC becomes. 

Question for Stig and Tim, and anyone else that wants to chime in. The authors will do another update to incorporate the few (but detailed) comments we have received during WGLC. From my perspective, I don't see a problem with holding off until June to file it with Ron.

But - what would the objective be? It seems like the purpose of holding it off is either to add new things to test, or to report on the testing. Tim, Stig, others? What do you want to see happen here?

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 12 May 2011 23:48:01 -0700

On 5/12/11 11:35 PM, Fred Baker wrote:
>> Overall, I think that this document is quite good. My main concern
>> is that even between now and June, it really should be a living 
> Question for Stig and Tim, and anyone else that wants to chime in.
> The authors will do another update to incorporate the few (but
> detailed) comments we have received during WGLC. From my perspective,
> I don't see a problem with holding off until June to file it with
> Ron.
> 
> But - what would the objective be? It seems like the purpose of
> holding it off is either to add new things to test, or to report on
> the testing. Tim, Stig, others? What do you want to see happen here? 

putting it a different way, do we expect material improvement with age?

> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 May 2011 11:45:41 +0100

> But - what would the objective be? It seems like the purpose of holding it off is either to add new things to test, or to report on the testing. Tim, Stig, others? What do you want to see happen he…

I would be perfectly fine with it being a 'living document' for the foreseeable future.   From discussion with Stig last week, I believe he shares the same view.  We also have a third author contributing material.

The idea was simply to have a place at which to point people - with a focus on administrators at end sites - to become more aware of some common connectivity issues they may see and some ways to measure the performance of clients attempting to reach their sites.   If that place is a draft not an RFC, it doesn't make the text any less useful, and as Wes suggests, we can make quick updates right up to the day if it's deemed useful/necessary.

It might be useful beyond June 8th if it becomes more the text that Ray is hinting at, for general connectivity gotchas for dual-stack sites.  For example we ran into another one recently during the IETF's test of its 'mirror' facilities. The duplicate IETF mail servers didn't have reverse IPv6 DNS, so our dual-stack mail servers rejected the mails, and after a few days I dropped off some lists.  The IETF ops people were really helpful in sorting it out, but the interesting thing was that the servers didn't - as far as I can determine - drop back to IPv4 transport; they kept retrying over IPv6.

Tim

---

From: Fred Baker <[email-masked]>
Date: Fri, 13 May 2011 09:40:35 -0700

> I would be perfectly fine with it being a 'living document' for the foreseeable future.   From discussion with Stig last week, I believe he shares the same view.  We also have a third author contri…

In that case, the WGLC was premature. Thanks, we'll just let it ride.

> It might be useful beyond June 8th if it becomes more the text that Ray is hinting at, for general connectivity gotchas for dual-stack sites.  For example we ran into another one recently during th…

Interesting. I presume you'll discuss that in the updated draft.