Subject: [ietf-provreg] Our "Privacy Issue"

From: Edward Lewis <[email-masked]>
Date: Sun, 23 Mar 2003 15:23:13 -0500

During the face to face meeting in SF, we had a productive discussion 
of the privacy issue that has been holding up progress.  Minutes, 
et.al. of the meeting will be forthcoming, but the first action item 
to arise from the meeting is a presentation to the WG (list) a 
detailed description of the problem.

In a discussion that involved Ted Hardie, our new Area Advisor, and 
Randy Bush, the following comment was cast into the following 
requirement:

The protocol must provide a mechanism to allow enforcement of privacy 
policy at either the registrar or registrant.  This must be done in a 
protocol feature that is "mandatory to implement, optional to use." 
Further, the privacy meta-data must be to individual elements of 
social data.

     First, before going further, what is stated above is the suggestion
     derived during the face-to-face meeting.  Being that this is a
     clarification of the IESG comment obtained with representatives
     present, this is what we need to solve. However, wording changes
     may be made.

As EPP stands now, privacy policy decisions are only possible at the 
registrar.  This is because the dcp element allows the registry to 
tell the registrar the "rules."  Whatever the registrar sends to the 
registry is considered to be in accordance with the rules.

What is desired is a mechanism that will let EPP support thick 
registries, in which social data is held by the registry.  In such 
situations, the registrar needs to inform the registry of 
restrictions on the redistribution of the data submitted to the 
registry.

There are limits to what the WG is being asked to do.  We are not 
being asked to provide a very rich syntax for the mechanism.  For 
example, we are not being asked to provide a means to say "you can 
publish the phone number in whois but not in any other way."  (We 
could, if we desired, but we are not asked to do.)

There's one protocol standards consideration I'd like to make.  The 
more detail and depth in the solution of a problem often leads to a 
tougher job in reaching consensus.  I.e., as a chair, I appreciate 
efforts to refine and divine the depths of privacy, but such threads 
are in danger of becoming distractions to the main job of this WG.

During the meeting, it was suggested that a mechanism to meet the 
requirement has already been sent to the mailing list and discussed. 
The next steps for the WG is to 1) consider and discuss the 
requirement in this message.  If the WG accepts this as the problem 
statement as discussion in the room did, the next step will be to 
open a thread on the modified proposal suggested.  For procedural 
reasons, I'm not going to mention that proposal until the problem 
statement is accepted by the WG (i.e., the mailing list).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 24 Mar 2003 11:44:47 -0500

...
> The protocol must provide a mechanism to allow enforcement

OK. We blew it semantically in the grrq when we stated the req as a
mechanism to announce.

>                                                            of privacy
> policy at either the registrar or registrant.

OK. We blew it semantically in the grrq when we limited the protocol to
registrars and registries.

>                                                This must be done in a

No comment.

> Further, the privacy meta-data must be to individual elements of

OK. We blew it syntactically by reference to an inextensible type.

> ...  this is what we need to solve ...

I disagree with the claim that any IETF WG needs to be responsive to the
IESG. The claim only begins to approximate "true" iff the WG wants IESG
approval of its work-product.

I'm not convinced that the issue of contention is technical.

> registry is considered to be in accordance with the rules.

Correct. The registry announces a session-policy. Implementors are free
to evaluate the registry-announced policy, and implement local policy,
e.g., accept the policy and propogate policied data, or decline.

> registries, in which social data is held by the registry.

Umm, this _is_ the current model, neh?

>                                                            In such 

This does not follow. Where state is persistent is a different issue
from how may access to that persistent state be implemented.

Just to test the correctness of this reasoning however, if there did
exist a mechanism for a client to select from a menu of policies in
a <dcp> (this begins to look like beep and the srv record), and the
menu offered by a registry was _in_theory_exhaustive_, would the
registrar need to do anything more exciting than pick a policy out of
the extended hat?

> are in danger of becoming distractions to the main job of this WG.

I'll be _happy_ to leave the problem to more capable hands than my own.

