At 7:06 AM -0400 8/10/14, Timothe Litt wrote:
>On 09-Aug-14 15:48, Dan Krimm wrote:
>> <pre wrap>
>> I'm sympathetic with this point of view.  Technical issues should be able
>> to be quickly resolved, and it should therefore be possible to identify a
>> technical contact quickly when something technical is going wrong.  I
>> emphasize the word "technical" here quite pointedly.
>>
>> (For example, trademark issues are for the most part not technical -- they
>> mostly do not affect the technical function of the network.  And any
>> relevant impacts are the ultimate responsibility of non-technical domain
>> owners, not technical staff.)
>Yes, and that's why WhoIS has separate contact information for
>Registrant, Administrative, and Technical contacts.
>
>[Definitions:
>  Registrant: the 'owner' of the domain name; legally responsible
>  Administrative: Contact for billing,
>renewal/expiration/cancellation/transfer
>  Technical: Contact for operational issues: malfunctioning servers,
>network issues]

I'm a domain registrant, and also the admin contact for my own domain, so I
know what's in Whois.  :-)



>Note that a trademark holder also deserves a timely response -- as a
>technical person,
>I might argue it doesn't need to be quite as timely (trademark affects
>the competing
>entities, not the whole network).  But still timely in that context.

"Timely" is a completely different time scale for non-technical issues.
The point is, trademark issues won't "break the Internet" vis-a-vis DNS.
ICANN is about IP numbers and DNS, right?

I agree that there needs to be functional pass-through.  But if there is
some trademark issue, I may not want to respond until I consult a lawyer.
As a Little Guy, that may take some time, because I'll be looking for that
advice on the cheap given that I don't have a big budget.

FYI, I am a trademark owner as well as a domain owner so I've been through
some basic parts of that path as well (I currently administer my own
trademark, for renewals, etc.).  It amuses me when I get emailed (generally
from Asia) alerting me to someone wanting to use my second-level domain on
some other TLDs, under the framework of "protecting my trademark" when what
they are really doing is trying to sell me unnecessary 2LDs.  I respond to
them that as long as the other registrants aren't infringing my trademark,
I don't care about anyone else's use of that 2LD on a different TLD (simply
operating an identical 2LD in a different TLD does not constitute
infringing my trademark per se -- they'd have to masquerade with my logo,
etc., actively trying to confuse the public that they are me -- the 2LD by
itself does not rise to that criterion).



>> Privacy issues arise mostly for "small" domain owners (like myself)
>> that do
>> not have the "corporate veil" to protect personal identification
>> information with a "corporate front".  I don't know the statistics, but I
>> would not be surprised if the substantial majority of second-level domain
>> owners actually consists of small entities such as myself -- private
>> individuals, sole proprietors, small businesses.
>>
>I am such a domain owner.  Privacy is important - I said that.  A
>suitable anonymous
>proxy service can meet both objectives - as long is it ensures timely
>delivery.  That
>includes both electronic delivery and physical delivery (e.g. service of
>process.)
>
>I've said that many times too.
>
>What is NOT acceptable is providing false, unresponsive, obscured or no
>information.

No argument there, we are in accord, as long as privacy protection is an
option (additional elaboration below flagged by ***).



>Registrars could help by defaulting their technical contact contact
>information when
>their servers are used and prompting for technical contact information
>when other
>name servers are registered.  Typically, they don't - and registrants
>either enter their own
>information (but don't know how to respond), or not wanting to be
>annoyed, enter
>false/random data.
>
>Abuse of WhoIS data (including trolling it for spam) is a separate
>issue.  Spam delivered
>through a privacy proxy is no more nor less obnoxious than other spam.
>One advantage
>of a privacy proxy is that the registered (in whois) address can be
>changed periodically
> - thus invalidating the spammer's illicit lists. [This has to be done
>in a manner that doesn't impact legitimate use.  I won't specify how
>here, but it's
>quite doable.]

My domain host does have a proxy service and it seems to work well.  This
is enough for my needs.  However, in case the free market were not up to
providing sufficient options for this, I'd like to see a mandate that this
service be offered across the board, as a backup to the free market.  In
fact, it should be built-in to the basic design of the Whois database and
applications.



