Re: [ietf-provreg] FYI: EPP implementation by the Polish registry

[Jaap Akkerhuis <jaap@sidn.nl>]

    It appears I did read that. I replied with about 60 lines of comment in
    
    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html
    
    and a one character correction in
    
    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html
    
    and followed up with 
    
    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html

Two followups for a charater change.

You said:

    1. Application of the IESG proposal to "technical" data.
    
    The .NL registry defines (hypothetically of course) a dnp==true value for
    one or more elements as an error condition, and presumably returns some
    error code.
    
    Someone, Scott if my memory serves, mentioned a registry which defines a
    dnp==true value for one or more elements as a non-error, and presumably
    returns something other than an error code.
    
    Is using EPP with dcp==true for technical data a good thing? I see it as
    an operation to modify the string-space, with no external manifestation,
    other than error upon query or transform. I can't imagine an application
    to an address registry's operational practices, but I don't have direct
    knowledge of address registry or registrar operational art.

That shows. Note I said, that this was a hypothetical case.
    
    2. Application of the IESG proposal to "social" data at a registry.
    
    The .NL registry anticipates (effective 29 Jan 2003) operating under the
    general framework of a European Union member state's Data Protection Act.
    
    Consistent with the general framework of EU's Data Protection Directives,
    the access, purpose, recipient, and retention are all contractually defined.
    
    This is not generally the case for registries operating outside of the EU,
    nor for registrars and resellers operating outside of the EU.
    
    It would be helpful if the details of data protection between a non-EU
    resident .NL regsitrar and the .NL registry were available, assuming any
    exist.

Note that we do this under dutch law. If registrars and registrations
doesn't want to confirm to that, there is no point in registrting
in .NL.
    
    3. Existance of the PROVREG proposal, in the presence of the IESG proposal.
    
    Would the .NL registry operator use both the session-level <dcp> data, and
    the element-level opt-{in|out} data? If the answer is "no", as I suspect
    it is, then <dcp> use either a) is error, or b) is silently discarded.

No, it is not discarded. Reread. And I din't mentioned both elements
at all.

    If the answer is "yes", which takes precidence in the event of conflict?

    Trying to keep concrete, data originates from a registrant and is collected
    by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is
    provisioned to a .EU-Registry. Is the mechanism that provides the guidance
    for operational art at each onward-transport entity out-of-band (contract),
    or is it in-band, and if in-band, did the IESG proposal provide the same
    policy at each collector/onward-transporter as the European Union member
    state's Data Protection Act?
    
    I don't think so.
    
    I could be wrong.
    
    A p|np toggle is fine if purpose/recipient/retention/access are already
    taken care of (the Data Protection case). Where they are not, (OEDC and
    US cases), a p|np toggle may solve the 954 problem. How it can be applied
    to non-954 (and 954bis) is not stated.
    
Deliver text.

	jaap