To me, it _was_ just distributed read and write access mechanisms to
shared store, with a specific syntax. If someone claims read-on-43
exhaustively defines "privacy", I don't care. It doesn't exhaustively
define _read_.

Enforcement is a whole different can of worms, unless this is just a
techno-fiction.

> For procedural 

Nope. Seems technically flawed to me, and worse than what we had.

YMMV.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Mon, 24 Mar 2003 16:21:09 -0500

>I'm not convinced that the issue of contention is technical.

Then I've failed in my description of the problem.

As we sit, EPP requires the registrar to make decisions on whether 
the submission of a piece of data will be accorded the proper 
handling with regards to privacy.  The issue is that EPP forces the 
registrar into this posture, there is no choice.

What the IESG has asked of us is to make EPP possible to support a 
scenario in which a registrar gives the data and policy request to 
the registry and then let the registry decide what to do. 
Furthermore, a basic framework for this is desired to be part of the 
base protocol.

The IESG is doing this through the role of protocol design engineer 
review - recognizing functionality that oughta be in a protocol but 
isn't.

>The registry announces a session-policy. Implementors are free

But the only option available to users of the client is to decide 
whether or not to make the registration.  We want more of an option 
than that.

>exhaustively defines "privacy", I don't care. It doesn't exhaustively

I don't think anyone is trying to link privacy to what's on port 43 
(whois to most of us).  The goal isn't to tie privacy to any 
publication mechanism.  This is done with the intent that during the 
phase of reaching towards DS, we will have more tools for dealing 
with privacy.  Features are more easily removed from PS to DS than 
added.

>Enforcement is a whole different can of worms, unless this is just a

Enforcement is part of policy and we are making every effort to sidestep it.

>Nope. Seems technically flawed to me, and worse than what we had.

I don't see how.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 24 Mar 2003 18:33:16 -0500

> Then I've failed in my description of the problem.

It had one error. The assertion that to function (at all) some delta
is required. The correct statement is to function (as required post
rfc3375) some delta is required.

Requirement by assertion is more popular than I recall.

> registrar into this posture, there is no choice.

There are a lot of restrictions. RRP doesn't have this one (it has
others). SRS doesn't have this one (it too has others). Etcetera.

Its a nuance that may be lost on some, but the evaluation possible
by the registrar isn't necessarily prospective (forward looking),
it can be of the announced policy at the moment of transactional
evaluation, with some explicit temporal guarantees. Mind, all of
the evaluation is either optional (epp-07), manditory (epp-08), or
irrelevant (iesg-any).

> the registry and then let the registry decide what to do. 

Question #1: If the client originated a <c-dcp> as part of session
init, and the server responded with a <s-dcp>, and the evalution
algorithm (tbd) was simple, e.g., equality, would that meet their
requirement?

> Furthermore, a basic framework for this is desired to be part of the 

As the formal specification of this protocol is in XML, this is more
than it appears.

In eppcom-1.0.xsd we have this:

<!--
Non-empty token type.
-->
  <simpleType name="minTokenType">
    <restriction base="token">
      <minLength value="1"/>
    </restriction>
  </simpleType>

We use it to define type ofthe element "email". Now how does a "data
structures 101" compatible tag fit into that? 

> review - recognizing functionality that oughta be in a protocol but 

3375 is the requirements statement.

> whether or not to make the registration.  We want more of an option 

Please explain.

> >I'm not convinced that the issue of contention is technical.

Just how complex is "privacy"? Is it a property that a tag is a useful
mechanism to encode it?

If "privacy" is simple, something that fits in a tag, then we have one
technical issue.

If "privacy" is not simple, then we have another technical issue.

It is my sense that "privacy" is not simple.

> Enforcement is part of policy and we are making every effort to sidestep it.

To avoid non-sensicalness however, an enforcable mechanism needs to be
capable of violation detection. No spitting when I'm not looking is not
impressive.

> >Nope. Seems technically flawed to me, and worse than what we had.

Cheers,
Eric

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Mar 2003 09:51:16 -0500

>rfc3375) some delta is required.

