Re: privacy

[Edward Lewis <edlewis@arin.net>]

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:
>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

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