[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-kawamura-ipv6-isp-listings-00.txt



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Kurt

Thanks for the review

Lindqvist Kurt Erik wrote:
> I have read the above documents and have some general comments and then some more nit like comments.
> 
> General comments: 
> -----------------
> 
> In general it might be good with a document outlining some basic checklists to determine 
> the level of IPv6 readiness in a service provider. However, I doubt the value
> of listing some of the current programs and what methodology they are currently using.
> These change, and keeping the document uptodate so it's meaningful might be hard and
> of little value.

I agree. The lists on this draft are noted here for reference and starting a discussion.
If this were to be an RFC, its not much worth listing them on the document.

> Now, that type of measurement is not the same type of checklist / certification 
> program as the I-D describes, but this brings me to what I believe is the
> biggest flaw of section 3 - it doesn't say much about actual deployment. ]
> Rather, the barrier is very low. For example in 3.3 it mentions an
> allocated or PI block. If this is for an ISP, a PI block is useless as the intention
> of PI is to not suballocate. I would set the requirement to PA bock only.

Good point. I agree with this.

> Further - I believe the Basic class described in 3.3 should at least require 
> sub-allocations of IPV6 prefixes, otherwise it's hard to argue that an ISP
> has 'deployed' IPv6. As for the Advance class in 3.4, I would suggest that an

Also agree here.

> ISP provides more than basic services (i.e DNS) over IPv6 to end-users and/or the Internet in general. 

Agree also.

> Still, while I am somewhat agreeing with a standardized measurement of IPv6 readiness in an 
> AS/ISP I think that it's more useful to work on measuring actually deployed
> clients that can be observed and publishing that data. Even better would be
> standardized quality measures of these deployments. There are many drawbacks
> on doing this based on only observed data at a server side ala looking at
> a web-server, but as Lorenzo and Google have shown in many presentations,
> at least it gives data to do a risk assessment for a service operator.

I think that would be interesting work too.

What I hear from small ISPs these days is
that they want a minimum list of things to do to be
able to communicate with the IPv6 world.

Bringing an ISP to be fully dual stacked will take years.
I think a minimum guideline would be useful (is there one out there already?), and
if these lists would measure readiness according to
minimum guidelines that would be even better.

> If this document could combine some level of Basic recommendations along the lines of
> "Have PA, hvae done X sub-delegations, provides Y services" together with a standard
> collection mechanism/schema (perhaps that is really a different document) similar to
> what RIPE does, what Google does, or even better- a format or method that would allow
> sharing of data, content/service operators could build a matrix and we could see the
> progress and quality of IPv6 deployment.

This sounds very cool. Although I admit I don't know too much about measurement.

Regards,
Seiichi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkxGZDAACgkQcrhTYfxyMkKXDgCfUcAIThjMhLBSKXjK/D7qW2TP
xaEAnieR+/7XH/+abJt9ApPjSJvLlLQf
=gsgG
-----END PGP SIGNATURE-----