Eric, help me here.  What is your point?

>Requirement by assertion is more popular than I recall.

I'm still not getting your point.  I'm not sure if you are unhappy 
that someone wants to add client-sent statements on privacy or that 
the someone is the IESG.  I'm not sure I see a reason from you 
explaining why adding this is a bad idea.

>algorithm (tbd) was simple, e.g., equality, would that meet their

Initially, this might be, but as an outcome of the discussion in the 
meeting we felt that finer granularity was desirable and achievable. 
We talked about this as being a session-granular thing, but that was 
discarded.

>In eppcom-1.0.xsd we have this:

You're getting into an implementation detail.  At this point, we are 
hashing out the problem statement.

>3375 is the requirements statement.

Yeah, it is.  Obviously, you mean something by saying that, but it is 
not clear.

>>  whether or not to make the registration.  We want more of an option

We want the registrar to be able to say, here's the phone number but 
don't send it anywhere.  What is meant by 'anywhere' is policy 
specific, hence outside the WG's concern.

>It is my sense that "privacy" is not simple.

Then it's not privacy we are concerned about.  It's about tagging 
data with something called 'privacy.'

Recall that this effort is to build an interoperable, general purpose 
protocol.  If there is something you think is useless and harmless, 
then don't use it and don't complain.  (Harmless = doesn't cause a 
lot of things, including [useless] bloat.)

You may decide that what is here is not enough, then use an 
extension.  You may decide what is here does not apply to you, but if 
it applies to someone else, see if you can live with it.  The process 
is about finding "common denominators" and not tailored, optimized, 
solutions.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 25 Mar 2003 13:21:40 -0500

Hi Ed,

Long and interlinear. 

> Eric, help me here.  What is your point?

You wrote:

No new mechanism is required by this sentence.
                                                                  In such
        situations, the registrar needs to inform the registry of
        restrictions on the redistribution of the data submitted to the
        registry.

False. It is a requirement not in 3375. It is a new requirement, one that
modifies some functionality.

OK, so neither of us writing or grading english compositions. EPP "works"
as is (-02, -04, -06, ... for some value of "works"), and some new thing
is desired by someone in -0N, for some value of N. Fair enough.

> explaining why adding this is a bad idea.

Any requirement not in the req doc is either a) previously rejected, or
b) a failure of the process that created the req doc, or c) neither a)
nor b). Suppose c.

We don't know it is a good idea, we do know that it is the IESG's idea. So,
when we say that Scott is the editor of documents under the change control
of the IETF, what we are really saying is that the actual change control is
held, not by the contributors, acting in concert, under 2026, et alia, to
create some specification, but by institutional authority figures other than
the I-D administrator, who may add/delete/modify the text, without undertaking
the corresponding action on the requirements doc, which has already had WGLC,
and IETF-LC.

If someone wants to modify 3375 and delete the manditory announcement clause,
let them. It is possibly deficient.

If someone wants to modify 3375 and add a manditory enforcement clause, let
them. It is possibly sufficient.

I'm "unhappy" about what I see as the technical difficulty of the proposal,
the inability of the authors of the proposal to make a technical case for a
mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and
the process to effect change control of the provreg work product.

I wasn't thrilled with the congestion issue either, or the ordering issue,
but those are damp spots under prior bridges.

> We talked about this as being a session-granular thing, but that was 

I thought so, which is why I asked.

Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select)
is unrestricted, _this_isn't_what_the_iesg_wants_.

On the bright side, this means that all two-step discovery kludges of the
form Edmon proposed are as KIA as the <dcp>.

On the dim side, this seems to mean that the issue is syntax or religion,
as there's a heck of a lot of values less than BIGNUM (or a full DOM tree),
and a baroque richesse of choices when one is unrestricted. So semantics is
possibly _not_ the issue.

> hashing out the problem statement.

I could be wrong, but the authors of the document offering guidance on the
use of xml in IETF protocols may have failed to mention an edge case.

If a type is inextensible, and is used to type a datum that cannot be
semantically conditioned by any means other than extension, for reasons
that are non-sytactic in nature, an "owie" occurs. I'm sure there is a
better form of expressing this than "owie".

