Dear all, First of all, is there is real definition of PIC universally agreed by all parties. Since most of PICs are established based on Voluntary commitment, how seriously we should discuss and analyze them, taking into account the severe time constrains? It is good to see some many valuable remarks on the pics but without narrowing down the path to move toward a possible consensus. Almost all arguments are valid based on the way that their author understands the meaning and scope of application of PICs by the Board and the observance of the promised commitment . Where we are going from here? Regards Kavouss 2016-01-16 20:59 GMT+01:00 Eric (Maule) Brunner-Williams < ebw@abenaki.wabanaki.net>:
But Eric is probably wrong, even if this academic anyway.
Of course, but lets find out what the specific error is.
RFC 1591 is VERY clear on substantial misbehavior, probably only during the app lication phase, but most certainly also during tue application phase (as interp reted by the FoI Principles).
Jon submitted to Joyce the draft that was published as 1591 in the Winter of 1993-1994.
At the moment, in the ccwg-acct list, the subject under discussion appears to me to be the enforcement of agreements contained in, or arising from, those delegations made after 1998, which were not made because of existing, or new allocations of iso3166-1 code points by the iso3166/MA.
I do not recall Staff (that would be Louis) reliance upon 1591 when selecting 6-10 of the 41 new gTLD applications submitted to the Corporation in 2000, several of which I contributed to, and while tangential, when .us was transfered from the IANA to another operator, the NTIA did not take note of conditions existing during the IANA management period which were difficult to reconcile with the plain reading of 1591, which were continued after transition to another operator, and continue to the present.
Similarly, I do not recall Staff (that would be several people, not just Louis) reliance upon 1591 when evaluating the 2004 sTLD applications, though of course the application for .cat was made with the plain reading of 1591 in mind. There was significant public comment on the next best 2004 application, which I'm confident Becky recalls -- I don't recall the issue of 1591 among the major critiques of the .xxx application.
I'm confident that there are others contributing to the list who were involved in one or more applications in the 2010 round, and can offer their recollection of the import of 1591 language, section 2 in particular, in framing their application and any subsequent offers of conditions such as PIC statements. Of the linguistic and cultural and/or municipal and/or regional applications I contributed to or was informed of, as with the .cat application, these were made with the plain reading of 1591 in mind.
I infer from your statement that my error lies in failing to discern the import of 1591 in the 2000 and/or 2004 and/or 2010 and/or subsequent, if any, processes which resulted in, or are likely to result in, delegations by the IANA function operator.
Never mind that i would be surprised that misrepresentations during the applica tion could not be sanctioned after delegation (in the agreement) ICANN could us e, in my view, RFC 1591 before execution of the agreement.
There is the history of .travel, and .pro, to name just two frequently mentioned over the past decade and a half, or more generally, the weakness of the compliance portion of the Corporation, whether directed at registrars, or at registries. However, as I understand it, the subject under discussion appears to me to be the enforcement of agreements contained in, or arising from, those delegations, with the past accomodated by "grandfathering" language, so the core issue is prospective enforcement, where the Applicant Guidebook is the primary source of authority, not 1591.
Eric Brunner-Williams Eugene, Oregon _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community