Subject: GA-DIGEST V1 #1690
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST             Friday, May 9 2003             Volume 01 : Number 1690

----------------------------------------------------------------------

Date: Fri, 9 May 2003 10:00:48 -0500
From: Don Brown <[email-masked]>
Subject: Re: [ga] Posting rights of Jeff Williams suspended for 14 days.

There will always be people who you may think a jerk, as well as those
who you may feel offer nothing more than liking to hear themselves
speak.  That, however, is a matter of personal prospective and it is
well within the power of each of us to simply not read their messages.

Everyone in the community should have the unfettered right to be heard
- - even those that babble, those we don't like and those that deliver
messages to which we disagree. Yes - even Jeff Williams and Joe
Baptista, should not be restricted in the delivery of their messages,
regardless of our individual or collective perception of their value
or worthlessness.

Censorship is not appropriate and doesn't belong in the same solar
system as the terms "open" and "transparent." We impeach our own
process, by singling out certain people for censorship or
disenfranchising any member of the community.

Tuesday, May 6, 2003, 2:46:07 AM, Stephane Bortzmeyer <[email-masked]> wrote:
SB> On Mon, May 05, 2003 at 05:30:03PM +0100,
SB>  Richard Henderson <[email-masked]> wrote 
SB>  a message of 143 lines which said:

>> "ALAC, whose goal is to legitimitize the total elimination of public
>> representation on the Board of ICANN"... yep... the whole point of ALAC is
>> to minimise and contain the impact of the internet user community and to
SB> ...
>> ICANN is regarded with disdain because it is perceived as a self-serving
>> clique of insiders, working on behalf of the US Government,
SB> ...
>> The comments of Jeff Williams were insubstantial.

SB> I hope that nobody will accuse me of defending the US government or
SB> its front in Marina del Rey but you raise an important point: besides
SB> Jeff Williams' empty and useless contributions, there is the issue of
SB> "at large" involvment (I use lowercase to emphasize that I talk about
SB> the concept of "at large" participation, not the actual attempts by
SB> ICANN to organize it.)

SB> IMHO, there is still no serious way to build a real democracy online:
SB> the various "at large" attempts are a proof by experience that the
SB> situation is not ready yet. This GA list is a typical
SB> example. Discussions are focused on the intense activities of a few
SB> trolls like Joe Baptista. Although some people like Vittoria Bertola
SB> and yourself try to stay calm and to express their views in a way that
SB> reasonable people could read and understand, and although these
SB> reasonable people are probably the majority, nervertheless, the
SB> debates revolve around a few jerks which are not connected to any
SB> actual practice.

SB> Not having any responsability, they can work full-time sending
SB> messages on the GA list, screaming "censorship" and "fascism" at every
SB> possible opportunity.

SB> I have no suggestions at the present time. I just wanted to
SB> acknowledge that the ICANN at least tried (and failed). I strongly
SB> hope that the idea of an Internet democracy will raise again and will
SB> be successful next time but I have no idea how.

>> mentality which could be seen as institutionally fascist and arrogant.

SB> Here, I agree with Vittorio: the real fascists are people who kill,
SB> torture and mutilate. They do not try to silence you by suspending
SB> your posting rights on a mailing list for two weeks. They shoot you
SB> right now. Calling the administrators of this mailing list "facists"
SB> is a insult to the victims of the real fascists. (It's like saying
SB> "genocide" for every murder: you blur the responsability of the real
SB> genociders.)

SB> --
SB> This message was passed to you via the [email-masked] list.
SB> Send mail to [email-masked] to unsubscribe
SB> ("unsubscribe ga" in the body of the message).
SB> Archives at http://www.dnso.org/archives.html