The point of the implementation detail is that I think (I'd prefer to be
wrong) that we need to put a layer between the syntax of EPP extensions
to XML, and the basic types of XML, so that "policy" can be hidden in the
syntax, which I don't see a way to do with the "mail" element's "token"
type.

Eventually all this garbage, mine and anyone else's, gets tossed into a
validating parser. What comes out may come as a surprise to me.

> Yeah, it is.  Obviously, you mean something by saying that, but it is 

See above. *-LC are not meaningless, and should not be "worked around".

> specific, hence outside the WG's concern.

Are there any success or failure semantics? Is the transaction atomic and
unitary, or is a partial write success?

Is the new semantic capable of test by any in-protocol means?

> data with something called 'privacy.'

How large is the policy value space?

Taking the phone number example above, the value space appears to encode
neatly into a single bit.

If so, while I'm typing this I've found one solution to the "email" element
qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal
to pun the size type and signal directionality, into an octet. Violate some
rule about octets in mail addrs, e.g., set a high bit in the domain name.
If high-bit on, semantic one flag set and unset bit before store.
If high-bit off, semantic one flag not set.

mail="[email-masked](eval((0x164+0x177)"

Wierd. I guess the same could be done to the e164 type too.

Of course, if the value space doesn't encode neatly into one bit, then
this won't work, unless applied iteratively.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Mar 2003 13:54:38 -0500

>modifies some functionality.

Yup.  The issue isn't whether something is new or not.  The issue is 
whether it is a good idea.  Recall that in the IETF process, an RFC 
is just that, a request for comments.  I've stated in the past that 
there is never a deadline for getting it right - so long as we get it 
timely.

We can "debate" forever on the merits of late requirements and 
concerns late in the game - but if you care about that, 
problem-statement seems to be the place.  Let's focus on this problem 
statement and not worry about whether or not the process is a problem.

>is desired by someone in -0N, for some value of N. Fair enough.

Basically, yeah.

>We don't know it is a good idea, we do know that it is the IESG's idea. So,

Okay, let's get over this.  Forget who suggested it.  Apparently you 
are not happy with requiring the protocol let the client include 
privacy meta-data to achieve the goal of allowing enforcement to 
happen at the server.

Others have thought this is a good idea, mostly in the room and Scott 
so far as agreed that the statements in the room amounted to what I 
wrote.

>the corresponding action on the requirements doc, which has already had WGLC,

Once again - worry about this in problem-statement.  I ain't about to 
debate the role of the document editor here - the topic is EPP, not 
the IETF.  Scott is recording the consensus of the WG, along with 
much of the material he originally brought to the WG in 2000.  (See 
the charter, it hasn't changed.)

>them. It is possibly sufficient.

I don't think that there's much support for writing 3375bis at this 
time.  Perhaps when a WG comes along to advance to Draft Standard it 
would be good to have a document that rolls in operationally derived 
experience, but it's way too premature to consider this now.

>the process to effect change control of the provreg work product.

With the high bandwith of voice-over-soundwave (a cutsy name for 
face-to-face meetings) I think we were able to get deeper into the 
issue.

>but those are damp spots under prior bridges.

I suppose you are referring in some way to the statement that we 
aren't pursuing SMTP or other transports over TCP (or other 
transports at all).

One reason we are not pursuing them is that 1) no one has maintained 
a document on this for a prolonged period of time and 2) no second 
person has cared enough to present an interoperability-motivated 
reason for this to be brought into the group.

I know you have had documents that discussed SMTP.  My reading of 
them was that they were never fully developed enough to trigger me 
into personal action.

As a WG chair, admittance of documents is based in part on a reason 
to use the WG's resources - i.e., the members.  Without voluntary 
member motivation to review the documents, there's not a sufficient 
reason for the WG to expand its horizons.

I.e., although our charter says we will investigate alternate 
transports - it doesn't mean we will develop an alternate transport. 
So far the result of the investigation is that there's been no 
popular support for other transports.