>> And many of such small domain owners use domain-hosting services, and the
>> technical contacts at those hosting services presumably should be the
>> first
>> point of contact for technical network issues.  (There could be technical
>> content issues associated with web servers, but those are by and large
>> distinct from network technical issues.)
>>
>The WhoIs technical contact is for generic network technical issues
>traced to a domain.
>These may be DNS server issues;  however, it is also used for network
>routing/protocol
>violation/denial of service source reporting and other issues not
>specific to a higher
>level protocol (e.g. http, smtp, ftp, imap, pop,bittorrent, etc).
>
>Websites should, as good practice have a contact method (typically
>'contact webmaster')
>on their site (at least the home page), but that's out of scope for
>WhoIS.  E-mail servers
>are required (by the SMTP RFCs) to respond to 'Postmaster'.  Other
>services have other
>conventions.  Sadly, these days many sites don't conform to those
>RFCs/conventions,
>but again, that's out of scope of WhoIS.
>
>I guess I should also mention that WhoIs also operates on IP addresses,
>not just domain
>names. (e.g.
>http://whois.arin.net/rest/nets;q=8.8.8.8?showDetails=true&showARIN=false&ext=netref2)
>That fact is rarely mentioned here...though contact issues are similar.

FYI, I also contract web hosting and email hosting to a third party.  So
some of these issues reside with the contractor as well.  I don't operate
any servers on the Internet myself.  The only Internet node I operate
directly is my personal computer through my ISP (though obviously I have
access to the content areas of my web server, etc.).



>> One of the things I look forward to in the future of the Internet is an
>> even broader proliferation of domain ownership by Little Guys like me, but
>> in that event we need to protect us Little Guys as if we were individual
>> citizens, not treating us as if we were big corporations with more layers
>> and resources for dissociating individuals from corporate activity.
>>
>No disagreement.  See my **many** pleas on this list for considering
>**individual**
>registrants, not just non-commercial corporations.  For example, I've
>pointed out
>that we individual registrants can't protect our domain names, since a
>Trademark,
>by definition, is a mark used in commerce...  (Yes, it's slightly weird that
>"non-commercial" organizations are "engaged in commerce" for trademark
>purposes.  But individuals (e.g. families) are not.  That's our legal
>system.)
>
>I haven't gotten any traction on individual rights issues here -- but
>those aren't in
>scope of the current note.

Why not?  Individual use is often non-commercial.  Non-commercial is
non-commercial.  Even though I own a dot-com domain, I have never actually
used that domain directly for commerce.  The closest to it is that I use it
partly for some promotional purposes linking to commerce sites elsewhere
that may generate a trickle of revenue for me from time to time.



>> If my domain host did not have a service to add that layer of anonymity to
>> domain contacts, I would be uncomfortable using them as my host and would
>> look for one that did offer such service.  And if I couldn't find one,
>> then
>> I'd be uncomfortable maintaining my own domain -- if I really felt the
>> need
>> to continue operating my own domain, then I'd be forced to consider
>> spending resources to formally incorporate some entity to act as the
>> domain
>> owner, and to establish separate contact information for that entity that
>> does not identify me as an individual.  This creates higher barriers to
>> entry for domain ownership (or else a tradeoff of the cost of lack of
>> personal privacy).
>>
>Many domain hosts (including registrars and 3rd party DNS services)
>offer privacy
>proxy services - some for free, some at additional cost.  There are also
>3rd-pary
>privacy proxy services.

Yes, of course.  IMO this should not be left to discretion of hosting
services.  It should be built-in to the Whois design and implemented
everywhere.



>The important thing is that a responsive contact be listed for each
>classification,
>and that the contact data is maintained in usable form.  That is, an e-mail
>address needs to be able to be plugged into a notification script (not
>mangled
>or sent thru a 'human detector').  A physical address can be a post
>office box,
>a proxy service, or an attorney - but it needs to be something that if
>printed
>on an address label, is deliverable.  (Graveyards, vacant lots, 'Santa
>Claus, North
>pole', unrelated parties do not qualify..., nor do phone numbers of
>pornographic
>pay services.  Yes, all of the above have been used in the name of
>'privacy'.)

*** When privacy services are not offered, a registrant is faced with a
binary choice: false information, or loss of privacy.  In such cases, the
latter gets priority in many cases, as a lesser of evils (most of those
registrants are probably not doing anything nefarious).  If a privacy
service were offered, then I'd bet the amount of false information would
drop dramatically.  And, it would give solid justification to policing the
accuracy of the information much more diligently.

This is a chicken-egg situation.  Who blinks first?  I think that privacy
options should be made universal first.  Then go after false info after
that with gusto.

(Though, there is still the further issue of legitimate anonymity for
whistleblowing purposes, which may suggest cases where info might at least
be missing, above and beyond being proxied.  I'm not sure we will ever
resolve that perfectly, because I'm not sure if that can ever *be* resolved
perfectly.  Anonymity can be abused, no doubt.  So if we're going to err on
one side or the other, should it be protecting legitimate anonymous use
even if some abuse occurs, or preventing any abuse of anonymity by
preventing any anonymity at all?  Perhaps what happens is that abuse of
anonymity is punished by removal from DNS, after sufficient due process has
established actual abuse.  I'm not claiming to have an answer here.  Would
be curious to hear your opinion, though.  This is a difficult question,
perhaps the most difficult of all.)



>Note that the example given was one where the desire was to detect issues in
>the top 1M domains (which, allowing for common servers, still would mean at
>least thousands of servers.  And if only 10% had the issue, hundreds of
>notifications.)  The institution behind this is quite capable of looking at
>even larger scales.
>
>Also note that such mass notifications are not "Spam"; by listing a
>technical
>contact, notifications of technical issues to that contact is solicited.
>
>> If one promotes the idea of widespread individual ownership of domains
>> (distribution of power, basically -- this is about pushing back against
>> centralization of authority), then systematic privacy protection for
>> citizen-level owners needs to be in place, and that protection need not be
>> pierced when technical domain operations are contracted to a third party.
>>
>> (FYI, I am personally not technically qualified to parse and respond
>> to the
>> example you present below.  Even though I own my domain, the domain
>> host is
>> the only entity in position to respond to this, and that is part of what I
>> have contracted them to do.  Their technical operations are almost
>> completely opaque to me.  So *I* should not be listed as the domain
>> technical contact -- I would just slow down the resolution of such issues
>> if I were in the loop.)
>>
>I did not intend for this audience to evaluate the example's technical
>merits.
>I would not have posted a meritless example.  (In case it isn't clear,
>I'm quoting
>the example from another list; I'm not behind it.)
>
>Again, that's why there are multiple contacts in WhoIS.
>
>> Finding the proper balance here is precisely what this ongoing debate is
>> all about.
>>
>Yes.  I just thought it was time to provide a concrete example of the
>case for
>functional WhoIs.  That 'side' of the debate is underrepresented in this
>group...

In my time here (starting mainly in 2007), it has always been implicit (and
on occasion explicit) that the consensus is in clear support of "functional
Whois" -- that has never been in doubt so far as I know, goes without
saying (but perhaps worth saying once in a while, I don't begrudge you
bringing it up here).  Being against overreach of Whois does not constitute
Whois abolitionism, just as opposition to copyright maximalism does not
constitute a copyright abolitionist stance.

In matters such as this (both Whois and intellectual property), I consider
myself an "optimalist" -- looking for that sweet-spot, the "Goldilocks"
solution.

There are so many "Whois maximalists" at large at ICANN (and outside of
ICANN but seeking to influence ICANN, such as law enforcement) that it
seems that that side of the debate is well represented elsewhere.  Though,
that side of the debate often goes well beyond "functional" Whois (the
trick here is defining what "functional" means, and according to whose
needs or goals).  Law enforcement definition of "functional" may go beyond
what I'm comfortable with defining as "functional" -- for example, if due
process is lost along the way.

This is where the conceptual debates arise, mostly matters of scope of
"functionality" with regard to DNS and Whois.  One view that shows up here
in the NC groups a lot is the idea that narrowing scope of Whois to only
what is necessary to perform its direct technical functions would clear up
a whole lot of the issues like privacy.  Mission creep is the threat here,
and there is much push-back against mission creep from NCUC in particular
and from NCSG as a whole to the extent that it continues to be influenced
by NCUC members.

The best way to resolve these issues within ICANN as a whole is to arrive
at a clear consensus on the functional scope of Whois across all
stakeholders (or at least "enough for rough consensus").  This has been the
primary battleground on this issue for as long as I've been here.  I'm not
sure how optimistic to be that we can reach such consensus any time in the
foreseeable future.

Do you have an opinion as to the proper scope of mission for Whois?  If so,
I'd like to hear it, since you brought this up.  What exactly does
"functional Whois" mean to you?

Dan


--
Any opinions expressed in this message are those of the author alone and do
not necessarily reflect any position of the author's employer.



>Timothe Litt
>ACM Distinguished Engineer
>--------------------------
>This communication may not represent the ACM or my employer's views,
>if any, on the matters discussed.
>
>
>> Best,
>> Dan
>>
>>
>> --
>> Any opinions expressed in this message are those of the author alone
>> and do
>> not necessarily reflect any position of the author's employer.
>>
>>
>>
>> At 2:49 PM -0400 8/9/14, Timothe Litt wrote:
>> </pre><blockquote type=cite><pre wrap>
>> There is a recurring theme in discussions here that WHOIS data/accuracy
>> is a matter of privacy; that somehow the technical need is imaginary, or
>> obsolete because most registrants don't actually operate DNS servers.
>> The fact is that someone operates the servers, and the technical contact
>> needs to reflect that.
>>
>> Here is a recent (today) example of a (frustrated) senior engineer
>> attempting to get malfunctioning DNS server operators to address issues
>> that are causing considerable grief.
>>
>> </pre><blockquote type=cite><pre wrap>
>> I just logged fault reports with the technical contact for every
>> tld that has a server that responds incorrectly to EDNS(1) queries
>> if they handle EDNS(0) queries. BADVERS should be the result if
>> they the support EDNS as EDNS(1) is not yet defined.
>>
>>     dig +edns=1 zone @host
>>
>> I've had one contact acknowledge the report and say they have logged
>> a report upstream.  This doesn't mean that the others won't be acted
>> on.
>>
>> If we had consistent whois formats I would do the same for the Alexa
>> top 1M.
>> For the tld's I only had to deal with one whois output.
>>
>> The next round will be for those that don't correctly handle unknown
>> EDNS options.  Unknown options should be ignored.
>> </pre></blockquote><pre wrap>
>>
>> Although I'm on record as believing that privacy needs to be protected
>> (and I hate the SPAM that comes to addresses that are ONLY used in my
>> WhoIS data), and that privacy proxies are fine; I'm also on record that
>> whois contacts need to be responsive - whether directly or thru proxies.
>>
>> Note that in this example, only one **TLD** responded in a timely
>> fashion; whois is in such sad shape that the engineer didn't even try to
>> contact the next million domains... Which also gives you some idea of
>> the scale of technical issues these daze.
>>
>> (EDNS queries are queries that include OPT records, which provide DNS
>> extensions; at the moment, most notably allowing message sizes greater
>> than 512 Bytes, extended flags and response codes.  These are essential
>> for DNSSEC deployment.  There are active proposals for other uses.)
>>
>> I'm not discounting the need for accurate and timely administrative and
>> registrant contact information - I just thought I'd share a current,
>> live example.
>>
>> --
>> Timothe Litt
>> ACM Distinguished Engineer
>> --------------------------
>> This communication may not represent the ACM or my employer's views,
>> if any, on the matters discussed.
>>
>>
>>
>>
>> Content-Type: application/pkcs7-signature; name="smime.p7s"
>> Content-Disposition: attachment; filename="smime.p7s"
>> Content-Description: S/MIME Cryptographic Signature
>>
>> Attachment converted: Macintosh HD:smime 77.p7s (    /    ) (008177D4)
>> </pre></body>
>> </html>
>> </html>
>
>
>
>
>Content-Type: application/pkcs7-signature; name="smime.p7s"
>Content-Disposition: attachment; filename="smime.p7s"
>Content-Description: S/MIME Cryptographic Signature
>
>Attachment converted: Macintosh HD:smime 78.p7s (    /    ) (00819AD5)