Subject: RE: privacy

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 8 Jan 2003 07:17:41 -0500

> The crux of the issue is, there are situations in which a registrar 
> may wish to alter the default privacy considerations for data when 
> interacting with a registry.  Not all registrar-registry environments 
> will need this flexibility, but there is a claim that some exist.  (I 
> have no personal, first-hand knowledge of any such environments.)
> 
> How can we accomodate such environments?  That is the basic question.

FWIW the attribute-based proposal is the one most closely aligned with
"standard" XML practice, if such a thing exists.  XML attributes are
typically used to describe the data contained within an element, and that's
what's being proposed.

The other proposal I floated (the <doNotDisclose> proposal) could also work,
but it means carrying the same element data twice: once in the "normal"
place and a second time to mark it.  I can understand why some of the folks
who've been doing implementations might find it easier to incorporate into
current code, but I don't think it's the best architectural solution.

Just my two cents...

-Scott-

---

From: Joe Abley <[email-masked]>
Date: Wed, 8 Jan 2003 11:15:22 -0500

On Wednesday, Jan 8, 2003, at 07:17 Canada/Eastern, Hollenbeck, Scott 

> typically used to describe the data contained within an element, and 

Would it be possible to hear the set of requirements to which the 
attribute solution forms an acceptable solution?

I suspect that the requirements need work (or at least they need input 
based on real-life registry policy, as opposed to policy assumed by the 
IESG).

As Rick mentioned, if the IESG could raise their concerns on this list 
it would be a lot easier to understand where they are coming from.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jan 2003 15:53:29 -0500

At 11:15 -0500 1/8/03, Joe Abley wrote:
>I suspect that the requirements need work (or at least they need input based
>on real-life registry policy, as opposed to policy assumed by the IESG).

It's not so much the issue for a registry but for a registrar, which 
I sense isn't being considered.

The IETF concern is that a registrar can work with an registry that 
needs no specific privacy statements made in band and can work with a 
registry using another model that does need statements made.  If the 
registrar has to use two different EPP clients then the WG has failed 
to achieve the goal of interoperability.

E.g., if registry 1 uses brand A EPP client/server and registry 2 
uses brand B, the 'caught in the middle' registrar should be able to 
use the client of brand A xor B to talk to the two servers.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Joe Abley <[email-masked]>
Date: Wed, 8 Jan 2003 16:08:08 -0500

On Wednesday, Jan 8, 2003, at 15:53 Canada/Eastern, Edward Lewis wrote:

> It's not so much the issue for a registry but for a registrar, which I 
> sense isn't being considered.

I haven't been considering the registrar position much, that's true.

However, if the protocol collides with policies of different 
registries, then registries are going to be obliged to break the 
protocol in order to deploy it. You can bet that different registries 
will break the protocol in different ways.

This does not sound like something that will improve the chances of 
client interop.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jan 2003 16:11:52 -0500

Break v. Extend ;)

The way it should work is that if Brand A and Brand B both are 
compliant (remember that we use interoperable, not compliant though), 
then both will understand whatever they are compliant with (e.g., the 
base, extention 1, etc.).  If an extension is needed in the Brand A 
client to talk with the Brand B server for a given registry, extend 
the Brand A client should be a matter of adding a software module.

That's how it is supposed to work.

At 16:08 -0500 1/8/03, Joe Abley wrote:
>>  It's not so much the issue for a registry but for a registrar, 
>>which I sense isn't being considered.
>
>protocol in order to deploy it. You can bet that different 
>registries will break the protocol in different ways.
>

---

From: Joe Abley <[email-masked]>
Date: Wed, 8 Jan 2003 16:21:59 -0500

> That's how it is supposed to work.

Absolutely. That sounds like a strong argument in favour of leaving 
contentious (or registry-specific) matters like policy hooks out of the 
base spec, and allowing them to be implemented as extensions.

The base spec should contain the bare minimum functionality in order to 
provide the essential elements common to the vast majority (and 
hopefully all) registries. Putting stuff in there which is necessarily 
registry-specific means registries will have to break the base spec in 
order to implement it.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jan 2003 16:38:09 -0500

That's the basic rationale behind the criteria I posted in reference 
to the lastVerified element.

But then there's a dilemma of going to extremes, which is what Patrik 
referred to earlier today.  If you push too much out of the base and 
into the extensions, you run the risk of making the protocol too 
complicated to use.  I can think of two examples - IPsec and DNSSEC. 
With IPsec, it was possible to get desktop software to work with it, 
but only if you know the exact incantation of crypto modules 
available.  With DNSSEC, over time optional ways of working were 
invalidated because it was too hard to use (RFC 3008's updating of 
2535 is an example).

Believe me, this issue is a bit complicated, I'm not sure what the 
base problem is.

We are:

) not being asked to solve general privacy concerns.
) not being asked to duct tape in a privacy language
) being asked to put reqd hooks into the language to state privacy in the small

The problem is that we don't know enough about privacy to know what 
hooks are needed or what shape they need to take.  Is that accurate?

At 16:21 -0500 1/8/03, Joe Abley wrote:
>provide the essential elements common to the vast majority (and hopefully all)
>registries. Putting stuff in there which is necessarily registry-specific
>means registries will have to break the base spec in order to implement it.
>
>
>Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 8 Jan 2003 16:42:34 -0500

> hooks are needed or what shape they need to take.  Is that accurate?

That sounds accurate to me.

Joe