>is unrestricted, _this_isn't_what_the_iesg_wants_.

You've lost me again here.

>better form of expressing this than "owie".

There may be a better form of saying "owie" but the cost-benefit of 
finding this seems to be discouraging to the group.  (I.e., we've 
been running around just trying to figure out how to spell pirvayc at 
that point.)

>validating parser. What comes out may come as a surprise to me.

Valid concern, but as I said before - implementation detail.

>unitary, or is a partial write success?

It's all policy as far as we can tell.

>Is the new semantic capable of test by any in-protocol means?

Well, we want to be able to set, check, change and define the meaning 
of absence.

>this won't work, unless applied iteratively.

Details, implementation details...

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 25 Mar 2003 16:32:39 -0500

Ed,

Let's get this bit out of the way.

> aren't pursuing SMTP or other transports over TCP (or other 

No. It isn't about what documents the WG pursues. Its about the way
that session semantics crept in, and in a more exclusive form than
any contributor to the WG reqested, either during the reqs period,
or during the incremental deltas from -02 to -06.

I wrote about this at length.

Why does a stream of <check coat> <check bar> <check hat> <check bar>
<check scotch> <check ice> <check bar> <check scotch> <check scotch>
<check scotch> <check scotch> <check floor> have to be strictly ordered?

I don't know. It is worth a drink.

Now this may not be what everyone, or even anyone, wants to do, but to
discover in the ratrace of speculative gTLD operational art, some new
_universal_ requirement that ordering must be preserved, even for some
EPP-for-penguins deployment, is odd.

Then there's the got-to-have-it-now problem, or why order preserving
semantics aren't strong enough, they must be connectionist too. Bye
bye email.

Under the guiding light of the IESG we've gone from a protocol to a
rather narrower operational market in the guise of a protocol.

Believe me, I'm much happier with my drafts poking along dorkily to
dorkimental. But these are edge cases. Transport thingies. Brunner's
bad ideas.

The issue before the WG today is the common syntax. Existance, or not.
With that I'll go back to your note.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 25 Mar 2003 17:11:27 -0500

>                                                      Apparently you 

Actually, I don't even know what "enforcement" means.

How is "enforcement" meaningfully defined in the protocol?

If EPP allowed unconditional write-access to a centralized store, with
only an auth-thingie to partition the store into N-registrar buckets,
and allowed each writer to write the read-access (general, a la :43,
or to any other registrar writer, or the blind registry store manager),
then I'd have a clue what "enforcement" might mean.

The registrar would hand a bitmask the size of a contact object to the
registry, and could attempt to modify it without the auth-thingie, or
read it back without the auth-thingie. Partial sight proved.

>                                                      Apparently you
> privacy meta-data

If only it were that simple. 

All I'm looking for is a way to distinguish one policied endpoint from
another. What I'm not looking for is a way to change the policy on one
policied endpoint, until it is indistinguishable from another.

>                                                      Apparently you
> privacy meta-data

But it isn't that simple, is it? If it were, then just sourcing the <dcp>
from the client, and sinking it at the server, would suffice. But that
isn't it.

Hey, we could go back to BNF, or whatever the people use who write the
UI stuff for insurance companies, and add a little check box. For some
reason, the extra bit(s) have to be just so.

> It's all policy as far as we can tell.

No that is interesting. A functional requirement with no semantics.
A mechanism with no discernable effect. Now that is worth the price of
admission.

> Well, we want to be able to set, check, change and define the meaning 

Sounds like an abstract, post-creat, access provisioning protocol, for
shared, multi-reader repositories. 

Not the same as getting the data past creat, or mod, or ...

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 25 Mar 2003 17:38:31 -0500

Ed,

I'm going to shut up and wait until Scott next delta's of the draft set.

If there is no answer more ... whatever than what's been offered to
my questions to Randy, well, that's life.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Mar 2003 14:18:27 -0500

Answering the side-bar message first:

>Let's get this bit out of the way.

