Subject: [v6ops] Fwd: I-D Action:draft-kawamura-ipv6-isp-listings-01.txt

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 09 Dec 2010 11:49:00 +0900

This draft was discussed at Maastricht (thanks to Fred and Kurt
for giving me valuable v6ops time to present this) and from what
I recall, most people in the room either thought this should
be v6ops work, or it should be left independent but the WG
should provide input.

Many changes have been made to reflect comments
provided at the Maastricht meeting. Ed Jankiewicz is
now coauthor of this draft.

We appreciate your comments, suggestions. Thanks!

Regards,
Seiichi

- -------- Original Message --------
Subject: I-D Action:draft-kawamura-ipv6-isp-listings-01.txt
Date: Wed, 08 Dec 2010 18:30:01 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : A Basic Guideline for Listing ISPs that Run IPv6
	Author(s)       : S. Kawamura, E. Jankiewicz
	Filename        : draft-kawamura-ipv6-isp-listings-01.txt
	Pages           : 7
	Date            : 2010-12-08

There are many web sites that list IPv6 enabled service providers, or
attempt to categorize the IPv6 capability of ISPs.  While these
opinions are helpful, there is no standard criteria used by the
sites, so it is difficult to compare the results.  This document
surveys current listings, and proposes a set of guidelines that could
be taken into consideration by theses sites, or by anyone looking to
evaluate an ISP's IPv6 capability.  This guideline can also be used
as a checklist by ISPs planning activation of IPv6 in their network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kawamura-ipv6-isp-listings-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Thu, 9 Dec 2010 15:16:31 +0000

I've reviewed this document, and I think some clarifications are necessary
on your requirements: 

For example, not all ISPs will provide MX services for their customers, so
unless you're simply referring to being able to send email to
[email-masked], this might not be a valid requirement in every case.
Therefore some language to make it clearer as to which you are expecting
would be helpful.

Also, regarding "prefix is visible in at least [one|two] routing
database(s)" please clarify what you mean by this. If you are referring to
things like RADB and the RIPE or APNIC whois RPSL data, keep in mind that
not all ISPs participate in this, nor is it actually a requirement for
functional IPv6 service. If you are simply referring to the prefix being
visible in the DFZ routing table via one or more public looking
glasses/route servers, you should say this instead. 

In your advanced section, "Full support for IPv6 services comparable to
support for IPv4 Services..." is very general and not overly helpful as a
means to differentiate basic from advanced. How do you define comparable?
Complete parity? All but a few services? This shouldn't be a judgment call,
it should be objective guidelines. You say full parity earlier in your
section, but that conflicts with your statement here. Further, you would
also do well to recommend methods to verify some of the items such as
"...MUST be available to all customers by default" - how do you verify "by
default" ? ISP-provided documentation? A test customer, "secret shopper"
style?

Finally, I think that 3.6 is correct in that the requirements are going to
be different for each type of ISP. I would also add mobility to the list as
a separate type. However, I think that this document is of very limited
usefulness if it simply sticks to basic common requirements. My
recommendation would be to take the basic requirements and specify that they
are common among all ISPs, and then the advanced requirements should be
specified for the common different types of IPSs, especially since your
advanced requirements are very light at the moment.

Thanks, 
Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Seiichi Kawamura
> Sent: Wednesday, December 08, 2010 9:49 PM
> To: [email-masked]
> Subject: [v6ops] Fwd: I-D Action:draft-kawamura-ipv6-isp-listings-
> 01.txt
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
> 
> iEYEARECAAYFAk0AQ5wACgkQcrhTYfxyMkIlBgCfalwSN/biKG1vfQ7Oo0EuchNG
> uFQAn0ufhnkCcqYKZesOEcAA/jkBY8Mr
> =K1Nh
> -----END PGP SIGNATURE-----
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ed Jankiewicz <[email-masked]>
Date: Thu, 09 Dec 2010 11:09:21 -0500

We added the text on "Advanced" just before we submitted the rev, and we 
should have made it clear that it was a placeholder and more of a 
conversation starter.  Most people would agree that "parity with IPv4 
service" is an admirable goal but needs to be specified clearly to be a 
testable achievement.  We are very open to suggestion and contribution 
in this area.

"available to all customers by default" was intended to mean that no 
special request for IPv6 service would be required - plug in IPv6 
capable CPE and host, and (whoomp!) there it is.  Unlike a trial or 
limited deployment depending on customer opt-in or limited locations.  
Perhaps "available to all customers without a special request for IPv6" 
is closer to the intention.

Also, we should consider staged roll-out to service areas, i.e. the 
Metropolis service area may have "Advanced" IPv6 service while 
Smallville and other markets just have "Experimental".  What do we say 
about the ISP as a whole?

May be splitting hairs here, but we were trying to distinguish 3 points 
along the spectrum from "good luck, have fun - experimental IPv6" to 
"full production supported IPv6 service" with some intermediate point 
called "basic service".  One could argue that anything less than 
full-production support with parity to IPv4 service is not really 
"IPv6-ready" but at this time it is useful to recognize movement along 
this capability curve.  Even the experimental and trial deployments are 
important right now.

Thanks for your comments in general, and we appreciate your input.  
Seiichi and I will respond to the rest of your comments or address them 
in the next rev when we get a chance to discuss them.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]