<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Dear all,<br>
<br>
thank you so much for all the work. This final document has my
support as either an NCUC or an NCSG position document.<br>
<br>
Nicolas<br>
NCUC, NCSG<br>
<br>
<br>
<div class="moz-cite-prefix">On 31/07/2014 2:27 PM, Stephanie Perrin
wrote:<br>
</div>
<blockquote cite="mid:53DA8AAD.5080109@mail.utoronto.ca" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Ok folks, I think we have a draft (5) which is now ready for final
approval. I have taken Kathy's last draft, done a final edit
(unfortunately I cannot restrain my editing, each time I go
through the draft, as I find things I forgot to note the last
time. So there are a few changes.) In deference to Avri's strong
objection to the mention of multistakeholderism as being
subservient to adherance to law, I did an edit of that sentence. <br>
It is unfortunate that Michele used the example of German law (as
the lander each have their own laws and Commissioners, and I am
quite unsure whose jurisdiction this issue would fall under)
however I left it in. I also tried to clarify the paragraph
where we discuss consultation on decisions regarding exemption. I
hope it is now clear and reflects all members views on the matter.<br>
Rafik, I would recommend that when you digitally sign the clean
copy you save it as NCSG comments on the WHOIS conflicts
consultation, as the current title is messy (assuming we can now
get concensus on moving forward and filing this tomorrow).<br>
Kind regards, <br>
Stephanie <br>
<div class="moz-cite-prefix">On 2014-07-31, 11:09, Kathy Kleiman
wrote:<br>
</div>
<blockquote cite="mid:53DA5C0F.9050401@kathykleiman.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">Hi Stephanie,<br>
Tx for adding Avri's comments. I've reviewed all of the
changes, and also added one more to this most recent version.
<u>Newest version (NCSGEdits3) attached. </u><br>
**Due tomorrow** <br>
Best,<br>
Kathy<br>
:<br>
</div>
<blockquote cite="mid:53DA44C7.7090700@mail.utoronto.ca"
type="cite">I also agreed with Avri and inserted a few of her
changes, Kathy did not get those edits....we need to make sure
we have a final copy that Rafik can sign, which reflects all
the agreed changes. Do you want me to have another edit one
last time, to make sure that Joy's comments (which were on an
earlier draft) and Avri's are all in there? <br>
cheers stephanie <br>
On 2014-07-31, 9:22, Amr Elsadr wrote: <br>
<blockquote type="cite">Hi all, <br>
<br>
On Jul 30, 2014, at 2:57 PM, Avri Doria <a
moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:avri@ACM.ORG"><avri@ACM.ORG></a> wrote:
<br>
<br>
<blockquote type="cite">hi, <br>
<br>
Reviewed the document. <br>
<br>
Made a change so it could be a NCSG document. <br>
</blockquote>
Thanks. <br>
<br>
<blockquote type="cite">There are parts I am uncomfortable
with, some of which I deleted and <br>
some of which I left and still am uncomfortable with. <br>
<br>
I do not think we should ever dismiss the Multistakeholder
model. I do <br>
not wish to find ourselves in the situation of being
quoted for having <br>
suggested that there are times when the model should be
superseded. That <br>
would be a gold mine for some. I deleted those
references. <br>
</blockquote>
Fully agree. Although I don’t feel that was the intent, it
could certainly be perceived that way. No need to bring it
up. <br>
<br>
<blockquote type="cite">I am also uncomfortable with saying
there are things that don't need <br>
public comment on. To just have to take the legal staff
view on things <br>
is dangerous. What if they say the law does not require
something when <br>
someone knows better. Better to have a null review. I
have not, <br>
however, removed these as they were an entire section.
I would like <br>
to see that section reworded or removed before approving
the documents. <br>
</blockquote>
IMHO, I don’t see the need for a public comment period on
every time this policy might be used. If a new set of
policies and processes are adopted for handling WHOIS
conflicts with privacy laws, then they should be clear
enough during implementation to not require public comment,
right? Isn’t this the case with all policies? For instance,
is there a public comment period every time a new registrar
signs a contract with ICANN? Or will there be a public
comment period when implementation of the “thick” WHOIS
policy kicks in? <br>
<br>
Another thought is that a public comment period will also
lengthen the period during which a registrar will
potentially be at risk for non-compliance with local laws.
Unless there is an important reason why there should be a
public comment for each of the resolution scenarios, then I
suggest we support Kathy’s recommendation to not have any. <br>
<br>
Thanks. <br>
<br>
Amr <br>
<br>
<blockquote type="cite">I also removed a bunch of weasel
words like 'respectfully' <br>
<br>
avri <br>
<br>
<br>
<br>
<br>
<br>
<br>
On 30-Jul-14 14:28, Avri Doria wrote: <br>
<blockquote type="cite">Hi, <br>
<br>
Started reviewing them, actually Stephanie's comments.
They are written <br>
from an NCUC perspective and need to be approved by
them, not us. <br>
<br>
avri <br>
<br>
<br>
On 30-Jul-14 11:36, Rafik Dammak wrote: <br>
<blockquote type="cite">Hi everyone, <br>
<br>
Kathy sent a draft comment to the whois conflict with
local laws. we <br>
have a tight schedule and we should act quickly. <br>
we are responding during the reply period which means
the last chance <br>
for us to do so. <br>
@Maria can you please follow-up with this request? <br>
<br>
Best, <br>
<br>
Rafik <br>
<br>
<br>
<br>
---------- Forwarded message ---------- <br>
From: *Kathy Kleiman* <<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:kathy@kathykleiman.com">kathy@kathykleiman.com</a>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:kathy@kathykleiman.com"><mailto:kathy@kathykleiman.com></a>>
<br>
Date: 2014-07-30 2:44 GMT+09:00 <br>
Subject: Draft Comments for Whois Proceeding <br>
To: Rafik Dammak <<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:rafik.dammak@gmail.com">rafik.dammak@gmail.com</a>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:rafik.dammak@gmail.com"><mailto:rafik.dammak@gmail.com></a>>,
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:NCSG-DISCUSS@listserv.syr.edu">NCSG-DISCUSS@listserv.syr.edu</a>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:NCSG-DISCUSS@listserv.syr.edu"><mailto:NCSG-DISCUSS@listserv.syr.edu></a>
<br>
<br>
<br>
To Rafik, NCSG Executive Committee and NCSG
Membership, <br>
<br>
There is an important, but very quiet comment
proceeding that has been <br>
taking place this summer. It is the /Review of the
ICANN Procedure for <br>
Handling WHOIS Conflicts with Privacy Law///at <br>
/<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en/">https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en/</a>
<br>
<br>
<br>
Stephanie put out a call for comments, and not seeing
any, I drafted <br>
these. It has been dismayeding ever since ICANN
adopted its Consensus <br>
Procedure for Handling WHOIS Conflicts with Privacy
law -- because it <br>
basically requires that Registrars and Registries have
to be sued or <br>
receive an official notice of violation before they
can ask ICANN for a <br>
waiver of the Whois requirements. That always seemed
very unfair- that <br>
you have to be exposed to allegation of illegal
activity in order to <br>
protect yourself or your Registrants under your
national data protection <br>
and privacy laws. <br>
<br>
In the more recent Data Retention Specification, of
the 2013 RAA, ICANN <br>
Staff and Lawyers saw this problem and corrected it --
now Registrars <br>
can be much more pro-active in showing ICANN that a
certain clause in <br>
their contract (e.g., extended data retention) is a
clear violation of <br>
their national law (e.g., more limited data
retention). <br>
<br>
So to this important comment proceeding, I drafted
these comments for us <br>
to submit. As Reply Comments (during the Reply
Period), we are asked to <br>
respond to other commenters. That's easy as the
European Commission and <br>
Registrar Blacknight submitted useful comments. <br>
<br>
Rafik, can we edit, finalize and submit by the
deadline on Friday? <br>
Comments below and attached. If you have edits, in the
interest of time, <br>
kindly suggest alternate language. Tx!! <br>
<br>
Best, <br>
Kathy <br>
--------------------------------------------------------------------------------------------------------
<br>
<br>
DRAFT NCSG Response to the Questions of the <br>
<br>
/Review of the ICANN Procedure for Handling WHOIS
Conflicts with Privacy <br>
Law// <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en/">https://www.icann.org/public-comments/whois-conflicts-procedure-2014-05-22-en/</a>
<br>
<br>
<br>
*Introduction* <br>
<br>
The Noncommercial Stakeholders Group represents
noncommercial <br>
organizations in their work in the policy and
proceedings of ICANN and <br>
the GNSO. We respectfully submit as an opening premise
that every legal <br>
business has the right and obligation to operate
within the bounds and <br>
limits of its national laws and regulations. No legal
business <br>
establishes itself to violate the law; and to do so is
an invitation to <br>
civil and criminal penalties. ICANN Registries and
Registrars are no <br>
different – they want and need to abide by their laws.
<br>
<br>
Thus, it is timely for ICANN to raise the questions of
this proceeding, <br>
/Review of the ICANN Procedure for Handling WHOIS
Conflicts with Privacy <br>
Law/(albeit at a busy time for the Community and at
the height of <br>
summer; we expect to see more interest in this time
towards the Fall). <br>
We submit these comments in response to the issues
raises and the <br>
questions asked. <br>
<br>
*Background* <br>
<br>
The /ICANN Procedure for Handling Whois Conflicts with
Privacy Law /was <br>
adopted in 2006 after years of debate on Whois issues.
This Consensus <br>
Procedure was the first step of recognition that data
protection laws <br>
and privacy law DO apply to the personal and sensitive
data being <br>
collected by Registries and Registrars for the Whois
database. <br>
<br>
But for those of us in the Noncommercial Users
Constituency (now part of <br>
the Noncommercial Stakeholders Group/NCSG) who helped
debate, draft and <br>
adopt this Consensus Procedure in the mid-2000s, we
were always shocked <br>
that the ICANN Community did not do more. At the time,
multiple Whois <br>
Task Forces were at work with multiple proposals which
include important <br>
and pro-active suggestions to allow Registrars and
Registries to come <br>
into compliance with their national data protection
and privacy laws. <br>
<br>
At the time, we never expected this Consensus
Procedure to be an end <br>
itself – but the first step of many steps. It was an
“end” for too long, <br>
so we are glad the discussion is reopened and once
again we seek to <br>
allow Registrars and Registries to be in full
compliance with their <br>
national data protection and privacy laws – from the
moment they enter <br>
into their contracts with ICANN. <br>
<br>
*II. Data Protection and Privacy Laws – A Quick
Overview of the <br>
Principles that Protect the Personal and Sensitive
Data of Individuals <br>
and Organizations/Small Businesses * <br>
<br>
** <br>
<br>
/*[Stephanie, Tamir or Others with Expertise in
Canadian and European <br>
Data Protection Laws may choose to add something
here]. */ <br>
<br>
III/*. */Questions asked of the Community in this
Proceeding <br>
<br>
The ICANN Review Paper raised a number of excellent
questions. In <br>
keeping with the requirements of a Reply Period, these
NCSG comments <br>
will address both our comments and those comments we
particularly <br>
support in this proceeding. <br>
<br>
1. <br>
<br>
Is it impractical for ICANN to require that a
contracted party <br>
already has litigation or a government
proceeding initiated <br>
against it prior to being able to invoke the
Whois Procedure? <br>
<br>
1.1 Response: Yes, it is completely impractical (and
ill-advised) to <br>
force a company to violate a national law as a
condition of complying <br>
with that national law. Every lawyer advises
businesses to comply with <br>
the laws and regulations of their field. To do
otherwise is to face <br>
fines, penalties, loss of the business, even jail for
officers and <br>
directors. Legal business strives to be law-abiding;
no officer or <br>
director wants to go to jail for her company's
violations. It is the <br>
essence of an attorney's advice to his/her clients to
fully comply with <br>
the laws and operate clearly within the clear
boundaries and limits of <br>
laws and regulations, both national, by province or
state and local. <br>
<br>
In these Reply Comments, we support and encourage
ICANN to adopt <br>
policies consistent with the initial comments
submitted by the European <br>
Commission: <br>
<br>
o <br>
<br>
that the Whois Procedure be changed from
requiring specific <br>
prosecutorial action instead to allowing
“demonstrating evidence <br>
of a potential conflict widely and e.g.
accepting information on <br>
the legislation imposing requirements that the
contractual <br>
requirements would breach as sufficient
evidence.” (European <br>
Commission comments) <br>
<br>
We also agree with Blacknight: <br>
<br>
o <br>
<br>
“It's completely illogical for ICANN to require
that a <br>
contracting party already has litigation before
they can use a <br>
process. We would have loved to use a procedure
or process to <br>
get exemptions, but expecting us to already be
litigating before <br>
we can do so is, for lack of a better word,
nuts.” (Blacknight <br>
comments in this proceeding). <br>
<br>
<br>
1.1a How can the triggering event be meaningfully
defined? <br>
<br>
1.1 a Response: This is an important question.
Rephrased, we might ask <br>
together – what must a Registry or Registrar show
ICANN in support of <br>
its claim that certain provisions involving Whois data
violate <br>
provisions of national data protection and privacy
laws? <br>
<br>
NCSG respectfully submits that there are at least four
“triggering <br>
events” that ICANN should recognize: <br>
<br>
o <br>
<br>
Evidence from a national Data Protection
Commissioner or his/her <br>
office (or from a internationally recognized
body of national <br>
Data Protection Commissioners in a certain
region of the world, <br>
including the Article 29 Working Party that
analyzes the <br>
national data protection and privacy laws) that
ICANN's <br>
contractual obligations for Registry and/or
Registrar contracts <br>
violate the data protection laws of their
country or their group <br>
of countries; <br>
<br>
o <br>
<br>
Evidence of legal and/or jurisdictional
conflict arising from <br>
analysis performed by ICANN's legal department
or by national <br>
legal experts hired by ICANN to evaluate the
Whois requirements <br>
of the ICANN contracts for compliance and
conflicts with <br>
national data protection laws and cross-border
transfer limits) <br>
(similar to the process we understand was
undertaken for the <br>
data retention issue); <br>
<br>
<br>
o <br>
<br>
Receipt of a written legal opinion from a
nationally recognized <br>
law firm in the applicable jurisdiction that
states that the <br>
collection, retention and/or transfer of
certain Whois data <br>
elements as required by Registrar or Registry
Agreements is <br>
“reasonably likely to violate the applicable
law” of the <br>
Registry or Registrar (per the process allowed
in RAA Data <br>
Retention Specification); or <br>
<br>
<br>
o <br>
<br>
An official opinion of any other governmental
body of competent <br>
jurisdiction providing that compliance with the
data protection <br>
requirements of the Registry/Registrar
contracts violates <br>
applicable national law (although such
pro-active opinions may <br>
not be the practice of the Data Protection
Commissioner's office). <br>
<br>
The above list draws from the comments of the European
Commission, Data <br>
Retention Specification of the 2013 Registrar
Accreditation Agreement, <br>
and sound compliance and business practices for the
ICANN General <br>
Counsel's office. <br>
<br>
We further agree with Blacknight that the requirements
for triggering <br>
any review and consideration by ICANN be: simple and
straightforward, <br>
quick and easy to access. <br>
<br>
<br>
1.3 Are there any components of the triggering
event/notification <br>
portion of the RAA's Data Retention waiver process
that should be <br>
considered as optional for incorporation into a
modified Whois Procedure? <br>
<br>
<br>
1.3 Response: Absolutely, the full list in 1.1a above,
together with <br>
other constructive contributions in the Comments and
Reply Comments of <br>
this proceeding, should be strongly considered for
incorporation into a <br>
modified Whois Procedure, or simply written into the
contracts of the <br>
Registries and Registrars contractual language, or a
new Annex or <br>
Specification. <br>
<br>
We respectfully submit that the obligation of
Registries and Registrars <br>
to comply with their national laws is not a matter of
multistakeholder <br>
decision making, but a matter of law and compliance.
In this case, we <br>
wholeheartedly embrace the concept of building a
process together that <br>
will allow exceptions for data protection and privacy
laws to be adopted <br>
quickly and easily. <br>
<br>
<br>
1.4 Should parties be permitted to invoke the Whois
Procedure before <br>
contracting with ICANN as a registrar or registry? <br>
<br>
<br>
1.4 Response: Of course, Registries and Registrars
should be allowed to <br>
invoke the Whois Procedure, or other appropriate
annexes and <br>
specifications that may be added into Registry and
Registrar contracts <br>
with ICANN. As discussed above, the right of a legal
company to enter <br>
into a legal contracts is the most basic of
expectations under law. <br>
<br>
<br>
2.1 Are there other relevant parties who should be
included in this <br>
step? <br>
<br>
<br>
2.1 Response: We agree with the EC that ICANN should
be working as <br>
closely with National Data Protection Authorities as
they will allow. In <br>
light of the overflow of work into these national
commissions, and the <br>
availability of national experts at law firms, ICANN
should also turn to <br>
the advice of private experts, such as well-respected
law firms who <br>
specialize in national data protection laws. The law
firm's opinions on <br>
these matters would help to guide ICANN's knowledge
and evaluation of <br>
this important issue. <br>
<br>
<br>
3.1 How is an agreement reached and published? <br>
<br>
3.1 Response. As discussed above, compliance with
national law may not <br>
be the best matter for negotiation within a
multistakeholder process. It <br>
really should not be a chose for others to make
whether you comply with <br>
your national data protection and privacy laws. That
said, the process <br>
of refining the Consensus Procedure, and adopting new
policies and <br>
procedures, or simply putting new contract provisions,
annexes or <br>
specifications into the Registry and Registrar
contracts SHOULD be <br>
subject to community discussion, notification and
review. But once the <br>
new process is adopted, we think the new changes,
variations, <br>
modifications or exceptions of Individual Registries
and Registrars need <br>
go through a public review and process. The results,
however, Should be <br>
published for Community notification and review. <br>
<br>
<br>
We note that in conducting the discussion with the
Community on the <br>
overall or general procedure, policy or contractual
changes, ICANN <br>
should be assertive in its outreach to the Data
Protection <br>
Commissioners. Individual and through their
organizations, they have <br>
offered to help ICANN evaluate this issue numerous
times. The Whois <br>
Review Team noted the inability of many external
bodies to monitor ICANN <br>
regularly, but the need for outreach to them by ICANN
staff nonetheless: <br>
<br>
<br>
*Recommendation 3: Outreach* <br>
<br>
*ICANN should ensure that WHOIS policy issues are
accompanied by <br>
cross-community* <br>
<br>
*outreach, including outreach to the communities
outside of ICANN with a <br>
specific* <br>
<br>
*interest in the issues, and an ongoing program for
consumer awareness.* <br>
<br>
This is a critical policy item for such outreach and
input. <br>
<br>
<br>
3.2 If there is an agreed outcome among the
relevant parties, should <br>
the Board be involved in this procedure? <br>
<br>
<br>
3.2 Response: Clearly, the changing of the procedure,
or the adoption of <br>
a new policy or new contractual language for
Registries and Registrars, <br>
Board oversight and review should be involved. But
once the new <br>
procedure, policy or contractual language is in place,
then subsequent <br>
individual changes, variations, modifications or
exceptions should be <br>
handled through the process and ICANN Staff – as the
Data Retention <br>
Process is handled today. <br>
<br>
<br>
4.1 Would it be fruitful to incorporate public
comment in each of <br>
the resolution scenarios? <br>
<br>
4.1 Response: We think this question means whether
there should be <br>
public input on each and every exception? We
respectfully submit that <br>
the answer is No. Once the new policy, procedure or
contractual language <br>
is adopted, then the process should kick in and the
Registrar/Registry <br>
should be allowed to apply for the waiver,
modification or revision <br>
consistent with its data protection and privacy laws.
Of course, once <br>
the waiver or modification is granted, the decision
should be matter of <br>
public record so that other Registries and Registrars
in the <br>
jurisdiction know and so that the ICANN Community as a
whole can monitor <br>
this process' implementation and compliance. <br>
<br>
Step Five: Public notice <br>
<br>
<br>
5.2 Is the exemption or modification termed to the
length of the <br>
agreement? Or is it indefinite as long as the
contracted party is <br>
located in the jurisdiction in question, or so long as
the applicable <br>
law is in force. <br>
<br>
5.2 Response: We agree with the European Commission in
its response, <br>
“/By logic the exemption or modification shall be in
place as long as <br>
the party is subject to the jurisdiction in conflict
with ICANN rules. <br>
If the applicable law was to change, or the contacted
party moved to a <br>
different jurisdiction, the conditions should be
reviewed to assess if <br>
the exemption is still justified.” But provided it is
the same parties, <br>
operating under the same laws, the modification or
change should <br>
continue through the duration of the relationship
between the <br>
Registry/Registrar and ICANN. / <br>
<br>
<br>
5.3 Should an exemption or modification based on
the same laws and <br>
facts then be granted to other affected contracted
parties in the same <br>
jurisdiction without invoking the Whois
Procedure <br>
<br>
5.3 Response. The European Commission in its comments
wrote, and we <br>
strongly agree: /“the same exception should apply to
others in the same <br>
jurisdiction who can demonstrate that they are in the
same situation.” <br>
/Further, Blacknight wrote and we support: /“if ANY
registrar in <br>
Germany, for example, is granted a waiver based on
German law, than ALL <br>
registrars based in Germany should receive the same
treatment.” /Once a <br>
national data protection or privacy law is interpreted
as requiring and <br>
exemption or modification, it should be available to
all <br>
Registries/Registrars in that country. <br>
<br>
Further, we recommend that ICANN should be required to
notify each gTLD <br>
Registry and Registrar in the same jurisdiction as
that of the decision <br>
so they will have notice of the change. <br>
<br>
We thank ICANN staff for holding this comment period.
<br>
<br>
Respectfully submitted, <br>
<br>
NCSG <br>
<br>
<br>
DRAFT <br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________ <br>
PC-NCSG mailing list <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:PC-NCSG@ipjustice.org">PC-NCSG@ipjustice.org</a>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://mailman.ipjustice.org/listinfo/pc-ncsg">http://mailman.ipjustice.org/listinfo/pc-ncsg</a>
<br>
<br>
</blockquote>
_______________________________________________ <br>
PC-NCSG mailing list <br>
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:PC-NCSG@ipjustice.org">PC-NCSG@ipjustice.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mailman.ipjustice.org/listinfo/pc-ncsg">http://mailman.ipjustice.org/listinfo/pc-ncsg</a>
<br>
<br>
<br>
</blockquote>
<NSCG DRAFT Comments for Review of WHOIS Consensus
Proceduresp+ad.doc>_______________________________________________
<br>
PC-NCSG mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:PC-NCSG@ipjustice.org">PC-NCSG@ipjustice.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mailman.ipjustice.org/listinfo/pc-ncsg">http://mailman.ipjustice.org/listinfo/pc-ncsg</a>
<br>
</blockquote>
<br>
_______________________________________________ <br>
PC-NCSG mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:PC-NCSG@ipjustice.org">PC-NCSG@ipjustice.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mailman.ipjustice.org/listinfo/pc-ncsg">http://mailman.ipjustice.org/listinfo/pc-ncsg</a>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>