RE: [ga] I want to be on the Inclusive Name Space SIG ML

["Dassa" <dassa@dhs.org>]

|> -----Original Message-----
|> From: owner-ga-full@dnso.org
|> [mailto:owner-ga-full@dnso.org]On Behalf Of
|> Patrick Corliss
|> Sent: Tuesday, April 17, 2001 1:03 AM
|> To: Darryl Lynch
|> Cc: Marc Schneiders; ga@dnso.org
|> Subject: Re: [ga] I want to be on the Inclusive Name Space SIG ML
|>
|>
|> On Tuesday, April 17, 2001 12:00 AM (AEST), Marc Schneiders wrote:
|> Subject: RE: [ga] I want to be on the Inclusivbe Name Space SIG ML
|>
|>
|> > The point is of course the term 'cooperative'. The so-called
legacy
|> > root has hardly any history of cooperation, no has none at all.

The RFC archives are evidence this view is not correct.  You and I may
not have been involved but there were a number of people who were and
they cooperated and reached agreement to bring about the formation of
the legacy name space.

|> > There is no agreement whatsoever. The status quo is imposed by
the USG
|> > and its contractors, including ICANN. All the rest is window
dressing.

I tend to agree with the last part of the above but still deny it
gives anyone the right to dictate to the legacy name space what it can
and can't do with regards to private name space TLD's and the
introduction of new TLD's into the public name space.

|> > Marc Schneiders
|> >
|> > On Mon, 16 Apr 2001, at 11:36 [=GMT+1000], Dassa wrote:
|>
|> Hi Darryl
|>
|> There are, as I understand it, about 300 people on this
|> list.  Their understanding ranges from abysmal to expert.  Some may
|> have only just joined a day or so ago.

To quote from http://www.dnso.org/dnso/notes/2000.GA-ga-rules.html
"The participants in the GA should be individuals who have a knowledge
of and an interest in issues pertaining to the areas for which the
DNSO has primary responsibility, and who are willing to contribute
time, effort and expertise to the work of the DNSO, including work
item proposal and development, discussion of work items, draft
document preparation, and participation in research and drafting
committees and working groups."

As such I would not expect any participant to have an abysmal
understanding of the issues or the history but your point is noted.

|> I remember you on the <discuss-list@opensrs.org> mailing
|> list in June last year
|> and on the <idno-discuss@idno.org> list in December.  We
|> also corresponded
|> privately about the Australian Tax system back in
|> September.  We may have also
|> met on the Australian mailing lists, perhaps [DNS] or
|> [LINK] or both.  You are
|> certainly pretty competent.

Thank you, I do not have all the knowledge I would like but am
competent in finding the information I need.

|> I think, therefore, it is only fair to point out that many people
are not
|> familiar with the quite complex tripartite agreements
|> between ICANN, DoC and Verisign (formerly known as NettSol) and in
particular the
|> separation between the Registry and Registrar functions or indeed
how any of
|> that relates to the operator of the "A" root.

I have posted a list of RFC numbers that if those who are interested,
read them, they will gain some historical knowledge of the legacy name
space.  For more recent information they may off course continue
reading through to the latest RFC's and visit the ICANN web site and
all the alternative sites that are mentioned in the archives.  I
imagine the majority would read through the archives to gain some
background information once they join the GA.

|> Indeed several ccTLDs have argued, in Melbourne and
|> elsewhere, about the nature
|> of their responsibility to Jon Postel-IANA-ICANN
|> especially when being invoiced.

That is another issue.

|> The RFCs are also under attack in several respects.  This
|> takes us back to RFC1074 and it's successor - RFC1591.

Do not understand the reference above, RFC 1591 does not appear to be
directly related to 1074.

|> Of course RFC1591 has been challenged by
|> many on this list and now there is a new RFC3071 which has
|> raised other interesting issues.

To quote from 3071, "Therefore, it may be useful to try to reconstruct
1591's principles and think about their applicability today as a model
that could continue to be applied: not because it is historically
significant, but because many of its elements have proven to work
reasonably well, even in difficult situations."

That would appear to be applicable and may encourage more to revisit
both RFC 1591 and 3071.

For those interested a URL to the applicable RFC's is:
http://www.faqs.org/rfcs/rfc-activeV.html

|> I have personally asked several members of the ICANN Board
|> whether there is any
|> policy on alt roots.  Apparently there is none.  Others
|> have said that alt.roots
|> should not be created unless they follow the specs defined
|> by the IETF and the IAB.

The creation of private name spaces (alt.roots) is a different issue
to the creation of additional TLD's within the public name space
(legacy DNS).

|> In this regard, Simon Higgs has said:
|>
|> > There are no valid specs. That's the point. RFC2826 is
implausible deniability
|> > for the existence of alt.roots. The IAB think that if they
convince everyone
|> > that alt.roots don't exist, then the problems that created them
will go away.
|> > Wrong answer.

RFC 2826 doesn't say the private name spaces do not exist.  It
acknowledges them and defines their role, they are not alternative
name spaces within the public name space but private name spaces
outside of the public name space.  They may or may not link into the
public name space.  I do agree the problems that created these private
name spaces in the way they have developed over the last few years
does need addressing.  Assigning special rights to any TLD's created
in the private name spaces is in my humble opinion, not the way to do
so.  To do so is to revert to an anarchy system.  Anyone can create a
private name space, once you assign special rights to one group, it
would be hard to contain the flow.

|> In these circumstances in really behoves everyone to be
|> specific in their claims
|> especially when referring to RFCs and Internet Drafts,
|> etc.  Your comment was:
|>
|> > > Try the relevent RFC and the history archives.  Not all
agreements are
|> > > explicity written either.

Which is a perfectly valid response to the generalised question asked.
The archives of the RFC's evidence a continued history of cooperation
and agreement in the building of the legacy name space, starting at
236 (the first reference I find applicable).  To point to specific
RFC's numbers was not necessary.

|> I'd ask you, and others on the list, to move this debate
|> along constructively by saying exactly what you mean, quoting
references and
|> providing necessary links.

I can quote references and provide all the links in the world, so can
others.  The history is well documented.  It is not always necessary,
especially when dealing with a generic question that only requires a
generic answer.

|> Otherwise we are just wasting time arguing from opinion
|> and analogy.

The majority of it is opinion and interpretation.  We can all read the
same RFC's and come away with a different understanding.  The point of
this forum is to share our opinions and if we feel so inclined to back
those opinions up with information to support them.  It is a forum to
share and come to an understanding of the other perspective held by
participants and reach consensus.  It is not a debating society.

Which brings me to the 5 a day posting limit and the call for
additional mailing lists.

I would suggest the GA may benefit from having an unrestricted (no
posting limits) mailing list for the full dissemination of ideas and
responses.  With a 5 a day posting limit and only one mailing list it
is very difficult to respond to replies of postings.  I feel that the
posting limit forces discussion to private mail and is causing the
mailing list to miss a substantial amount of useful sharing.

Darryl (Dassa) Lynch.

--
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