[175573] in North American Network Operators' Group
A translation (was Re: An update from the ICANN ISPCP meeting...)
daemon@ATHENA.MIT.EDU (David Conrad)
Thu Oct 23 23:11:32 2014
X-Original-To: nanog@nanog.org
From: David Conrad <drc@virtualized.org>
Date: Thu, 23 Oct 2014 19:27:03 -0700
To: North American Network Operators Group <nanog@nanog.org>
In-Reply-To: <54497E03.5020207@nic-naa.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_9D440FBC-0287-412F-8FC3-088997FF5837
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hi,=20
While I'm sure most of the folks on NANOG are fully aware of the myriad =
of acronyms and Byzantine structures in the ICANN universe (:)), I =
thought some translation for those not inoculated with ICANNese may be =
helpful:
On Oct 23, 2014, at 3:15 PM, Eric Brunner-Williams <brunner@nic-naa.net> =
wrote:
> some history.
>=20
> at the montevideo icann meeting (september, 2001), there were so few =
attendees to either the ispc (now ispcp) and the bc (still bc),
Translated:
At a meeting in Uruguay in 2001 (one of the 3 times per year meetings =
ICANN holds all over the world in accordance with its Bylaws requirement =
to be a global organization and/or the desire of those who came up with =
the Bylaws to have many fine lunches and dinners in exotic places), very =
few people attended the working group meetings purportedly chartered for =
the interests of ISPs (the "ISP Constituency" or ISPC) and the meetings =
purportedly chartered for typically e-commerce related business =
interests (the "Business Constituency" or BC). =20
For those interested and/or who have morbid curiosity, both of these =
constituencies have their own web pages:
ISPCP: http://ispcp.info
BC: http://www.bizconst.org
The parentheticals note the ISP Constituency was renamed to the "ISP and =
Connectivity Provider" Constituency (ISPCP) and the Business =
Constituency is still named the BC. I do not know for sure what the =
rationale was behind the renaming (I'm guessing it was to increase the =
number of folks the Constituency would be relevant to).
> that these two meetings merged.
You could see this either as a desire to have something like a "joint =
working group meeting" in IETF parlance or a desire to have a few people =
in a single room instead of a couple of people in two rooms to try to =
avoid awkwardness (in my experience, the ISPCP meetings are not =
particularly well attended -- this may have changed: I haven't been in a =
while. I can't comment on the BC meetings since I've never been.)
> at the paris icann meeting (june, 2008) staff presented an analysis of =
the voting patters of the gnso constituencies
GNSO: Generic Names Supporting Organization, the folks who care =
sufficiently deeply about generic top-level domains to go to places like =
Montevideo and Paris for a week to scream past... err... reach consensus =
with other individuals who care deeply about generic top-level domains.
The GNSO is made up of a bunch of Constituencies, of which the ISPCP and =
BC are two. There are more.
There are two other Supporting Organizations, the ccNSO for country code =
TLDs and the ASO, the Addressing Supporting Organization, made up of =
folks elected by the RIRs.
> -- to my non-surprise, both the bc and the ispc votes (now ispcp) =
correlated very highly with the intellectual property constituency,
Yet another GNSO Constituency: the Intellectual Property Constituency =
(IPC), focused on trying to protect the interests of Intellectual =
Property Rights owners in the areas ICANN touches. =20
IPC: http://www.ipconstituency.org
I think it safe to say that much (but not all) of the warfare that goes =
on at ICANN meetings is between the folks interested in protecting IPR =
(in this context, trademarks) and folks interested in selling oodles of =
domain names.
> and unlike that constituency, originated very little in the way of =
policy issues for which an eventual vote was recorded.
I am, in fact, unaware of any policy issues originated out of the ISPCP =
or BC (but again, I'm not too familiar with these groups). =46rom a =
purely technical policy perspective, this may be considered to be ... =
unfortunate. That is, many of the folk on this mailing list undoubtedly =
have a view on what ICANN does yet those views are not relayed in a way =
the ICANN community can hear.
> in other words, the bc and ispc were, and for the most part, imho, =
remain captive properties of the intellectual property constituency.
Here, Eric is suggesting the intellectual property folks are driving =
policy issues on behalf of the folks interested in security/stability of =
e-commerce and as well as ISPs and connectivity providers. I have no =
reason to doubt Eric's opinion as I've not been involved enough in that =
part of ICANN and he has.
> this could change, but the isps that fund suits need to change the =
suits they send, the trademark lawyer of eyeball network operator X is =
not the vp of ops of network operator X.
Indeed, and I must commend Warren and Eric for caring enough to actually =
engage in this stuff. While many people in the NANOG/IETF/DNS Operations =
communities complain about the latest abomination ICANN is inflicting =
upon the world, there aren't a whole lot of folks from those communities =
who take the (non-trivial) amount of time to try to understand and =
address the situation. While I fully understand the rationales for not =
participating, the lack of strong representation from the technical =
community does not help in preventing abominations.
> meanwhile, whois, the udrp, and other bits o' =
other-people's-business-model take up all the available time.
UDRP: The "Uniform Domain Name Dispute Resolution Policy" (I do not know =
why it isn't referenced as the UDNDRP or "udden-drip"). This is the =
mechanism by which people who believe a domain name is being used =
abusively can attempt to have that abuse stopped. Folks who have been =
through UDRP disputes can comment on their view of its effectiveness.
Examples of "other bits o' other-peope's-business-model" might include =
stuff like how to improve accuracy in the registration databases so =
anti-abuse folks can have more hope finding spammers or how =
culturally/liguistically-identical-but-represented-by-different-Unicode-gl=
yphs strings can be deployed as new top-level domains (by analogy, =
imagine if the DNS was not case insensitive for LDH labels and the 'fun' =
that would occur if different organizations were allowed to sell names =
out of the two different TLDs, ".com" and ".COM"). Or, if you want =
something outside of the DNS, what ICANN should do about the RPKI =
"global trust anchor", i.e., whether the RPKI tree should be a =
singly-rooted tree originating at IANA as indicated by the IAB or a =
forest of 5 (or 6) trees originating at each of the RIRs (plus IANA) as =
the RIRs would appear to prefer at this time. =20
If you've read this far, you might worry about your own sanity... :).
Regards,
-drc
(ICANN CTO, but speaking only for myself)
--Apple-Mail=_9D440FBC-0287-412F-8FC3-088997FF5837
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJUSbj3AAoJENV6ebf0/4rXKd8H/jLCrBVY0I6a1y/m4Z4v8kf8
k4Gy9RMIG8KYb1QSJ7b39MT7X8DdQ2HnjU/nfCH+/ChidTlzyhGCmAqTfQhnZOyF
FaIt1lOqulDVkU5w4VEaAfQ03nV7cqbNnjFZyisfRswYJtnHnJ0J4kDtCqVJTruc
Gm9ICTODSX33D2bghbg2Q+QA+tALXJI2mD/zBdtFg1Kd8QyKnCzr244JsCrhbTMy
bZqXT+BL113CGAijTW+XZBK8v0oJtnowN5Cn30znPIgXmWhqDtgcnjk31UZ2Pw6D
pGZy5sjINFV8tgg9UtUPZ30S44M7ouqJz4EQ0HF+HZe/kWBeEWgCAXqk0nvidB0=
=anMe
-----END PGP SIGNATURE-----
--Apple-Mail=_9D440FBC-0287-412F-8FC3-088997FF5837--
