[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "janusz sienkiewicz" <janusz@libertyrms.info>
Cc: <ietf-provreg@cafax.se>
From: "Edmon Chung" <edmon@neteka.com>
Date: Fri, 28 Mar 2003 11:18:20 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] privacy profile for domain mapping

That is quite true.  There could be potential conflicts.
We need statements that says the registry privacy policy will prevail, next
the contact privacy preference will prevail and then domain preference is
taken into consideration (which is what happens in our implementation for
SG).

i.e.
If the registry policy is that Addr MUST be displayed for the domain, then
even if the contact says dnd it can be disclosed (OR the policy can say that
the upate/creation must fail)

If the contact privacy preference say for email is dnd while the domain
profile says ok for disclosure (AND that the Registry policy allows an
opt-out of the info) then the email must NOT be disclosed (OR the policy can
say that the update/creation must fail)

OR a registry MUST choose to do privacy for domain mapping or contact
mapping only and that they are mutually exclusive.


In terms of dependence on contact mapping, that is not necessarily the case.
If the privacy elements in domain mapping does NOT exist in the contact
mapping, then the policy may say that the field is either ignored, or that
the transaction should fail.

Edmon


----- Original Message -----
From: "janusz sienkiewicz" <janusz@libertyrms.info>
To: "Edmon Chung" <edmon@neteka.com>
Cc: <ietf-provreg@cafax.se>
Sent: Friday, March 28, 2003 10:51 AM
Subject: Re: [ietf-provreg] privacy profile for domain mapping


> I see a general problem with all the proposed variants. They break modular
> architecture of EPP protocol. With the current structure of the protocol
there
> is not much assumed in domain object mapping about contact object mapping
and
> other object mappings. All the proposed variants make domain object
mapping
> depended on contact object mapping.
>
> I see also practical problems with the proposals. It is possible to set
> address, email privacy element/attribute to true in <domain:privacy>
block.
> Meanwhile the owner of the contact object (which does not have to be the
same
> as domain object) may set privacy element/attribute to false for address
and
> email elements. That will lead to a situation when the domain owner
assumes his
> privacy is protected and at the same time it is not. Someone can use whois
to
> query the contact object to see address and email.
>
> Janusz Sienkiewicz
>
> Edmon Chung wrote:
>
> > At the SF meeting we discussed adding privacy profile for contact
mapping,
> > but I think it is important to also add it to domain mapping as well, in
> > fact, I think being able to handle a per domain profile model is even
more
> > important because the same contact may be the admin contact as well as
say
> > the tech contact and the disclosure requirements may also be different
> > within the same domain.
> >
> > Moreover, one contact may be associated with multiple domains, and each
> > domain may have different preference.  (e.g. a domain registered in EU
and a
> > domain registered in US with the same contact might have to/want to
> > disclose/hide different info)
> >
> > Anyway, here are four ways I have thought of to add the privacy elements
for
> > domain mapping:
> > (p=0: ok to disclose, p=1: privacy preserved)
> >
> > (1) adding an optional <domain:privacy> block:
> >
> > ...
> > <domain:privacy>
> >   <domain:registrant>
> >     <domain:contactname p="0"/>
> >     <domain:contactaddr p="1"/>
> >     <domain:contactvoice p="1"/>
> >   </domain:registrant>
> >   <domain:contact>
> >     <domain:contactid type="admin">sh8013</domain:contactid>
> >     <domain:contactPoInfo type="int">
> >       <domain:contactcc p="1"/>
> >     </domain:contactPoInfo>
> >   </domain:contact>
> >   <domain:contact>
> >     <domain:contactid type="tech">sh8013</domain:contactid>
> >     <domain:contactemail p="1"/>
> >     <domain:contactvoice p="1"/>
> >   </domain:contact>
> > </domain:privacy>
> > ...
> >
> > (2) changing <domain:contact> element to include privacy profile for
each
> > contact/registrant
> >
> > ...
> > <domain:registrant>
> >   <domain:registrantid>jd1234</domain:registrantid>
> >   <domain:contactname p="0"/>
> >   <domain:contactaddr p="1"/>
> >   <domain:contactvoice p="1"/>
> > </domain:registrant>
> > <domain:contact>
> >   <domain:contactid type="admin">sh8013</domain:contactid>
> >   <domain:contactPoInfo type="int">
> >     <domain:contactcc p="1"/>
> >   </domain:contactPoInfo>
> > </domain:contact>
> > <domain:contact>
> >   <domain:contactid type="tech">sh8013</domain:contactid>
> >   <domain:contactemail p="1"/>
> >   <domain:contactvoice p="1"/>
> > <domain:contact>
> > ...
> >
> > (3) including everything as attributes in the
<domain:contact/registrant>
> > element
> >
> > ...
> > <domain:registrant name="0" addr="1"
voice="1">jd1234</domain:registrant>
> > <domain:contact type="admin" poInfoIntcc="1">sh8013</domain:contact>
> > <domain:contact type="tech" voice="1" email="1">sh8013</domain:contact>
> > ...
> >
> > (4) combination of 2 & 3 (postalInfo has a further child element while
> > others are grouped as attributes)
> >
> > ...
> > <domain:registrant>
> >   <domain:registrantid>jd1234</domain:registrantid>
> >   <domain:privacy type="postalInfo" t="int">
> >     <domain:postalprivacy name="0" addr="1"/>
> >   </domain:privacy>
> >   <domain:privacy type="others" voice="1" email="0"/>
> > </domain:registrant>
> > <domain:contact>
> >   <domain:contactid type="admin">sh8013</domain:contactid>
> >   <domain:privacy type="postalInfo" t="int">
> >     <domain:postalprivacy cc="1"/>
> >   </domain:privacy>
> > </domain:contact>
> > <domain:contact>
> >   <domain:contactid type="tech">sh8013</domain:contactid>
> >   <domain:privacy type="others" voice="1" email="1"/>
> > <domain:contact>
> >
> > There could also be a (5)th apporach that is to combine 1 & 4 for a
smaller
> > <domain:privacy> block.
> > Thoughts?
> >
> > Edmon
>
>


Home | Date list | Subject list