Glen, would you please post the confirmations to this call for PDP
06, that you have received, check with Avri regarding any
flexibility on her part as chair, check with Liz regarding her
ability to be flexible re times/dates, and if Avri can accommodate,
can we ask via the list if the time can be moved, and /or if the
date can be moved by one day, to Wednesday? Thanks. See below.
Like Jeff, I have a conflict. I am trying to manage around it, but
it occurs to me that perhaps we can ask if some flexibility in the
TF overall can accommodate a further change, if that would help
both Jeff and me, and NOT create challenges for the members of the TF.
I'm in Europe, and have a business dinner that I'm hosting, with
governments, at this time. I will join the call for an hour, which
is the best I can do. My apologies for my limitations.
Moving the call by two hours EITHER WAY would be an improvement for
me and make it easier to participate. Moving the call by a day
would also be an improvement. Jeff, would either of those help you,
as well?
I know, I know. Lots of grumpy comments about checking the ICANN
web site, etc. However, the reality is that 'push' communications
is an improvement over 'pull', and at least two members have
challenges.
Is it possible to accommodate by some flexibility IF it doesn't
disadvantage the long list of other confirmed attendees. IF we have
a long list of confirmed attendees already. And the chair and
policy staff manager can accommodate.
Marilyn
-----Original Message-----
From: owner-pdp-pcceg-feb06@xxxxxxxxx [mailto:owner-pdp-pcceg-
feb06@xxxxxxxxx] On Behalf Of Marilyn Cade
Sent: Friday, January 12, 2007 6:05 PM
To: 'Neuman, Jeff'; 'Avri Doria'
Cc: 'PDPfeb06'; 'Glen De Saint Géry'; 'Liz Williams'; Denise Michel
(denisemichel@xxxxxxxxxxxxx)
Subject: RE: [pdp-pcceg-feb06] PDP Feb06 task force call 16 January
2007 - 1900 UTC
Dear Liz and other ICANN staff
I don't think it is really as effective to rely on the publication
of a
master calendar as the routine communication with a TF regarding
meetings.
Perhaps for now, until members of the community get used to having
to check
the web site for updates, we could return to having a 'push'
approach to
communicating with the TF members. Over time, we may all learn to
check the
web site, but as busy folks, I confess to having lost track myself.
We don't expect the Councilors to remember, but Glen sends them
reminders,
of course, they can then check the web site...
We are all creatures of habit, but more importantly, pretty
consumed with
day to day work as well as ICANN work. Would be helpful to have a
'reminder'
policy by staff.
Marilyn
-----Original Message-----
From: owner-pdp-pcceg-feb06@xxxxxxxxx
[mailto:owner-pdp-pcceg-feb06@xxxxxxxxx] On Behalf Of Neuman, Jeff
Sent: Friday, January 12, 2007 2:26 PM
To: Avri Doria
Cc: PDPfeb06
Subject: RE: [pdp-pcceg-feb06] PDP Feb06 task force call 16 January
2007 -
1900 UTC
OK. Then it was my miss. Unfortunately, I will not be able to attend
due to previous commitments, but I am hoping some others from the
registry constituency will be able to join.
Below are some initial thoughts for discussion purposes on TOR 5.
These
are my own personal thoughts and do not necessarily reflect the
views of
NeuStar and/or the gTLD Registries Constituency (except where so
identified).
1. As stated by the gTLD registry constituencies, in order to
evaluate any policy recommendations, the term "registry data" needs to
be defined.
2. In addition, the group needs to recognize that there are
different types of registry data, some of which is Personal Data, some
of which is completely unrelated to Personal Data. To the extent that
such information is Personal Data (as defined in the existing
contracts
or by applicable national law), such data may already be properly
dealt
with in the WHOIS policies, the existing contracts, or in many
instances
by applicable law.
3. Where such data is not Personal Data, but relates to other
types of data collected by registries, such data needs to be defined.
Perhaps the task force should send a formal request to the registries
asking for the type of data it collects.
4. Work must also be done to establish what rights, either by
contract, law or otherwise, that parties other than registries,
have in
the non-Personal data. The reason I state this is that there has
been a
claim by some that individuals/businesses/entities, etc. have some
sort
of privacy or other right in their "non-personal" data (i.e., traffic
data). I personally have never seen such laws or regulations, but I
would be happy for someone to show me the basis for those claims. In
the event that the Task Force is even thinking about limiting the
use of
any non-personal data, there needs to be some basis in law, contract,
etc. for such limitation. Please also recognize that any limitations
placed on such data by "Consensus Policy" must also be consistent with
the GNSO's mandate and the existing contracts.
5. Finally, the group needs to recognize that registries often
use registry data for security purposes (security for its own TLD and
security for the Internet as a whole). Registries may or may not be
able to disclose how such information is being used, but care must be
taken as to not restrict a registry's right to use registry data for
such purposes.
Jeffrey J. Neuman, Esq.
Sr. Director, Law, Advanced Services & Business Development
NeuStar, Inc.
-----Original Message-----
From: Avri Doria [mailto:avri@xxxxxxx]
Sent: Friday, January 12, 2007 12:26 PM
To: Neuman, Jeff
Cc: PDPfeb06
Subject: Re: [pdp-pcceg-feb06] PDP Feb06 task force call 16 January
2007
- 1900 UTC
Hi,
On 12 jan 2007, at 10.53, Neuman, Jeff wrote:
> Did I miss the previous announcement on a January 16th meeting?
If it
> was previously announced, I apologize for this note. If,
however, it
> was not, when was this decided?
>
> Jeffrey J. Neuman, Esq.
> Sr. Director, Law, Advanced Services & Business Development
>
> NeuStar, Inc.
>
It was announced as part of the entire schedule back in Liz Williams
schedule email of 4 Dec 2006, and has been listed in the GNSO master
schedule for several weeks now.
a.