Speaking as a chair, Eric, I have to admit I am having trouble 
comprehending your angst here.  Honestly, every time I begin to try 
to reply to some point you are raising, I get lost in thought and 
realize I've no answer.

I don't want to discount a lone voice in the wilderness (as no one 
else is speaking out in the same way), but its that whatever is 
clueing you into your view is not apparent to me.  Hence, I'm 
powerless to help.

I want to avoid the appearance that EPP is perfect.  (No one is 
running it operationally yet, so even if EPP is the most righteous 
protocol ever designed by mankind, there's no empirical evidence that 
it is perfect.)  But it's also apparent that whatever flaws hiding in 
it are hidden so well not many of us see them.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Mar 2003 14:26:30 -0500

>How is "enforcement" meaningfully defined in the protocol?

In this case, "makes a decision on whether to send some data in a 
message."  We see the need to make decisions at either the registry 
or registrar.

>from the client, and sinking it at the server, would suffice. But that

Part of the problem statement was that we wanted to piecemeal the 
privacy metadata to a finer scope.  Do you think that that is a bad 
idea?

>A mechanism with no discernable effect. Now that is worth the price of

Yes, that is part of the role of being a proposed standard.  We have 
to gain operational experience that may find that parts of the 
protocol are useless or a needed to be expanded - as well as the 
circumstances of the documents.

I have heard rumors that in some business dealings swirling around 
the work done here, there is a need for a "standard."  To some that's 
an RFC, to others PR, to others DS, and so yet some others Full 
Standard or even STD-n.  As a chair, I can't deal with what others 
call a "standard" all I can deal with is what's in the process 
documents.

>Not the same as getting the data past creat, or mod, or ...

Fortunately, this time I got lost at the end of the message.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 26 Mar 2003 16:22:17 -0500

Dear Co-Chair of the PROVREG WG (and all around nice guy Ed Lewis),

I have no angst.

I am quite content that no working group, in particular, the PROVREG WG,
has any interest in some drafts published as individual contributions.

Just to be degenerate, which comes easily to me, and get to some core issues
of ordering, reliability, and who is the author of requirements...

EBW sez <check bar> <check bar> <check bar> contains no fewer than zero,
and possibly as many as one, maybe even three, instances of the operation
"check" on the operand "bar", which might be ordered, and the temporal
bounds on delivery are ... "best effort", or weaker.

PAF sez <check bar> <check bar> <check bar> contains exactly three, ordered
instances of the operation "check" on the operand "bar", and the temporal
bounds on delivery are ... "web time", an odd bit of transactional real-time. 

EBW sez for some things, it matters, for some things, it don't.

PAF sez for all things, it matters equally.

That disposes of epp/smtp, epp/udp, epp/http, epp/uucp, and of course
epp/avian-transport (only a few days until that one, neh?).

This is all done, my concern with the present question fits fairly neatly
into two questions. I can wait till they're answered, or ... expire.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 26 Mar 2003 18:13:41 -0500

> message."

Which isn't the same thing as "makes a decision on whether to send any
data in a message."

Which is why I asked a Yes/No/Mumble question (partial write semantics),
since between "none" and "all" lies "mumble". Eventually I suppose that
"mumble" will take some greater detail.

At least enough to make "mumble enforcement" sensible.

Somewhere out there is a manditory to implement (but always optional to
deploy) requirement that one end point or the other shave at least one
bit (haircut optional for an additional two bits) off of some object.
Which bit(s) is tbd, but some sort of mask is a given.  

I'd like to go on record as wanting the Mask of Zorro, er, Zero.

> privacy metadata to a finer scope.  Do you think that that is a bad 

I'm certain its a ... IESG idea ... to insist on the syntactic form of
metadata, and insist that it be temporally scopeless, and insist that
it is the terminal node in a directed acyclic graph (element attribute).

Randy's an ex-compiler weenie, he knows what he's proposing.

