<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [ga] Re: ICANN & Stability - Motion and second
Jefsey and all assembly members,
I second this motion.
J-F C. (Jefsey) Morfin wrote:
> However it is nice that the father of the Internet, the President of the US
> Government International Agency for the Internet and the Germany NIC
> President relate on this mailing list, I find very sad the reasons why the
> USG root information is no more maintained acurately. BTW this now makes
> the open roots the authoritative source about legacy TLD entries.
>
> A network is a system for everyone to relate together, it is very sad that
> it is today a system for people in charge of the Internet network stability
> to oppose. We - the users - do not want a new Network split.
>
> I therefore submit the following motion to the GA
>
> "
> ICANN is requested to make sure that nameservers IP address changes are
> reflected in the shortest delays (ie less than 36 hours) in the USG root
> servers system master file.
>
> ICANN is requested to keep informed the Internet Global Community if it
> becomes temporarily unable to maintain that minimum level of quality of
> service.
>
> ICANN is requested to present in the shortest delays a secure scheme
> permitting the IP address changes decided by the TLD Managers to be
> incporated into the USG root file in less than 48 hours after recieving the
> TLD Mamager information.
> "
> jfc
>
> On 19:46 24/09/02, Sabine Dolderer/Denic said:
>
> >Dear Stuart,
> >Dear Vint,
> >
> >(-> cc Elisabeth can you please forward my mail to the NC)
> >
> >
> >On 22.09.2002 05:26 "M. Stuart Lynn" <lynn@icann.org> wrote:
> > >
> > > Dear Thomas:
> > >
> > > Thank you for your note and your concern.
> > >
> > > You may be aware of the note (appended) that Vint Cerf and I have
> > > sent to the Names Council. We believe it is important to have a
> > > considered technical review of this issue that takes all viewpoints
> > > into consideration.
> > >
> > > Stuart
> > > _____________
> > >
> > > Dear Names Council:
> > >
> > > Over the past few weeks, questions have arisen regarding the IANA
> > > practice of obtaining and reviewing TLD zone files at the time of
> > > changes in the nameservers listed for the TLD in the root zone. The
> > > various points of view expressed suggest to us that it would be
> > > productive to re-examine the objectives for this practice and to
> > > consider alternative means by which those objectives might be reached.
> > > The principal motivation for this practice has been to improve the
> > > quality of the DNS service by validating the format of the
> > > TLD zone files to ensure correct configuration.
> >
> >you should also mention that there are views validating the format of
> >zonefiles has no technical value, is not needed and can therefore be
> >skiped.
> >
> > >
> > > Considering that this examination has until now tended to be done by
> > > the IANA only when a TLD nameserver is being transferred to a new
> > > operating site, we believe it is appropriate to ask the Committee on
> > > Security and Stability (SAC) to look into the matter and to develop a
> > > longer-term recommendation as to what would be the most sound technical
> > > practices to follow to promote better DNS stability; and to provide an
> > > interim recommendation while the broader issues are being explored.
> > > Since this, however, involves domain names, we would want to enquire
> > > whether the DNSO concurs with this approach before asking the SAC to
> > > undertake this analysis.
> >
> >Technical stability of DNS relys much more on the realtime performance of
> >the related server and a timly and redundant answering from different
> >places in the Internet. These things have nothing to do with zonefile
> >information but with long term monitoring and underlying network
> >infrastructure. But even this is in my opinion up to the operator of a TLD
> >and his community.
> >
> > >
> > > Historically, the goal of the practice has been to improve the
> > > quality of data in the DNS. Pursuing the RFC 1591 policy that the
> > > IANA should make checks to verify nameserver "operational status and
> > > database accuracy",
> >
> >The only database which IANA has to maintain is the database who operates
> >which TLD and what are the related nmameservers. For DE this information is
> >DENIC and a set of nameservers. To check the operational status of our
> >nameservers before entering them in the IANA database you simply has to ask
> >them if they felt authorativ for .de (dig @dns.denic.de .de). I am not
> >aware of other databases which IANA maintain and which they have to check
> >for accuracy.
> >
> > > the IANA follows the practice of obtaining
> > > and technically reviewing TLD zone files as part of the technical checks
> > > it performs when nameserver changes are requested. Although checks for
> > > the most severe database misconfigurations can be performed by other
> > > means, many less severe errors have been detected through this review.
> > > The ordinary result of finding one or more of these less severe errors
> > > is to proceed with the root-zone change, to alert the ccTLD manager of
> > > the error, and to request that it be remedied.
> >
> >If a ccTLD manager wants to optain additional service from IANA like
> >assistance in error checking then it has to be discussed and can be done as
> >long as it didn't took too much ressources. For professional assistance
> >these kind of consultancy services should be left to others like Men &
> >Mice or others who offer these kind of services on a professional
> >commercial base.
> >
> > >
> > > DNS data accuracy continues to be an important, and by some measures
> > > increasingly urgent, goal. Recent "Domain Health" surveys conducted
> > > by Men & Mice <http://menandmice.com/6000/6350_eu_survey.html> and
> > > <http://menandmice.com/6000/61_recent_survey.html> have reported
> > > surprisingly high performance error rates in reviews of subdomains
> > > within various TLDs.
> >
> >As Men & Mice is a commercial company offering DNS configuration assistance
> >I am sure that they will welcome your support for their service ;-).
> >
> > > While DNS quality at the TLD level appears to
> > > be much better, discussions at the November 2001 ICANN security
> > > meeting and the Domain Health surveys have demonstrated that it is
> > > important that the community work continuously to maintain and improve
> > > DNS quality.
> >
> >I am sure that you have also learned from that survey that the .DE-zone is
> >quit healthy and thats why we are doing some checks similar to those I
> >discribed above. But we are doing this without checking the zonefile as
> >this - as I pointed out earlier - not needed for the check of DNS quality.
> >
> > > Particularly with increasing requirements from the broader
> > > society for security and trustworthiness within the DNS, it is important
> > > for the ICANN community to develop and implement practices that promote
> > > high-quality DNS data at all levels, and with a higher frequency than
> > > only at times when nameserver changes are contemplated.
> >
> >I am not really convinced. Usually one tries to have a balance between the
> >benefits and the costs of something. Currently a gTLD-level and a lot of
> >ccTLDs there are no checks at all when a domain is inserted in the TLD.
> >DENIC does at least check our delegated domains for nameserver consitency
> >but we didn't check if siemens.de or ibm.de are doing this also. I have
> >some understanding that IANA does also check nameserver consistency at
> >their level and I would recommend to siemens.de and ibm.de to do that also.
> >But I don't think it's DENIC's task to enforce this within siemens.de and
> >ibm.de and I don't think it's IANA's to do so for .de.
> >
> > >
> > > Although with cooperation from the TLD managers (which has historically
> > > been quite high)
> >
> >Historically the DNS software was unable to supress unsolicited
> >zonetransfers and the TLD managers were not asked (at least not between
> >1994 and now, when I am operating it). You shouldn't interpret this a
> >cooperation.
> >
> > > the current IANA practice has served to locate and
> > > allow correction of many DNS errors, recently four TLD managers have
> > > denied the IANA download access to the zone files for their TLDs.
> > > Without having the zone files, there is no reasonably practical method
> > > for a third party to perform some checks of database accuracy.
> >
> >As you have no access to our database it is unclear to me how you want to
> >perform checks if the zonefile we produce is reflecting our database
> >correct.
> >
> > > This
> > > disagreement has resulted in an unfortunate standoff situation that,
> > > perversely, frustrates attempts to locate and correct TLD configuration
> > > errors, and at the same time potentially introduces additional DNS data
> > > errors through configuration mismatches between the DNS data in the root
> > > zone (which remains unchanged) and the affected TLD zones (assuming the
> > > TLD manager proceeds to change the TLD zone).
> > >
> > > This debate has prompted some very helpful initial ideas from the
> > > community regarding possible changes in practices that might be better
> > > suited to achieve the goal of improved DNS data accuracy. As pointed
> > > out by Thomas Roessler
> > > <http://www.dnso.org/clubpublic/ga/Arc11/msg00206.html>, the current
> > > timing of technical checks may not be optimally suited to the goal
> > > of improving DNS data quality. As one of us (Stuart) has pointed
> > > out, a strong argument can be made that TLD integrity checks would
> > > be more effective, and the process for making root-zone updates
> > > streamlined, by developing a possibly distributed and delegated process
> > > for performing TLD zone-file reviews on a periodic basis
> > > rather than as part of technical checks performed at the time of
> > > nameserver changes.
> > > <http://www.dnso.org/clubpublic/ga/Arc11/msg00210.html>
> >
> >I think you should also point out in your summary that also while some
> >(Stuart) suggested to performe these checks periodically. Some (CENTR,
> >LACTLD, ccTLD constituency at their meeting in Bucharest, and others on the
> >lists) suggest to stop checking the zones immediately.
> >
> > >
> > > It appears to us that the issues about what practices should be
> > > followed by the IANA, TLD managers, and other participants in the
> > > ICANN process to promote improved DNS data quality is one that is ripe
> > > for examination. We believe that technical focus of these issues
> > > makes it appropriate to have at least the initial examination and
> > > analysis conducted by the ICANN Security and Stability Advisory
> > > Committee.
> >
> >One big step to improve DNS data quality is to proceed changes in the root
> >much more timely.
> >
> > >
> > > Because the issues also concern domain names (the focus of the DNSO),
> > > however, we would like feedback about whether the Names Council believes
> > > for any reason that it is inappropriate that they be referred to the
> > > Security and Stability Advisory Committee. Because an early resolution
> > > of these issues would be helpful to all concerned, we would appreciate
> > > your considering the appropriateness of the referral at your earliest
> > > convenience.
> >
> >As this issue is very important for ccTLDs I would also recommend not to
> >decide things without their support.
> >
> >
> >Sabine
> >
> > >
> > > Our mutual interest is to take the opportunity occasioned by these
> > > discussions to encourage the development of more effective methods for
> > > improving DNS data quality at all levels in the system.
> > >
> > > Regards,
> > >
> > > Vint Cerf
> > > Chairman
> > >
> > > Stuart Lynn
> > > President and CEO
> > > _______________
> > > --
> > >
> > > At 3:49 PM +0200 9/19/02, Thomas Keller wrote:
> > > >This mail is being sent on behalf of the Technical Advisory Council of
> > > >DENIC (TACD) which represents the .de registrar community.
> > > >
> > > >Dear Stuart,
> > > >
> > > >with dismay the TACD has noticed that the crucial and long awaited
> > > >changes of the root name servers for the zone .de have not taken place
> >to the
> > > >current day. It even appears that the whole process has come to a stop
> >due to
> > > >misunderstandings between ICANN in fulfillment of its IANA functions and
> > > >the Board of DENIC as well as other ccTLD registries.
> > > >
> > > >To judge about the reasons of the current misunderstanding is out of the
> > > >scope of the TACD but the TACD strongly believes that a mere dispute can
> >not
> > > >be a reason for ICANN to deny a simple technical implementation for any
> >ccTLD
> > > >registry as long as this registry is acting in favor of the local
> >internet
> > > >community.
> > > >
> > > >Therefore the TACD would like to emphasize DENICs request to perform the
> > > >necessary steps as soon as possible.
> > > >
> > > >Please note that not performing the requested changes is not only a
> > > >severe political issue but also jeopardizes the german Internet related
> >and
> > > >Internet dependent industries. All internet business, not only in
> >Germany, is
> > > >built on a foundation of trust that all Internet services are
> > > >reliable and dealt
> > > >with in a highly responsible manner. For the DNS as one of these
> > > >services, if not
> > > >the most important one, not updating the root name servers is
> >endangering
> >this
> > > >trust and might lead to cutbacks of Internet related business,
> > > >impacting guiltless
> > > >companies and employees. This is a situation which cannot be tolerated
> >by
> > > >TACD nor by the DENIC community which TACD represents.
> > > >
> > > >Out of the above mentioned reasons the TACD wants to urge ICANN to
> >rethink
> >its
> > > >position on this issue and move their political playing field towards a
> >ground
> > > >where no uninvolved party may be harmed.
> > > >
> > > >Tom Keller on behalf of the Technical Advisory Council of DENIC
> > > >
> > > >-
> > > >
> > > >Thomas Keller
> > > >
> > > >Domain Services
> > > >Schlund + Partner AG
> > > >Erbprinzenstr. 4 - 12 Tel.
> > > >+49-721-91374-534
> > > >76133 Karlsruhe, Germany Fax
> > > >+49-721-91374-215
> > > >http://www.schlund.de tom@schlund.de
> > > >
> > > >
> > > >
> > > >
> > > >Am 16.09.2002 schrieb M. Stuart Lynn:
> > > >> You are assuming, Danny, that the assumptions that underlie
> > > >> Elisabeth's proposed resolution are correct. They are not. Perhaps
> > > >> you might be interested in the facts before forming your
> > > >> "impressions".
> > > >>
> > > >> There is no threat to Internet stability. Soon after KPNQwest
> > > >> announced its suspension of operations, RIPE NCC agreed to assume
> > > >> operation of the ns.eu.net nameserver (which had formerly been
> > > > > operated by KPNQwest), and has committed to continue that operation
> > > > > for as long as necessary to migrate secondary nameservice to other
> > > >> nameservers. That nameserver has been operating for quite some time
> > > >> in a sound and stable manner. The IANA has given priority to
> > > >> handling requests to migrate from the KPNQwest nameservers, and as it
> > > >> happens 38 of the 41 requests that have been received to migrate
> > > >> nameservice from ns.eu.net have been satisfactorily completed.
> > > >> (Incidentally, 37 of the 38 ccTLDs that have been migrated have no
> > > >> contractual relationship with ICANN.) There are several other ccTLDs
> > > >> that have not yet requested to migrate, and the IANA is in the
> > > >> process of suggesting that they move along to suitable substitute
> > > >> nameservice as well. Three of the ccTLD requests for migration have
> > > >> not yet been completed because the ccTLD operators have (despite
> > > >> repeated requests) failed to cooperate in allowing the IANA to
> > > >> perform technical checks as provided by longstanding IANA policy.
> > > >> See the FAQs at <http://www.iana.org/faqs/tld-zone-access-faq.htm>
> > > > > for a description that we recently posted summarizing for ccTLD
> > > >> managers the policy, its longstanding basis (documented back to RFC
> > > >> 1591 in March 1994), and the means by which those seeking to change
> > > >> the policy should proceed.
> > > >>
> > > >> To reiterate, however, there no threat whatsoever to Internet
> > > >> stability, since the ns.eu.net nameserver continues to function
> > > >> perfectly.
> > > >>
> > > >> Stuart
> > > >>
> > > >>
> > > >> At 4:05 PM -0400 9/16/02, DannyYounger@cs.com wrote:
> > > >> >Stuart,
> > > >> >
> > > >> >Having read the text of Elisabeth Porteneuve's proposed resolution
> >on
> >name
> > > >> >server updates (reprinted below), I can't help but get the
> >impression
> >that
> > > >> >either ICANN/IANA staff is thoroughly incompetent or that you are
> >engaged
> > > >> >in
> > > >> >the process of blackmailing the ccTLD community. It would seem to
> >me
> >that
> > > >> >some discussion on this topic is warranted as the assertion has been
> >made
> > > >> >that ICANN itself has threatened the stability of the Internet (a
> >subject
> > > >> >that I presume you would take seriously). As the President and
> >Chief
> > > >> >Executive Officer of this Corporation, that ostensibly deems the
> >stability
> > > >> >of
> > > >> >the Internet to be its highest priority, can you comment on why your
> >
> >staff
> > > >> >has failed to process these updates?
> > > >> >
> > > >> >Best regards,
> > > >> >Danny
> > > >> >
> > > >> >
> > > >> >Whereas the ICANN Evolution and Reform Committee (ERC) has published
> > > >> >its second implementation report,
> > > >>
> > >
> > >http://www.icann.org/committees/evol-reform/draft-mission-core-values-02s
> > ep02.
> >
> > > >> >
> > > >> >htm
> > > >> >
> > > >> >Whereas the stability of the universal Internet has been part of
> > > >> >permanent preoccupations since the White Paper document,
> > > >> >http://www.icann.org/general/white-paper-05jun98.htm
> > > >> >
> > > >> >Whereas on 28 November 1998, both the USG and the ICANN committed
> > > >> >to abide by the principle of Internet stability in the MoU,
> > > >> >http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm
> > > >> >
> > > >> >Whereas the ccTLD Managers has been awaiting since years
> > > >> >for correct IANA ccTLD database services, as explicitly specified
> > > >> >in the Amendment 2 to the MoU of 11 September 2000, requesting
> > > >> >for "Documentation of IANA procedures for root zone editing,
> > > >> >root zone generation, and root zone WHOIS service".
> > > >> >
> > > >> >Whereas the ccTLD IANA Service Requirements has been restated
> > > >> >once more in Bucharest on 25 June 2002 and approved unanimously,
> > > >>
> > >http://www.dnso.org/constituency/cctld/ccTLDbucharest-communique.html
> > > >> >
> > > >> >Whereas the ERC reaffirms that "Preserve and enhance the operational
> > > > > >stability, reliability, security, and global interoperability of
> > > >> >the Internet" is on top of the list of ICANN Core's values,
> > > >> >
> > > >> >Whereas the global interoperability and stability of Internet
> >depends
> > > >> >on the TLD name servers,
> > > >> >
> > > >> >Whereas the recent bankruptcy of KPNQwest, providing secondary
> > > >> >services to several ccTLD Registries requested for prompt actions
> > > >> >on IANA side to update the name servers records as requested by
> > > >> >the ccTLD Managers,
> > > >> >
> > > >> >Whereas there is widespread dissatisfaction of ccTLD Managers about
> > > >> >the ICANN failing to its IANA Function duty, and several name
> >servers
> > > >> >updates pending since three months (since June 2002),
> > > >> >
> > > >> >The NC therefore resolves that:
> > > >> >The stability of universal Internet is in danger and request
> > > >> >ICANN to take immediate actions to update ccTLD name servers
> >entries.
> > > >> >
> > > >> >http://www.dnso.org/clubpublic/council/Arc11/msg00035.html
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> __________________
> > > >> Stuart Lynn
> > > >> President and CEO
> > > >> ICANN
> > > >> 4676 Admiralty Way, Suite 330
> > > >> Marina del Rey, CA 90292
> > > >> Tel: 310-823-9358
> > > >> Fax: 310-823-8649
> > > >> Email: lynn@icann.org
> > > >> --
> > > >> 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
> > > >>
> > > >
> > > >gruss
> > > >
> > > >tom
> > > > O /
> > > > /| o
> > > > / \ \|/
> > > > wenn ein kind eine blume pflueckt ist das schoen.
> > > > wenn alle kinder eine blume pfluecken ist die wiese leer.
> > > >
> > > >
> > > >
> > > >Content-Type: application/pgp-signature
> > > >Content-Disposition: inline
> > > >
> > > >Attachment converted: Macintosh HD:Untitled (????/----) (000738DB)
> > >
> > >
> > > --
> > >
> > > __________________
> > > Stuart Lynn
> > > President and CEO
> > > ICANN
> > > 4676 Admiralty Way, Suite 330
> > > Marina del Rey, CA 90292
> > > Tel: 310-823-9358
> > > Fax: 310-823-8649
> > > Email: lynn@icann.org
> > > --
> > > 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
> > >
> > >
> >--
> >Sabine Dolderer
> >DENIC eG
> >Wiesenhüttenplatz 26
> >D-60329 Frankfurt
> >
> >eMail: Sabine.Dolderer@denic.de
> >Fon: +49 69 27235 0
> >Fax: +49 69 27235 235
> >
> >
> >--
> >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
> >
> >
> >
> >---
> >Incoming mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/02
Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
--
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|