Hi, 

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 <brun...@nic-naa.net> wrote:
> some history.
> 
> 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).  

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.  

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). From 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-glyphs 
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.  

If you've read this far, you might worry about your own sanity... :).

Regards,
-drc
(ICANN CTO, but speaking only for myself)

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to