Subject: Re: [weirds] New Version Notification for draft-kucherawy-weirds-requirements-03.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Apr 2012 05:38:11 +0000

> -----Original Message-----
> From: Arturo Servin [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2012 4:40 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [weirds] New Version Notification for draft-kucherawy-weirds-requirements-03.txt
> 
> 	Section 3.2
> 
> 	Instead of: "The design of servers supporting the above protocol needs to consider
>    support for the following likely classes of service for clients:"
> 
> 	I would like something more like:
> 
> 	"The design of servers supporting the above protocol needs to consider
>    support for different classes of service, for example:"
> 
> 	I mention this because the types of services that each operator
> may support could (or it will) be dictated by policy.

OK, but I think the classes we listed will be the ones that all operators need to think about, at a minimum.

>  	Section 3.3
> 
> 	I think that some of the content of this section should be
> documented in the names and numbers data models. I suggest to remove:
> 
> "
>       *  The date/time on which the record most recently changed owners/
>          registrants
> 
>       *  The date/time on which any other part of the record was
>          modified
> 
>       *  The identifier of the registrar that created the record (e.g.,
>          the registrar ID)
> 
>       *  The identifier of the registrant that created the record (e.g.,
>          the registrant ID)
> 
>       *  For network registration records, the range of addresses
>          comprising the assigned subnet
> "

I'm a little worried about starting down this path.  A basic set of data in response to a reply, in a standard form and supporting internationalization and differential services, is what consumers of the data are after.  For instance, the single one you like, creation timestamp of the record, by itself doesn't tell me a lot.  For names, for example, a popular domain might've been registered back in the 1990s but recently expired and come into the hands of a bad actor.  That information is critical to security applications.

It might make the producers happy to do that, but going through huge effort to create a protocol framework for which a nearly empty JSON reply can be reliably returned to the client and claimed as compliant won't attract many parties on the consumer side of this work.

> 	Also, I am not sure that all RIRs databases have all these data
> or if by policy those data is published or not. We analized the current
> output of RIRs whois and not all of the mentioned above is shown,
> either because the RIR does not have data about it or because of
> policy.

I think most of the data that would be considered private is actually omitted from the set above.  Note that we haven't asked for names, phone numbers, addresses, or anything else, nor are the identifiers required to reflect actual registration data (e.g., your NIC handle doesn't have to be anything that resembles your name; it just needs to be constant).  What needs to be enabled are things like:  "Do this registration and that one appear to be owned by the same party?"  "This entity has a good reputation, but it recently changed hands.  That could be interesting."

This also goes back to reputations and default-deny type postures: If the registries won't provide the data that enable such questions to be answered (for any reason, including policy), then people will have to distrust the subjects of the queries.  I think that will put a lot of pressure on policies to meet the clients half-way.

> 	For the security considerations, should be add something about
> privacy, DoS attacks, loops because of redirection, etc. that operators
> or the protocol itself should take care of?

We could add those as things that documents based off of this one need to address, sure.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Apr 2012 05:43:33 +0000

> From: James Mitchell [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2012 8:56 AM
> To: Arturo Servin; Murray S. Kucherawy
> Cc: [email-masked]
> As an example, and with hope that this does not turn into a discussion
> regarding specific registry policies, consider the response to a
> .com.au whois where the creation and expiration dates are withheld as a
> means to reduce frequency of fake renewal notices (registrations are
> for a fixed 2 year period). By mandating the creation date/time element
> you will force their hand to either 1, not implement the product of
> this group, 2, create a similar but incompatible response format, or 3,
> change their policy. I don't think this group should gamble on 3.

This is where differential policy comes in.  For certain classes of consumers, some or all of the things listed are necessary, or the consumer doesn't get anything by being a consumer.  We may as well stick to port 43.

If it will make people feel better, I'd be fine with dropping the specific parts of Section 3.3 in exchange for stronger language in the previous section making it clear that operators should expect to encounter and probably make arrangements to provide more information to bona fide security and law enforcement operators, for example.  They are, after all, half of the equation here.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 03 Apr 2012 12:41:25 +0200

On 03/Apr/12 07:38, Murray S. Kucherawy wrote:
>> From: Arturo Servin
>>       [removed fields]
> I'm a little worried about starting down this path.  A basic set of
> data in response to a reply, in a standard form and supporting
> internationalization and differential services, is what consumers
> of the data are after.  For instance, the single one you like,
> creation timestamp of the record, by itself doesn't tell me a lot.
> For names, for example, a popular domain might've been registered
> back in the 1990s but recently expired and come into the hands of a
> bad actor.  That information is critical to security applications.

IMHO, the fields in Section 3.3 ought to be subdivided by type of
registry, type of query, and perhaps even by class of service.  If at
all possible, the code-name of the field, registrationDate in this
case, should be the hanging text of the list item, since this is where
we define the datum.  The specific response syntax documents
apparently use phrases like "The following is /an example/ of [...]"
(emphasis added).

The specific datum that I'd like to see here, for numbers' operator
queries at the anonymous service class, is the abuse-mailbox contact.