A translation (was Re: An update from the ICANN ISPCP meeting...)

Fri Oct 24 02:27:03 UTC 2014

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 <brunner at 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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20141023/920e5438/attachment.sig>