\begin{wicked_serious_mode}

	It depends on what one is attempting to design. If one is
	attempting to provision policy data (aka "metadata") in an
	SRS, and the SRS is not partitioned by metadata, and the
	data is uncorrolated w.r.t. metadata, then the metadata is
	sensibly encoded into the data.

	We did assume that there was correlation when we went for
	the session scoped <dcp>, thinking that changes in <dcp>
	would be infrequent, relative to the policied objects,
	that session encoding of the metadata was sensible, that
	the value-space of the <dcp> was a lot smaller than the
	value-space of the <contact> object, and this design choice
	did not preclude client sourcing of <dcp>, or negociation
	of <dcp>, or .... 

	Where the "finer is better" approach veers away from reality
	is in the assertion that no sensible aggregation of stuff is
	already well-defined in some relevant context. If 95/46/EC is
	a guide for anything that is remotely related to "privacy",
	we can expect to find in it an approval of "finer is better".

	I don't. What I do find is that deconstruction of the data is
	only part of the problem domain. Deconstruction of the purpose,
	recipients, temporal existance, originator write-through (aka
	"access"), and more define the problem domain, and that "fine
	structure" is less important than policing lumps, and relations
	between lumps, that when handled with the intent to construct
	or extract personally identifying information, can.

	I can live with "design" in the IETF social construct, with
	PS/DS/SS having a different frame of reference from "design"
	in the W2C social construct.

	I tried to "cross over" a gramatical framework, from the W3C
	to the IETF. It wasn't a success. No matter.

	I'm spending more time trying to prevent there being two or
	more core syntaxes than I will spend implementing those few
	I care about, so I'm way past my ROI, or my sell-by date.

\end{wicked_serious_mode}

> ... We have to gain operational experience ...

With a mechanism with no discernable effect. OK.

> call a "standard" all I can deal with is what's in the process 

I'm happy with Dork-i-mental, and operational experience. I have very
low tastes. Maybe none at all.

Cheers,
Eric

---

From: "Ram Mohan" <[email-masked]>
Date: Thu, 27 Mar 2003 22:10:17 -0500

Ed,
[snip]
> I want to avoid the appearance that EPP is perfect.
> No one is running it operationally yet

Last time I checked, at least half a dozen registries are running EPP
operationally.  .INFO (02); .ORG(07), .BIZ(04), .US(04?), .AU(05),
.NL(?)plus a bunch more ccTLDs.

> But it's also apparent that whatever flaws hiding in

Not sure the hypothesis is true; exposure of limitations has probably not
happened - i know a few registry folks who have things they don't much care
for in EPP, but haven't talked about it on the list.

-ram

---

From: Asbjorn Mikkelsen <[email-masked]>
Date: 28 Mar 2003 09:23:04 +0000

> .NL(?)plus a bunch more ccTLDs.

...and .NAME(05)...

Asbjorn

-- 
Asbjorn Steira <[email-masked]>
Senior Developer
The Global Name Registry, Limited
Tel: +44 (0) 207 025 2214

Information contained herein is Global Name Registry Proprietary Information and is made available to you because of your interest in our company.    This information is submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.
*****************
What's your .name?
Get one at www.name
*****************

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 28 Mar 2003 08:44:51 -0500

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

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 28 Mar 2003 08:48:17 -0500

> > .NL(?)plus a bunch more ccTLDs.
...and .SG(04) and soon to be .BZ(04 or 07)

Edmon

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 28 Mar 2003 09:46:07 -0500

> ...and .SG(04) and soon to be .BZ(04 or 07)

congrats edmon!!! i'd thought that .bz was a vgrs property. whether you've
moved on to the high-table at vgrs, or swung a spin-out deal, i'm impressed.

---

From: janusz sienkiewicz <[email-masked]>
Date: Fri, 28 Mar 2003 10:51:30 -0500

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

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 28 Mar 2003 11:18:20 -0500

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

---

From: janusz sienkiewicz <[email-masked]>
Date: Mon, 31 Mar 2003 10:11:05 -0500

> .NL(?)plus a bunch more ccTLDs.

I don't know whether .PL is running EPP operationally but at least there is
(07) implementation presented at RIPE-44.

> for in EPP, but haven't talked about it on the list.

Janusz