- ----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
[email-masked]         http://www.inetconcepts.net
PGP Key ID: 04C99A55              (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
- ----

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 9 May 2003 10:01:47 -0500
From: Don Brown <[email-masked]>
Subject: Re: [ga] Reminder of GA List Moderation Guidelines

I haven't seen any response to this and I'm curious, as well.

Tuesday, May 6, 2003, 5:41:43 AM, Abel Wisman <[email-masked]> wrote:
AW> Ross, and list,

AW> When Thomas's chairmanship of the list ended, simultaneous with the end
AW> of the GA and GNSO, "interim" moderators were announced, being Ross W
AW> Rader and me.

AW> Ross once decided to suspend posting privs without notifying or
AW> conferring with me, this was an oversight that was not to happen again
AW> (according to Ross, in whom I have faith).

AW> For me however the strangest part has been that I was never given any
AW> access to the list' workings in order to either suspend or end
AW> suspension, nonetheless I was appointed moderator.

AW> The suspension of JW was not discussed with me, my opinion not sought
AW> and done by someone who supposedly no longer should or could be a
AW> moderator of this list.

AW> I would dearly like clarification of this matter.

AW> Kind regards

AW> Abel Wisman

AW> -----Original Message-----
AW> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Wm.
AW> Rader
AW> Sent: 06 May 2003 00:19
AW> To: [email-masked]
AW> Subject: [ga] Reminder of GA List Moderation Guidelines

AW> Folks,

AW> Over the last 24 hours there has been a lot of conversation regarding
AW> moderation of the GA-List. 

AW> First, I'd like to point out that most of this traffic has been
AW> off-topic. 

AW> Second, I'd like to remind everyone that there are moderation guidelines
AW> in place that everyone, by virtue of having subscribed to this list, has
AW> agreed to play by. My hope is that moderation on this list will be found
AW> in your respective capabilities to engage in a modest level of
AW> self-control and respect for one another. Failing that, imposed
AW> moderation will continue to be the default rule. 

AW> From: http://www.dnso.org/mailinglists.html

AW> 1. Anybody interested in the [GNSO] issues may subscribe to this list,
AW> only subscribers may write to this list 
AW> 2. Two main principles since the origin of this server in June 1999,
AW> explained in the welcome message sent by majordomo to every new
AW> subscriber: 
AW>  - the non cross-posting rule is reinforced 
AW>  - the respect of participants is mandatory 
AW> 3. More explicit rules of order defined in
AW> http://www.dnso.org/dnso/notes/2000.GA-ga-rules.html 
AW> 4. More about GA list monitoring in
AW> http://www.dnso.org/dnso/notes/GA.list-monitoring.html 
AW> 5. Currently, there is a limit of FIVE postings per day on the GA
AW> mailing list 
AW> 6. To subscribe (or unsubscribe) to the General Assembly list, please
AW> send an email to [email-masked] with the words subscribe ga (or
AW> unsubscribe ga) in the body of the message. 

AW>                        -rwr

AW> "People demand freedom of speech as a compensation for the freedom of
AW> thought which they seldom use."
AW> - Soren Kierkegaard

AW> Get Blog... http://www.byte.org/

AW> --
AW> This message was passed to you via the [email-masked] list.
AW> Send mail to [email-masked] to unsubscribe
AW> ("unsubscribe ga" in the body of the message).
AW> Archives at http://www.dnso.org/archives.html

AW> --
AW> This message was passed to you via the [email-masked] list.
AW> Send mail to [email-masked] to unsubscribe
AW> ("unsubscribe ga" in the body of the message).
AW> Archives at http://www.dnso.org/archives.html

- ----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
[email-masked]         http://www.inetconcepts.net
PGP Key ID: 04C99A55              (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
- ----

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 9 May 2003 10:17:43 -0500
From: Don Brown <[email-masked]>
Subject: Re: [ga] Re: Even Handed Application of The Rules (Yes or No? - We shall see)  (was Re: [ga] Posting rights of Jeff Williams suspended for 14 days).

Take note that this process narrowly applies to a DoS of the consensus
building process.  That's very different from censorship.

Are you saying that Jim Fleming is guilty of such an infraction WRT
the GA list (if so, I disagree) or are you just, again, preaching your
personal prospective that Jim Fleming is a jerk?

Note that the "group" "votes" on the actions.

Wednesday, May 7, 2003, 3:36:12 AM, Stephane Bortzmeyer <[email-masked]> wrote:
SB> On Wed, May 07, 2003 at 11:05:02AM +1200,
SB>  Joop Teernstra <[email-masked]> wrote 
SB>  a message of 26 lines which said:

>> BTW, as a matter of interest, a poll among icannatlarge listmembers 
>> revealed that more than 63% are in favor of a mailing list with Rules.
>> The comments are of interest.
>> http://www.icannatlarge.com/results-may4a.htm

SB> It may be interesting also to read the attached Internet-Draft which
SB> is proposed to the IETF (background: anyone can write an
SB> Internet-Draft, as its name suggest, they have no official value) to
SB> deal with jerks. Since some are common to the IETF and to the GA
SB> mailing list (Jim Fleming...), it is interesting reading:

SB> Network Working Group                                            M. Rose
SB> Internet-Draft                              Dover Beach Consulting, Inc.
SB> Expires: November 2, 2003                                    May 4, 2003

SB>       A Practice for Revoking Posting Rights to IETF mailing lists
SB>                       draft-mrose-ietf-posting-02

SB> Status of this Memo

SB>    This document is an Internet-Draft and is in full conformance with
SB>    all provisions of Section 10 of RFC2026.

SB>    Internet-Drafts are working documents of the Internet Engineering
SB>    Task Force (IETF), its areas, and its working groups. Note that other
SB>    groups may also distribute working documents as Internet-Drafts.

SB>    Internet-Drafts are draft documents valid for a maximum of six months
SB>    and may be updated, replaced, or obsoleted by other documents at any
SB>    time. It is inappropriate to use Internet-Drafts as reference
SB>    material or to cite them other than as "work in progress."

SB>    The list of current Internet-Drafts can be accessed at http://
SB>    www.ietf.org/ietf/1id-abstracts.txt.

SB>    The list of Internet-Draft Shadow Directories can be accessed at
SB>    http://www.ietf.org/shadow.html.

SB>    This Internet-Draft will expire on November 2, 2003.

SB> Copyright Notice

SB>    Copyright (C) The Internet Society (2003). All Rights Reserved.

SB> Abstract

SB>    All self-governing bodies have ways of managing the scope of
SB>    participant interaction. The IETF uses a consensus-driven process for
SB>    developing computer-communications standards in an open fashion. An
SB>    important part of this consensus-driven process is the pervasive use
SB>    of mailing lists for discussion. Notably, in a small number of cases,
SB>    a participant has engaged in a "denial-of-service" attack to disrupt
SB>    the consensus-driven process. Regrettably, as these bad faith attacks
SB>    become more common, the IETF needs to establish a practice that
SB>    reduces or eliminates these attacks. This memo recommends such a
SB>    practice for use by the IETF.

SB> Rose                    Expires November 2, 2003                [Page 1]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> Table of Contents

SB>    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
SB>    2. A Revocation Practice  . . . . . . . . . . . . . . . . . . . .   4
SB>    3. Q & A  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
SB>    4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .   8
SB>    5. Security Considerations  . . . . . . . . . . . . . . . . . . .   9
SB>       Normative References . . . . . . . . . . . . . . . . . . . . .  10
SB>       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  10
SB>       Intellectual Property and Copyright Statements . . . . . . . .  11

SB> Rose                    Expires November 2, 2003                [Page 2]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> 1. Introduction

SB>    All self-governing bodies have ways of managing the scope of
SB>    participant interaction. For example, deliberative assemblies often
SB>    employ "rules of order" for determining who gets to speak, when, and
SB>    for how long. Similarly, there is widespread agreement in so-called
SB>    "liberal" societies that the right to free speech is not absolute,
SB>    e.g., political speech is given more leeway than commercial speech,
SB>    and some forms of speech (e.g., egregious libel or incitement to
SB>    violence) are considered unacceptable.

SB>    The IETF uses a consensus-driven process for developing
SB>    computer-communications standards in an open fashion. An important
SB>    part of this consensus-driven process is the pervasive use of mailing
SB>    lists for discussion. Unlike many other organizations, anyone may
SB>    post messages on those IETF mailing lists, and in doing so,
SB>    participate in the IETF process. Historically, this approach has
SB>    worked very well in the IETF, as it fosters participation from a wide
SB>    range of stakeholders.

SB>    Notably, in a small number of cases, a participant has engaged in a
SB>    "denial-of-service" attack to disrupt the consensus-driven process.
SB>    Typically, these attacks are made by repeatedly posting messages that
SB>    are off-topic, inflammatory, or otherwise counter-productive. In
SB>    contrast, good faith disagreement is a healthy part of the
SB>    consensus-driven process.

SB>    For example, if a working group is unable to reach consensus, this is
SB>    an acceptable, albeit unfortunate, outcome; however, if that working
SB>    group fails to achieve consensus because it is being continuously
SB>    disrupted, then the disruption constitutes an abuse of the
SB>    consensus-driven process. Interactions of this type are fundamentally
SB>    different from "the lone voice of dissent" in which a participant
SB>    expresses a view that is discussed but does not achieve consensus. In
SB>    other words, individual bad faith should not trump community
SB>    goodwill.

SB>    Guidelines have been developed for dealing with abusive behavior
SB>    (c.f., Section 6.1 of [1] and [2]). In practice, the application of
SB>    those guidelines has included the temporary suspension of posting
SB>    rights to a specific mailing list. If necessary, the length of the
SB>    suspension has been increased with each successive suspension. In
SB>    many cases, applying those guidelines will produce the desired
SB>    modification in behaviour. However, as these bad faith attacks become
SB>    more common and the desired modification in behaviour fails to be
SB>    forthcoming, the IETF needs to establish a practice that directly
SB>    reduces or eliminates these attacks.

SB> Rose                    Expires November 2, 2003                [Page 3]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> 2. A Revocation Practice

SB>    Please refer to [3] for the meaning conveyed by the uppercase words
SB>    in this section.

SB>    As a part of its activities, the Internet Engineering Steering Group
SB>    (IESG) votes on "actions". Typically, an action refers to the
SB>    publication of a document on the standards-track, the chartering of a
SB>    working group, and so on. This memo recommends that the IESG also
SB>    undertake a new type of action, termed a PR-action.

SB>    A PR-action identifies one or more individuals, citing messages
SB>    posted by those individuals to an IETF mailing list, that appear to
SB>    be abusive of the consensus-driven process. If approved by the IESG,
SB>    then:

SB>    o  those identified on the PR-action have their posting rights to
SB>       that IETF mailing list removed; and,

SB>    o  maintainers of any IETF mailing list may, at their discretion,
SB>       also remove posting rights to that IETF mailing list.

SB>    Once taken, this action remains in force until explicitly nullified
SB>    and MUST remain in force for at least one year.

SB>    One year after the PR-action is approved, a new PR-action MAY be
SB>    introduced which restores the posting rights for that individual. The
SB>    IESG SHOULD consider the frequency of nullifying requests when
SB>    evaluating a new PR-action. If the posting rights are restored the
SB>    individual is responsible for contacting the owners of the mailing
SB>    lists to have them restored.

SB>    Regardless of whether the PR-action revokes or restores posting
SB>    rights, the IESG follows the same algorithm as with its other
SB>    actions:

SB>    1.  it is introduced by an IESG Area Director (AD), who, prior to
SB>        doing so, may choose to inform the interested parties;

SB>    2.  is is published as an IESG last call on the IETF general
SB>        discussion list;

SB>    3.  it is discussed by the community;

SB>    4.  it is discussed by the IESG; and, finally,

SB>    5.  it is voted upon by the IESG.

SB> Rose                    Expires November 2, 2003                [Page 4]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB>    Of course, as with all IESG actions, the appeals process outlined in
SB>    [4] may be invoked to contest a PR-action approved by the IESG.

SB>    Finally, working groups SHOULD ensure that their associated mailing
SB>    list is manageable. For example, some may try to circumvent the
SB>    revocation of their posting rights by changing email addresses.

SB> Rose                    Expires November 2, 2003                [Page 5]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> 3. Q & A

SB>    Q: Isn't a year too long?

SB>    A: No.

SB>       An initial PR-action is not undertaken lightly. It is approved
SB>       only after a period of substantive consideration and community
SB>       review. If a PR-action is approved, then this indicates that a
SB>       serious situation has arisen.

SB>    Q: Why not require one PR-action per IETF mailing list?

SB>    A: To do so would enable a prolonged series of denial-of-service
SB>       attacks.

SB>       If someone is poorly-behaved on one IETF mailing list, but
SB>       well-behaved on another, then the maintainer for the second IETF
SB>       mailing list needn't revoke posting rights. However, the more
SB>       likely scenario is that someone who behaves poorly on one IETF
SB>       mailing list is unwilling to be well-behaved on any IETF mailing
SB>       list.

SB>    Q: Should the initiation of a PR-action come from outside the IESG?

SB>    A: Informally, sure; formally, no.

SB>       Under the IETF's consensus-driven process, IESG actions are always
SB>       formally initiated by an IESG Area Director (AD). In practice, the
SB>       motivation for an IESG member to initiate an action almost always
SB>       comes from outside the IESG. For example, when a working group
SB>       (WG) reaches consensus on a document, the WG chair informs the
SB>       relevant AD that the document is ready for the AD to consider it
SB>       for a document action. In the case of this document -- an IETF
SB>       individual submission -- the author will iteratively circulate the
SB>       document for wide discussion and make revisions. At some point,
SB>       the author will contact an AD and ask for a document action to
SB>       publish this document as a Best Current Practice (BCP).

SB>    Q: Is this censorship?

SB>    A: Only if you believe in anarchy.

SB>       What is important is that the rules surrounding PR-actions exhibit
SB>       the same properties used by the rest of the consensus-based
SB>       process.

SB> Rose                    Expires November 2, 2003                [Page 6]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB>    Q: C'mon! You really are a closet fascist.

SB>    A: No, I'm a libertarian.

SB>       Frankly, I would prefer that people behave reasonably and act in
SB>       good faith. Since my first involvement with the IETF (nee GADS,
SB>       circa 1983), everyone understood that reasonable behavior was a
SB>       good thing. After 20 years, I regret to inform you that this step
SB>       is inevitable.

SB> Rose                    Expires November 2, 2003                [Page 7]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> 4. Acknowledgements

SB>    The author gratefully acknowledges the contributions of: Brian
SB>    Carpenter, Jim Galvin, Jeff Haas, and Bert Wijnen.

SB> Rose                    Expires November 2, 2003                [Page 8]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> 5. Security Considerations

SB>    This memo deals with matters of process, not protocol.

SB> Rose                    Expires November 2, 2003                [Page 9]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> Normative References

SB>    [1]  Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
SB>         25, RFC 2418, September 1998.

SB>    [2]  Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005,
SB>         November 2000.

SB>    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
SB>         Levels", BCP 14, RFC 2119, March 1997.

SB>    [4]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
SB>         9, RFC 2026, October 1996.

SB> Author's Address

SB>    Marshall T. Rose
SB>    Dover Beach Consulting, Inc.
SB>    POB 255268
SB>    Sacramento, CA  95865-5268
SB>    US

SB>    Phone: +1 916 483 8878
SB>    EMail: [email-masked]

SB> Rose                    Expires November 2, 2003               [Page 10]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB> Intellectual Property Statement

SB>    The IETF takes no position regarding the validity or scope of any
SB>    intellectual property or other rights that might be claimed to
SB>    pertain to the implementation or use of the technology described in
SB>    this document or the extent to which any license under such rights
SB>    might or might not be available; neither does it represent that it
SB>    has made any effort to identify any such rights. Information on the
SB>    IETF's procedures with respect to rights in standards-track and
SB>    standards-related documentation can be found in BCP-11. Copies of
SB>    claims of rights made available for publication and any assurances of
SB>    licenses to be made available, or the result of an attempt made to
SB>    obtain a general license or permission for the use of such
SB>    proprietary rights by implementors or users of this specification can
SB>    be obtained from the IETF Secretariat.

SB>    The IETF invites any interested party to bring to its attention any
SB>    copyrights, patents or patent applications, or other proprietary
SB>    rights which may cover technology that may be required to practice
SB>    this standard. Please address the information to the IETF Executive
SB>    Director.

SB> Full Copyright Statement

SB>    Copyright (C) The Internet Society (2003). All Rights Reserved.

SB>    This document and translations of it may be copied and furnished to
SB>    others, and derivative works that comment on or otherwise explain it
SB>    or assist in its implementation may be prepared, copied, published
SB>    and distributed, in whole or in part, without restriction of any
SB>    kind, provided that the above copyright notice and this paragraph are
SB>    included on all such copies and derivative works. However, this
SB>    document itself may not be modified in any way, such as by removing
SB>    the copyright notice or references to the Internet Society or other
SB>    Internet organizations, except as needed for the purpose of
SB>    developing Internet standards in which case the procedures for
SB>    copyrights defined in the Internet Standards process must be
SB>    followed, or as required to translate it into languages other than
SB>    English.

SB>    The limited permissions granted above are perpetual and will not be
SB>    revoked by the Internet Society or its successors or assignees.

SB>    This document and the information contained herein is provided on an
SB>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
SB>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
SB>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

SB> Rose                    Expires November 2, 2003               [Page 11]

SB> Internet-Draft    Revocation Practice: IETF Mailing Lists       May 2003

SB>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
SB>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

SB> Acknowledgement

SB>    Funding for the RFC Editor function is currently provided by the
SB>    Internet Society.

SB> Rose                    Expires November 2, 2003               [Page 12]

SB> --
SB> This message was passed to you via the [email-masked] list.
SB> Send mail to [email-masked] to unsubscribe
SB> ("unsubscribe ga" in the body of the message).
SB> Archives at http://www.dnso.org/archives.html

- ----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
[email-masked]         http://www.inetconcepts.net
PGP Key ID: 04C99A55              (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
- ----

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 9 May 2003 11:58:05 -0500
From: "Jim Fleming" <[email-masked]>
Subject: [ga] 0:242     SHOP...THREE .SHOP TLD Clusters ?

http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
0:242     SHOP
http://www.dnso.org/wgroups/wg-c/Arc01/msg01542.html
"After extensive public review, there was clear consensus to change .store to .shop."
====

It looks like interest in .SHOP names is very high and that there are THREE .SHOP TLD Clusters
for the 32-bit DNS Proof-of-Concept phase.

http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=shop&submit=Submit

BORN : Business Oriented Root Network : 213.70.103.18
VueDig Results : Answer = 0 : Authority = 3 : Additional = 3. 
shop. 2D IN NS hk.universalroot.com.
shop. 2D IN NS uk.universalroot.com.
shop. 2D IN NS us.universalroot.com.

NSpace : Name.Space : 209.48.2.11
VueDig Results : Answer = 6 : Authority = 0 : Additional = 6. 
shop. 1D IN NS NS10.AUTONO.NET.
shop. 1D IN NS ROOT3.AUTONO.NET.
shop. 1D IN NS NS10.ROOT-ZONE.NET.
shop. 1D IN NS A.TLD-SERVERS.NET.
shop. 1D IN NS B.TLD-SERVERS.NET.
shop. 1D IN NS NS.AUTONO.NET.

Nnet : New.net Inc : 206.132.100.42
VueDig Results : Answer = 4 : Authority = 0 : Additional = 4. 
shop. 2H IN NS tld4.newdotnet.net.
shop. 2H IN NS tld1.newdotnet.net.
shop. 2H IN NS tld2.newdotnet.net.
shop. 2H IN NS tld3.newdotnet.net.
==============================

http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
0:242     SHOP

http://www.dnso.org/wgroups/wg-c/Arc01/msg01542.html
"After extensive public review, there was clear consensus to change .store to .shop."
====

http://dot.com.shop
http://dot.com.shop.new.net

http://domain.shop
http://domain.shop.new.net

http://new.chat
http://new.chat.new.net/viewtopic.php?t=118
DAY 10 (Monday 05/05/03) 
.SHOP

Jim Fleming
http://www.IPv8.info
0:242     SHOP

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

End of GA-DIGEST V1 #1690
*************************