[atlarge-discuss] Re: [ga] Re: [nc-deletes] FW: [council] Concerns Regarding Report of Deletes Task Force

[Jeff Williams <jwkckid1@ix.netcom.com>]

Eric and all former DNSO GA members or other interested parties,

  A good lock will stop a poor crook every time.  Hence it is a matter
or degree, not an absolute.  Hence I don't find your remarks along that
logic to be very compelling, Eric.  Good people and good crooks
will always find a way to circumvent policy or law.  Any contract
can be broken to be sure.  But why do so unless there is a compelling
GOOD reason to?

  Good laws catch most good crooks and sometimes good people that
are ignorant of the law that they have broken.  Good policies are only good
in the ever changing communications arena when they are flexible, AND
well understood.

Eric Dierker wrote:

> I don't know but this problem seems to be business.
> It is not a matter of law.
> Either take care of business or do not whine.
>
> On the other hand a breach of contract and theft are just those.
> Policies and rules that prevent wrongful and evil actions are just that.
> "A lock stops an honest man" but no lock will stop a crook.
>
> e
>
> > Dr. Lisse and all former DNSO GA members,
> >
> >   Excellent comments are review here Dr. Lisse.  I have been preparing
> > INEGroup's response and have not had time yet to submit it.  Many of
> > the observations that you noted below closely follow ours.  It seems
> > that yet again Louis has been less than helpful in some respects in his
> > very skewed remarks and comments.  This of course was I am sure,
> > expected.
> >
> > Dr Eberhard W. Lisse wrote:
> >
> >> I have widened the Cc list, can someone post this to ga@centr.org and
> >> ga@dnso.org, if it is rejected by the mailing lists for non
> >> subscription?
> >>
> >> Personally I think Mr Trouton's input is not very helpful.
> >>
> >> 45 days is 45 days. We can give 90 days, 180 days, 9750 days, someone
> >> will manage to meet the deadline. And his name will not necessarily be
> >> Murphy.
> >>
> >> Concern A:
> >>
> >> Now I am not a laywer, just a simple Obstetrician and Gynaecologist,
> >> but the hypotheticals don't make much sense to me.
> >>
> >> #1: As far as I read the ICANN Registrar Agreement this case can not
> >> occur, and if it does, it is the Registrar's responsibility to make it
> >> right.
> >>
> >> #2: As far as I understand the usual Registrant Registrar agreements
> >> this case can not occur. And, if Registrant's headquarters happens to
> >> be in Tikrit, or happens to become collateral damage, they don't need
> >> much DNS in the first place.
> >>
> >> #3: Now I don't much about courts (yet, even being an Obstetrician
> >> :-)-O), but as far as I understand court orders have precedence over
> >> any agreement getween two ligitating parties. Seems to me that in the
> >> US this is true too, they even decide who wins elections, never mind
> >> how the people voted.
> >>
> >> #4: Besides the fact that this is actually #3. one would think that
> >> court proceedings would be rendered moot on expiry of the domain.
> >>
> >> #5: Too bad. They should have paid in time. They better have
> >> insurance.  In any case Mr Trouton's colleagues will institute a class
> >> action suit and pocket 1/3 of the proceeds.
> >>
> >> #6: As far as I understand an agreement is an agreement, and a
> >> deadline is a deadline. The first thing that happened when the .COM
> >> bubble burst was that the leased company cars and the leased cell
> >> phones were returned. The second was that the telephone lines were cut
> >> when the invoices were not paid any more. Under this, they would have
> >> to remain with the client and increase the debt of the bancrupt
> >> Registrant.
> >>
> >> #7: "The check is in the mail" (straight out of the book "2002 ways of
> >> not paying your bills" :-)-O). Too bad.  As far as I understand even
> >> ICANN requires TIMELY submission of Proof of Payment for its own
> >> bills.
> >>
> >> #8: I can not find a clause in any ICANN policy MANDATING favouritism
> >> or even condoning it. As far as I understand RFC1592 (and ICP-1)
> >> actually say the opposite.
> >>
> >> Concern B:
> >>
> >> Each registrar must of course tell Registrants BEFORE they apply, what
> >> the conditions will be. I can not read anything here that forbids the
> >> Registrar to modify its procedures after registration. It is a matter
> >> for the agreements between Registrar and Registrant, and all the
> >> agreements that I have read have a clause that modifications are to be
> >> published on the web site and accpepted by clients if not objected to
> >> within a period of time. Even the ICANN Registrar Accreditation
> >> Agreement has such as provision
> >>
> >> The ICANN Registrar Agreement does indeed MANDATE a web site for
> >> whois, so they can post it there if they don't have any other
> >> one. However it is actually impractical to assume that in a high
> >> volume, low cost per item, IT industry that any business model would
> >> pass ICANN's Registrar accreditation muster i they didn't have a web
> >> site where to post this.
> >>
> >> Concern C:
> >>
> >> There *IS* a "consideration" for the service provided in some of other
> >> form. I can not read anything that prescribes or limit the amount
> >> here.
> >>
> >> Concern D:
> >>
> >> Overlap with other task force is specifically not an issue for this
> >> Task Force. As it happens to concern deletion the recommendation of
> >> this Task Force should, of course, have precendence. However, I can
> >> not find any ICANN document stating that "First Come, First Serve" is
> >> the guiding principle of the policy process. I can also find nothing
> >> saying that any of this is easy.
> >>
> >> The Task Force had the brief of coming up with a policy and propose it
> >> to Council. The Task Force has come up with a policy (unanimously with
> >> one abstention) and proposes it to Council.
> >>
> >> Now, Council can vote on submission to the ICANN Board, as is, with
> >> amendments, or not at all.
> >>
> >> ICANN staff then can make unilateral decisions by violating all its
> >> own policies. As usual.
> >>
> >> I vote against any changes to the report.
> >>
> >> el
> >> --
> >> Dr. Eberhard W. Lisse  \   *    /        Managing Member, NA-NiC (cc)
> >> <el@lisse.NA> el108    /       | NA-NiC is the the .NA ccTLD Registry
> >> Private Bag X5501       \     /           NA-NiC, Not Just Like That!
> >> Oshakati, Namibia       ;____/     Telephone: +264 81 124 6733 (cell)
> >> Please send DNS/NA-NiC related e-mail to dns-admin@na-nic.com.na only
> >>
> >> In message <BABCAD2B.1E308%fausett@lextext.com>, Bret Fausett writes:
> >> > Thanks for this. Some of the points, especially with regard to the
> >> > ramifications of a uniform policy, were, I think, contemplated by
> >> > the task force. Other points reveal ambiguities in our drafting that
> >> > ought to be easily solved by a rewording. The whole report, however,
> >> > probably warrants a thorough review in light of the staff report.
> >> >
> >> > Procedurally, what can we do at this point? My sense is that it will
> >> > be easier for the task force to consider the staff report, having
> >> > been involved more deeply in these issues, than to ask the NC to
> >> > deal with it. Is there a mechanism that would allow us to reconcile
> >> > the task force report with the staff commentary?
> >> >
> >> >       Bret
> >> >
> >> >
> >> > Jordyn Buchanan wrote:
> >> > > -----Original Message-----
> >> > > From: Louis Touton [mailto:touton@icann.org]
> >> > > Sent: Friday, April 11, 2003 3:00 PM
> >> > > To: council@dnso.org
> >> > > Subject: [council] Concerns Regarding Report of Deletes Task Force
> >> > >
> >> > >
> >> > > To the GNSO Council:
> >> > >
> >> > > The agenda for the Council's next meeting (17 April 2003) includes
> >> > > the following item:
> >> > >
> >> > > "6. Vote to approve the Deletes Task Force recommendations and
> >> > > report for submission to the ICANN Board."
> >> > >
> >> > > Because the Deletes Task Force commenced work before the GNSO PDP
> >> > > came into effect on 15 December 2002, a Staff Manager has not been
> >> > > assigned and the T
> >> > ask
> >> > > Force has not otherwise had significant staff involvement/support
> >> > > to date.
> >> > As
> >> > > part of the overall process of transitioning to the PDP, Dan
> >> > > Halloran and I have just reviewed the Deletes Task Force's Final
> >> > > Report, as posted at
> >> > >
> <http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report.html>.
> >> > >
> >> > > Based on that review, we have concerns regarding some aspects of
> >> > > the report
> >> > .
> >> > > The purpose of this message is to alert the GNSO Council to the
> >> > > staff's concerns with the recommendations as currently framed.
> >> > >
> >> > > Concern A: The Proposed Mandatory Deletion Policy Does Not Allow
> >> > > for Extenuating Circumstances
> >> > >
> >> > > In its current form, the report makes two recommendations that
> >> > > require registrars to delete domain-name registrations within 45
> >> > > days after they expire. These recommendations appear to apply
> >> > > absolutely, not allowing exceptions for various extenuating
> >> > > circumstances under which deleting registrations by that deadline
> >> > > could harm innocent registrants or result in loss of DNS
> >> > > nameservice for other domains.
> >> > >
> >> > > The recommendations are 3.1.1 and 3.1.2:
> >> > >
> >> > > "3.1.1 Domain names must be deleted if a paid renewal has not been
> >> > > received by the registrar from the registrant or someone acting on
> >> > > the registrant's behalf by the end of the Auto-renew Grace Period
> >> > > (generally forty-five days after the domain's initial expiration).
> >> > > As a mechanism for enforcing this requirement, registries may
> >> > > elect to delete names for which an explicit renew command has not
> >> > > been received prior to the expiration of the grace period."
> >> > >
> >> > > "3.1.2 Domain names must be deleted within 45 days of the
> >> > > expiration of the registration agreement between the registrar and
> >> > > registrant, unless the agreement is renewed."
> >> > >
> >> > > It appears that a registrar has no ability to delay deletions past
> >> > > 45 days
> >> > in
> >> > > extenuating circumstances. Here are a few hypothetical situations
> >> > > intended
> >> > to
> >> > > highlight the serious problems such an unqualified rule could
> >> > > cause:
> >> > >
> >> > > Hypothetical #1: Shortly before the 45-day deadline, the registrar
> >> > > discover
> >> > s
> >> > > that its contact data for the registrant has been altered due to
> >> > > hacking or some other incident in the registrar's systems. The
> >> > > registrar concludes tha
> >> > t,
> >> > > as a result of the alteration, a renewal notice was never sent to
> >> > > the prope
> >> > r
> >> > > address for the registrant, so that the registrant has never paid
> >> > > a renewal fee and has never entered into a renewed registration
> >> > > agreement. Nonetheles
> >> > s,
> >> > > the registrar is required by 3.1.1 and 3.1.2 to delete the
> >> > > registration, resulting in DNS service to the registrant being
> >> > > shut off. The service can only be restored, after some delay,
> >> > > through restoration under the redemptio
> >> > n
> >> > > grace period.
> >> > >
> >> > > Hypothetical #2: The registrant's main office is located in a
> >> > > building that has suffered a disaster due to
> >> > > flood/fire/earthquake/war/terrorism/etc. The renewal notice was
> >> > > sent to that address, but it appears doubtful that the registrant
> >> > > would have been able to complete the renewal process by the
> >> > > deadline. Nonetheless, the registrar is required by 3.1.1 and
> >> > > 3.1.2 to dele
> >> > te
> >> > > the registration, resulting in DNS service being shut off.
> >> > >
> >> > > Hypothetical #3: A registration is the subject of court
> >> > > proceedings over wh
> >> > o
> >> > > is the proper domain-name holder. The court issues an order
> >> > > requiring that
> >> > the
> >> > > registrar "freeze" the domain registration, to prevent any
> >> > > changes. The registrant does not pay the renewal fee, putting the
> >> > > registrar in the posit
> >> > ion
> >> > > of either violating the court order or breaching 3.1.1 and 3.1.2
> >> > > (and therefore its accreditation agreement with ICANN).
> >> > >
> >> > > Hypothetical #4: A registrar has submitted a "registrar
> >> > > certificate" to a court concerning a domain name that is currently
> >> > > involved in court proceedings. In the registrar certificate, the
> >> > > registrar has submitted the registration to the court's
> >> > > jurisdiction and has promised not to modify, transfer, or delete
> >> > > the registration during the court proceedings. No renew
> >> > al
> >> > > takes place within 45 days after expiration, so that 3.1.1 and
> >> > > 3.1.2 requir
> >> > e
> >> > > the registrar to act contrary to the registrar certificate.
> >> > >
> >> > > Hypothetical #5: A domain name registered through a registrar is
> >> > > used to support the host names of nameservers that provide
> >> > > secondary nameservice fo
> >> > r
> >> > > 20,000 domains held by other customers, which are registered
> >> > > through many different registrars. The registration is not
> >> > > renewed. As a result, nameservice for the 20,000 other domains
> >> > > must be migrated to other hosts. T
> >> > his
> >> > > is not accomplished in 45 days, and as a result 20,000 domains
> >> > > disappear fr
> >> > om
> >> > > the Internet.
> >> > >
> >> > > Hypothetical #6: Shortly after the expiration date of a
> >> > > registration, the registrar is informed that the registrant has
> >> > > filed for bankruptcy. The registrar's legal advisors have
> >> > > cautioned the registrar to refrain from terminating services to
> >> > > the bankrupt registrant without court permission. Recommendations
> >> > > 3.1.1 and 3.1.2, however, require the registrar to delete t
> >> > he
> >> > > registration.
> >> > >
> >> > > Hypothetical #7: During the 45-day period after expiration, the
> >> > > registrant asserts that it has made a renewal payment to the
> >> > > registrar, but the regist
> >> > rar
> >> > > has been unable to complete its investigation into the payment
> >> > > dispute befo
> >> > re
> >> > > the 45-day deadline. The registrar is uncertain whether it must
> >> > > delete the registration in order to comply with 3.1.1 and 3.1.2.
> >> > >
> >> > > Hypothetical #8: The registrar has a long-standing relationship
> >> > > with a registrant; the registrar knows that one of the
> >> > > registrant's domain registrations that has expired is for an
> >> > > important and heavily used name, a
> >> > nd
> >> > > suspects that the registrants' failure to renew was caused by an
> >> > > oversight. The registrar is unable to resolve the issue with the
> >> > > registrant within the 45-day period. As a result, recommendations
> >> > > 3.1.1 and 3.1.2 require the registrar to delete the registration,
> >> > > shutting off nameservice for the doma
> >> > in.
> >> > >
> >> > > Based on a plain reading of the recommendations of 3.1.1 and
> >> > > 3.1.2, in many
> >> >  if
> >> > > not all of these hypothetical cases the registrar would apparently
> >> > > be requi
> >> > red
> >> > > to delete names, even though contrary to technical prudence or
> >> > > even other legal requirements. While it may make sense to
> >> > > prescribe a uniform time fra
> >> > me
> >> > > for registrar deletion of expired names, the hypothetical
> >> > > situations descri
> >> > bed
> >> > > above point to the difficulty of making hard and fast rules
> >> > > without allowin
> >> > g
> >> > > for exceptions in extenuating circumstances.
> >> > >
> >> > > Concern B: The Recommendations Concerning Mandatory Disclosures
> >> > > Inappropriately Restrict Certain Registrar Business Models
> >> > >
> >> > > Recommendations 3.1.4 and 3.1.6 seem to prevent registrars from
> >> > > adapting an
> >> > d
> >> > > evolving their service offerings over time since they mandate that
> >> > > policies and prices be provided "at the time of registration",
> >> > > even though the polic
> >> > ies
> >> > > and prices may not come into effect until after the registration
> >> > > expires (a
> >> > nd
> >> > > after the registrant has the opportunity to transfer to another
> >> > > registrar). These provisions state:
> >> > >
> >> > > "3.1.4 Registrars must provide a summary of their deletion policy,
> >> > > as well as an indication of any auto-renewal policy that they may
> >> > > have, at the time of registration. This policy should include the
> >> > > expected time at which a non-renewed domain name would be deleted
> >> > > relative to the domain's expiration date, or a date range not to
> >> > > exceed ten days in length."
> >> > >
> >> > > "3.1.6 Registrars should provide, both at the time of registration
> >> > > and in a conspicuous place on their website, the fee charged for
> >> > > the recovery of a domain name during the Redemption Grace Period."
> >> > >
> >> > > It is not clear whether registrars would be able to modify their
> >> > > procedures
> >> >  or
> >> > > prices at any time after initial registration of a domain name.
> >> > >
> >> > > Also, recommendations 3.1.5 and 3.1.6 seem to obligate all
> >> > > registrars to operate websites. In some business models currently
> >> > > available to registrars
> >> > ,
> >> > > including reseller models and models used in some regions of the
> >> > > world, registrars do not operate principally through websites, but
> >> > > use other means
> >> >  to
> >> > > communicate with prospective and actual customers. There is no
> >> > > current requirement that registrars operate websites, other than
> >> > > for a web-based Wh
> >> > ois
> >> > > service. These recommendations appear unnecessarily to restrict
> >> > > these alternative registrar business models.
> >> > >
> >> > > Concern C: Mandatory "Payment" Policies Could Stifle Registrar
> >> > > Business Mod
> >> > els
> >> > >
> >> > > Recommendation 3.1.1 (and possibly recommendation 3.1.6) appears
> >> > > to require that registrars charge all customers for registration
> >> > > and RGP services. Som
> >> > e
> >> > > registrars operate business models under which some or all
> >> > > registrants are
> >> > not
> >> > > charged specifically for registration services. In accord with
> >> > > ICANN's mission, Registrar Accreditation Agreement §3.7.10
> >> > > specifically precludes an
> >> > y
> >> > > policy that regulates registrar
> >> > > prices: "Nothing in this Agreement prescribes or limits the amount
> >> > > Registra
> >> > r
> >> > > may charge Registered Name Holders for registration of Registered
> >> > > Names." B
> >> > y
> >> > > requiring that renewals be paid, recommendation 3.1.1 contradicts
> >> > > this principle. Implementation of a requirement that a fee be
> >> > > charged for renewa
> >> > ls
> >> > > would also raise serious concerns under relevant antitrust and
> >> > > competition laws.
> >> > >
> >> > > Concern D: Overlap with Whois Recommendations
> >> > >
> >> > > On 27 March 2003, the ICANN Board adopted four consensus-policy
> >> > > recommendations relating to Whois accuracy and bulk access. One of
> >> > > those recommendations states:
> >> > >
> >> > > "B. When registrations are deleted on the basis of submission of
> >> > > false contact data or non-response to registrar inquiries, the
> >> > > redemption grace period -- once implemented -- should be applied.
> >> > > However, the redeemed domain name should be placed in registrar
> >> > > hold status until the registrant has provided updated WHOIS
> >> > > information to the registrar-of-record."
> >> > >
> >> > > This recommendation is currently early in the implementation
> >> > > process.
> >> > >
> >> > > The Final Report of the Deletes Task Force contains this
> >> > > recommendation on
> >> > the
> >> > > same topic, but proposing a somewhat different policy:
> >> > >
> >> > > "3.3.1 The Redemption Grace Period will apply to names deleted due
> >> > > to a complaint on WHOIS accuracy. However, prior to allowing the
> >> > > redemption in such a case, the registrar must update the
> >> > > registration with verified WHOIS data and provide a statement
> >> > > indicating that the data has been verified in conjunction with the
> >> > > request for the name's redemption. The same rules that apply to
> >> > > verification of WHOIS data for regular domain names following a
> >> > > complaint will apply to deleted names."
> >> > >
> >> > > By proposing overlapping policies so soon after one another, the
> >> > > GNSO would significantly complicate the task of implementing the
> >> > > policies.
> >> > >
> >> > > Thank you for your attention. Please feel free to contact me if
> >> > > you have an
> >> > y
> >> > > questions.
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Louis Touton
> >> > > General Counsel
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >> --
> >> This message was passed to you via the ga@dnso.org list.
> >> Send mail to majordomo@dnso.org to unsubscribe
> >> ("unsubscribe ga" in the body of the message).
> >> Archives at http://www.dnso.org/archives.html
> >
> > Regards,
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
> > ================================================================
> > CEO/DIR. Internet Network Eng. SR. Eng. Network data security
> > Information Network Eng. Group. INEG. INC.
> > E-Mail jwkckid1@ix.netcom.com
> > Contact Number: 214-244-4827 or 214-244-3801
> >
> >
> > --
> > This message was passed to you via the ga@dnso.org list.
> > Send mail to majordomo@dnso.org to unsubscribe
> > ("unsubscribe ga" in the body of the message).
> > Archives at http://www.dnso.org/archives.html
>
> --
> This message was passed to you via the ga@dnso.org list.
> Send mail to majordomo@dnso.org to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 129k members/stakeholders strong!)
================================================================
CEO/DIR. Internet Network Eng. SR. Eng. Network data security
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 214-244-3801



---------------------------------------------------------------------
To unsubscribe, e-mail: atlarge-discuss-unsubscribe@lists.fitug.de
For additional commands, e-mail: atlarge-discuss-help@lists.fitug.de