[Ietf-not43] -02 c's and q's...

[Ross Wm. Rader]

...in no certain order....

3.2.3 - I'd like to recommend that we change the requirement to read: "The
service MUST provide a _lightweight_ mechanism to distribute this search
across applicable domain registries and registrars. The service SHOULD have
a means to narrow the scope of a search to a specific TLD.  _The service
MUST provide a mechanism to restrict the scope of a search to specific TLDs,
registrars and registries. The service SHOULD provide a mechanism for
operators to opt-out of this search or series of searches. The service
SHOULD NOT distribute queries to operators that have opted out. The service
MUST be able to specify to the client an empty result set should the search
yield no results."

Comments: I think the lightweight language speaks for itself, hopefully it
addresses some of Rick's concerns (with which I generally concur). As to the
rest, there are any number of operational circumstances where I don't want
to answer queries for a definite or indefinite period of time  - if I don't
want to answer, it seems rather heavy to keep pushing requests my way even
if I am the appropriate place to find the data. I do have a further concern
that there should be an opt-out mechanism for registrants to opt-out of
specific or all searches based on their individual preferences. I need to do
a little more thinking and reading on this one though (but figure that I
shouldn't hold on to the general concept privately any longer ;)

3.1.9 - "The service MUST NOT require any Internet registries to participate
in any particular distributed authentication system." seems to be at odds
with 3.1.7 (The service MUST be decentralized in design and principle and
MUST NOT require the aggregation of data to a central repository, server of
entity.) Either the spec is decentralized or its not. I'd much prefer that
3.1.9 is amended to remove this particular statement.

3.1.4 - Do we think that two levels of privilege is sufficient. Two further
options here - we could open this up to many levels of privilege that might
be determined by the implementation - or - we could open this up to many
levels of privilege that would be determined by the spec.

3.1.8 - "The service SHOULD NOT provide a mechanism allowing a client to
determine if a query will be denied before the query is submitted" - not
sure that I get this one. Is there some perceived danger in clearly marking
the door off-limits for unauthorized personnel? Here's a use-case that
points out one of the negative implications of not marking the door.
Suppose at some point some entity that controls particular information
decides that they want to charge for access to that information. Failing to
provide a mechanism for pre-identifying the result/non-result due to
privileges will leave the customer without the means to determine if a
particular query will yield any useful information to them and may end up
having to paying for no service provided.

3.2.9 Lastly, can someone explain the DNS Label Referencing requirements a
little bit further. I'm not sure I get how this might/should/could/will
work.


Be gentle - I've spent far too much time with policy documents lately. ;)


                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog

Please review our ICANN Reform Proposal:
http://www.byte.org/heathrow