From: Robert S. Thau (rst@ai.mit.edu)
Date: Tue Sep 26 2000 - 20:18:44 PDT
Adam Engst writes [forwarded by Keith Dawson]:
I'll respond to one point out of order --- it's last in the note, but
has the most to do with the butterflies in my stomach. Adam says:
> Although there's no doubt that the loss of OneName would be blow to
> the system, especially early on, we at XNSORG have worked hard to
> make sure they're not actually required. Several large firms have
> already expressed interest in running backup root servers, and once
> there are other agencies out there to take up the slack if OneName
> fails, I think XNS could survive that.
But that's not the scenario that worries me. What worries me is the
possibility that OneName (or its buyer or designees) succeeds and
misbehaves --- for example, by providing information to people
claiming to represent law enforcement without an actual warrant, a la
AOL. The same applies to any other root server, of course; if other
agencies are potentially "taking up the slack", I'm afraid that means
that there are *more* folks that I have to trust not to screw up.
The root operator agreement says that OneName can be terminated as
root operator if XNSORG finds "a pattern or practice of abusive trade
practices that are commercially unreasonable and result in unfair
economic advantage to the ROOT OPERATOR or detriment to others" (in
sec. 7.5). Now, IANAL, but I'm not sure that everything that worries
me could be considered a "trade practice", and I'm not sure I see how
other forms of root operator misbehavior are covered by the agreement.
WRT the other stuff:
> We had an open source license ready, but some private feedback
> convinced us that it would just be stupid to release something
> without significant feedback and input from the open source
> community. So we explicitly punted on that entire issue, and I
> pored over the various legal documents to try and make sure that
> none of them required anything in particular of the open source
> license. I don't think they do, and the lawyers we had working on
> it agree, but I'm certainly not an open source expert.
Well, you may be trying to do the right thing here, but I'm not sure I
understand how you're trying to do it. If you want feedback and input
from the open source community, why not post your draft (labelled as
such)? If you've set up a mailing list, the text must be available...
> >What kills it for me, though, is that the license covers the client
> >side only; OneName is explicitly retaining all rights to the patent
> >claims which cover operation of the central directory. Which means
> >that, as Strata has pointed out, if you want to use their tech, you're
> >stuck with them or their licensees, even if they screw up or sell out.
> >This is not the sort of thing I like to see in a privacy guard.
>
> Drummond will have to respond to this. My distinct belief is that
> nothing in the so-called "Reserved Technology Area" is required for
> the operation of XNS.
Well, here's what I was going on, from the patent license agreement:
Without limitation, RESERVED TECHNOLOGY AREA includes Directory
Service Objects described in column 102, line 27 to column 105,
line 51 of the '325 Patent; Payment Service Objects described
U.S. Patent No. 5,862,325 (the "'325 Patent") in column 119, line
13 to column 123, line 15 of the '325 Patent; Feedback Service
Objects described in column 124, line 21 to column 128, line 30
of the '325 Patent; and Schedule Control described in column 136,
line 28 to column 141, line 46 of the '325 Patent; and any
service, method or system which does not rely upon and use the
XNS PROTOCOL.
I'll admit I was assuming that the Directory Service Objects claims
covered the operation of a root server --- I really should have
examined the patent itself, but I have real trouble reading patentese.
Still, if that's not the point of the RTA, I'm a bit perplexed at what
is.
At any rate, clarification from Mr. Drummond would certainly be
helpful.
> >(BTW, the privacy policy on their web site covers retrieval of
> >pages from the web site, and their mailing lists and discussion
> >forums, but is so far strangely silent on the use and
> >redistirbution of XNS ID information. The best discussion I've
> >found on that is on a separate page,
> >
> > http://www.xns.org/governance/legaldocs/globaltermssummary.html
> >but while that document says a great deal about who is required to
> >uphold the privacy policies, it doesn't yet say much at all about what
> >those policies *are*.
>
> Does this answer your question?
>
> http://www.xns.org/governance/legaldocs/privacyterms.html
Well, 3.4.4-3.4.8 are helpful, but they don't cover everything;
it would be good to see more about cooperation with court orders,
for instance. I'm not sure how 3.4.8 stands up against a subpoena,
for instance.
Some of the other paragraphs are still a bit wishy-washy; for
instance, it starts off with:
3.4.1. Fair Information Practices. REGISTRANT agrees that a
principal purpose of XNS technology is to provide an
infrastructure for protecting the privacy and security of each
MEMBER'S information. REGISTRANT agrees to abide by such Fair
Information Practices as XNSORG shall adopt and promulgate with
respect to the information of all MEMBERS. REGISTRANT understands
that, as part of the XNS OPERATIONAL SPECIFICATION, XNSORG may
issue and from time to time amend its own specification of such
Fair Information Practices for the purpose of establishing a
baseline for the XNS COMMUNITY as a whole and increasing the
trustworthiness of the XNS TRUST MARK. REGISTRANT agrees to
conform its conduct to such specification.
Again, that says that the REGISTRANT is bound by the policies, but
doesn't say what the policies are, just that whatever they are, they
are promulgated by XNSORG (and that if XNSORG changes them, REGISTRANT
is bound by the changes; likewise for the privacy policies).
(The requirement for change compliance is actually itself a bit
worrisome; I can imagine XNSORG might change its regulations in a
manner which some users of the system don't like --- requiring some
forms of recordkeeping, for instance. Privacy-sensitive folks often
prefer records not be kept).
rst
This archive was generated by hypermail 2b29 : Tue Sep 26 2000 - 20:23:33 PDT