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

From: [email-masked] (Ross Wm. Rader)
Date: Wed, 6 Nov 2002 10:55:40 -0500

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

---

From: [email-masked] (Andrew Newton)
Date: Wed, 06 Nov 2002 12:13:42 -0500

Ross,

Thanks for the comments... my followup is in-line.

> 3.1.9 is amended to remove this particular statement.

I don't think the two are at odds.  The intent of this requirement is to 
allow operators to participate in an authentication distribution system 
and to make sure they aren't limited to only one or mandated to one. So, 
what about removing the "centralised authority" and replacing it with a 
"federated, distributed system" or something like that?  The intent is 
for the optional participation in one or many coordinated systems.  And 
perhaps this requirement should include a note specifying it must be 
within the bounds of 3.1.7.

> levels of privilege that would be determined by the spec.

Thanks for pointing this out.  I never thought the intention was to 
specify only two levels.  The intention was to specify multiple levels 
to match the policy needs of the operator.  This probably needs reworking.

> having to paying for no service provided.

There was a concern from the particpants in Yokahama that abusive users 
would take advantage of a service that allows them to know in advance if 
they are allowed to issue a query.  In other words, they don't want the 
service to advertise its policy because it leads to abuse.

> little bit further. I'm not sure I get how this might/should/could/will

It has been mentioned several times that SRV records should be used to 
find the authoritative server for a particular domain, as opposed to 
starting from a defined well-known or mandated root in another protocol. 
  This requirement is worded so that SRV records are not ruled the only 
way to do it, but that this still be done with DNS as the authority pointer.

I've asked many times in the past for help on rewording this requirement 
to be more readable.  So if you have any ideas, I'd like to hear them.

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

Very constructive stuff.  Thanks.

-andy

---

From: [email-masked] (Ross Wm. Rader)
Date: Wed, 6 Nov 2002 13:24:06 -0500

> within the bounds of 3.1.7.

I understand now. What about something like this;

"The service MUST NOT require any Internet registries to participate in
specific authentication systems. The service SHOULD allow the participation
by an Internet registry in federated, distributed authentication system of
their choosing." followed by the note you suggest above?

> to match the policy needs of the operator.  This probably needs reworking.

Gotcha - the intent was not clear from my reading - which would tend to
support your reworking theory ;)

> service to advertise its policy because it leads to abuse.

This makes a strong case to allow a toggle for the behaviour
(advertise/no-advertise) and let the policy-wonks sort out the details
during implementation.

> to be more readable.  So if you have any ideas, I'd like to hear them.

Ahh...okay. Makes sense. I thought you might be talking about the MagicDNS
that we talk about in ICANN (it can do anything ;) Let me chew on it for a
bit and I'll let you know if I can come up with anything.

                       -rwr

----- Original Message -----
From: "Andrew Newton" <[email-masked]>
To: "Ross Wm. Rader" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 06, 2002 12:13 PM
Subject: Re: [Ietf-not43] -02 c's and q's...

> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43

---

From: [email-masked] (Jim Fleming)
Date: Wed, 6 Nov 2002 13:28:08 -0600

----- Original Message ----- 
From: "Ross Wm. Rader" <[email-masked]>
> bit and I'll let you know if I can come up with anything.

Whois is not really part of DNS. It is a shame that lawyers do not understand that.
Before ICANN, the whois was operated by one company. After ICANN the whois
has been operated by one company with an idirection to other whois services in
many companies. The DNS is still operated by one company. Now, more and more
people see the merits of having several companies cooperatively implement "the Registry"
which becomes a virtual network-based service. Many TLDs have TWO companies
to do that.
http://vuesoft.net/zonexchange/rsc/AIRS.txt
Some think 3 companies is a more robust arrangement. It appears that .COM will
gravitate to 4 companies forming "the Registry". To design to a requirment where
several hundred companies are expected, seems like a major disconnect from reality.
Software developers have to have some sizing estimates to do the best job possible.

Does anyone think that more than 4 companies are needed to build a central Registry ?
...is 3 a better number....or 2 ?...there are 4 tires on most cars...not 150...

Average wholesale cost...$7.735
======= Example 4 RegisTRA Model =======
http://www.cashbackalliance.com/domain/domainsfor619.aspx
$6.19
http://www.wildwestdomains.com/pricelist.asp
$6.75
http://www.srsplus.com/en-def-5d142899df19/en/srsplus/partners_pricing.shtml
$8.00
http://resellers.tucows.com/opensrs/
$10.00
======================================================

---

From: [email-masked] (Andrew Newton)
Date: Wed, 06 Nov 2002 14:50:03 -0500

> their choosing." followed by the note you suggest above?

Sounds good to me.

> (advertise/no-advertise) and let the policy-wonks sort out the details

This is an interesting point.  Are you asking that the requirement be 
changed so that the service has the capability to advertise usage policy 
depending on the paramters desired by the operator?

-andy

---

From: [email-masked] (Ross Wm. Rader)
Date: Wed, 6 Nov 2002 15:11:10 -0500

> depending on the paramters desired by the operator?

Yup.

-rwr

---

From: [email-masked] (Andrew Newton)
Date: Wed, 06 Nov 2002 15:35:10 -0500

How does this sound...

current:

3.1.8 Query of Access Levels

    If a query cannot yield a valid response due to insufficient
    permissions, the service MUST provide the client with an error
    response indicating this condition.  The service SHOULD NOT provide a
    mechanism allowing a client to determine if a query will be denied
    before the query is submitted.

new:

3.1.8 Query of Access Levels

    If a query cannot yield a valid response due to insufficient
    permissions, the service MUST provide the client with an error
    response indicating this condition.  The service MUST provide a
    mechanism allowing a client to determine if a query will be denied
    before the query is submitted according to the appropriate
    policies of the operator.

-andy

---

From: [email-masked] (Ross Wm. Rader)
Date: Wed, 6 Nov 2002 15:58:05 -0500

>     policies of the operator.

'tis okay by me - I'm not quite sure if it is quite specific enough as it
relates to the toggleability of the feature, but I'll leave it to others to
determine if it really gets the point across or not.

I'm happy as is.

                       -rwr

---

From: [email-masked] (Ted Hardie)
Date: Wed, 6 Nov 2002 14:03:58 -0800 (PST)

> shouldn't hold on to the general concept privately any longer ;)

I personal like the "lightweight" language above, but I am concerned
about the opt-out mechanism.  If the mechanism is simple enough to
opt out without requiring a server-to-server interchange, I think
life will be better; I also don't think we can use crisp as the
protocol to conduct that interchange, so I am leary of the requirement.

				regards,
					Ted Hardie

---

From: [email-masked] (Ross Wm. Rader)
Date: Wed, 6 Nov 2002 17:09:01 -0500

> protocol to conduct that interchange, so I am leary of the requirement.

Which opt-out are you referring to - server or registrant?

                       -rwr

---

From: [email-masked] (Ted Hardie)
Date: Wed, 6 Nov 2002 16:11:00 -0800 (PST)

> Which opt-out are you referring to - server or registrant?

Server opt-out.  I'm worried about drifting into server-to-server
protocols.  
			regards,
				Ted Hardie

---

From: [email-masked] (Ross Wm. Rader)
Date: Mon, 11 Nov 2002 16:22:32 -0500

> Server opt-out.  I'm worried about drifting into server-to-server

I hear you, but it would be tremendously useful to be able to send something
out to all nodes in the cloud basically saying "don't bother me for x
cycles..." as a response to the first unwanted query or similar.

Unplugging eth0 has pretty much the same net effect, so I'm not going to
ankle-bite this one...

                       -rwr