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

[Tim Chown <[e-mail]>]

On 13 May 2011, at 07:35, Fred Baker wrote:

> 
> On May 2, 2011, at 11:38 AM, George, Wes E [NTK] 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
>> 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?

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