[dnssd] draft-pusateri-dnsop-private-subdomains-01

[Tim Wattenberg <[e-mail]>]

Tom,

I just read your draft-pusateri-dnsop-private-subdomains-01.
Here’s some immediate feedback:

General:
I see to concepts in this document, one being the possibility to register a subdomain and prevent others from (mis-)using it by adding/changing/deleting records (Sec. 3) and one being the idea of keeping the records private and only queryable by the owner (Sec. 4). Having just finished reading, I’m not sure if I like those two to be „mixed up“ in one document. The first case seems applicable to me without insisting on the second one.

Sec. 3.1:
I’d consider adding some text about FCFS being a possible mechanism as well (not strictly necessary, but what immediately came to my mind).

What happens if "user“ tries to claim "<notuser>._pvt.<domain>.“ (which is not allowed by the policy of the administrative domain)?
You might want to respond with RCODE REFUSED?

I’m not yet convinced of using RCODE YXRRSet (instead of REFUSED), if the zone does already exist (although this would allow a distinction to the case described in the previous paragraph). Maybe I’m just sticking a bit to heavy on what RFC 2136 says ("Some RRset that *ought* not to exist, does exist.“)... 

I think you have a typo in "In response, appropriate NS records for "<user>" will be created in the "_pvtr.<domain>.“ and […]“, or is it "_pvtr.<domain>.“ (sic, note the r) on purpose?

Sec. 3.2:
"Then the message is signed with the subdomain owner's private key.“
If the KEY-change is due to the private key being changed, I presume this is *old* private key?

Sec. 4.1:
Just to make thinks clearer, I’d like an addition along the lines "All queries *to "<user>._pvt.<domain>.“* MUST be signed with the private key of the owner.“. Also I’d consider allowing an unsigned query of SOA records in order to allow checking for existence before trying to claim a subdomain.

I’m happy to discuss your feedback on feedback – here, in the session or during the week ;-)
	Tim