DNSO Mailling lists archives


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [council] changing the subject line: A different suggestion than voting on conclusions...

I agree.
Ellen B. Shankman, Adv.
Partner, Trademark Group
Telephone +972-9-9709026
Fax +972-9-9709001
Email - shankmane@technologylaw.co.il
Please visit our Resource and Research center at:

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.  If you received
this in error, please contact the sender and delete the material from any

> -----Original Message-----
> From:	Bruce Tonkin [SMTP:Bruce.Tonkin@melbourneit.com.au]
> Sent:	Thu, April 04, 2002 3:37 AM
> To:	'Cade,Marilyn S - LGA'; J. Scott Evans; NC (list); Philip Sheppard
> Subject:	RE: [council] changing the subject line:  A different
> suggestion  than voting on conclusions...
> I agree - we should avoid voting on conclusions at this stage.  Especially
> when the constituencies are still formulating their own positions.
> It would be better to just summarise the current points of views in the
> minutes for now.  That in itself is useful.
> I will be on the teleconference call this evening.
> Regards,
> Bruce Tonkin
> 	-----Original Message-----
> 	From: Cade,Marilyn S - LGA [mailto:mcade@att.com]
> 	Sent: Thursday, April 04, 2002 1:24 AM
> 	To: J. Scott Evans; NC (list); Philip Sheppard
> 	Subject: [council] changing the subject line: A different suggestion
> than voting on conclusions...
> 	Folks, 
> 	After reading Philip's summation again, and offering some edits to
> it, and now reading J.Scott's suggestion,  I offer a suggestion which I
> hope can help to move us all past this issue.
> 	I don't think that we should be voting on conclusions at all at this
> stage of our work together. I didn't take Philip's summary as anything
> other than an effort to provide a draft statement but I don't think that
> we are "there" yet in terms of voting on any conclusions at this stage.   
> 	How about agreeing that  the chair can put forward what he thinks
> might be a DRAFT summary OF INITIAL conclusions [did I give that enough
> options?] OR EVEN "PRELIMINARY FINDINGS" then we can discuss whether there
> is "general concurrence", document that, and then we need to move on and
> have discussions about the next issue. 
> 	In short, I do not support voting on "conclusions" at this stage of
> our discussions.  Let me explain why:  If we vote on conclusions at this
> stage on a progressive schedule,  and then as we discuss the next topic,we
> learn something which changes the viewpoint, we will have to go back,
> rediscuss, revote, etc.
> 	It appears that a further discussion of "mission" is needed to
> support further work. I would welcome seeing  proposed mission ideas.  
> 	In the BC, we have a pretty good sense of where most of our members
> are on " mission" but we are still in consultation. I suspect we are
> "typical" in that status.  
> 	I must say that I didn't take the same kind of work assignment that
> the IPC did out of the discussion, but instead the BC will focus in on the
> existing mission and the summary of work to build comments from. )
> However, our existing principles and positions already taken would
> indicate that we would likely continue support for the existing mission
> and activities, and maintaining consistency with the principles of the
> White Paper...  BUT, as I said, we are taking further consultation, as all
> of us are.  :-)
> 	Regards, Marilyn
> 	 -----Original Message-----
> 	From: J. Scott Evans [mailto:jse@adamspat.com]
> 	Sent: Wednesday, April 03, 2002 7:50 AM
> 	To: NC (list); Philip Sheppard
> 	Subject: Re: [council] Conclusions to call no on ICANN Evolution
> 	Importance: High
> 		Philip:
> 		I have just reviewed the "Conclusions to call on ICANN
> Evolution" below.  Perhaps I missed something on our call; however, I do
> not remember any consensus.  In fact, I specifically remember that you
> suggested that the constituencies provide a written idea of ICANN's
> mission for consideration by the NC members.  I certainly never agreed to
> the formulation of ICANN's mission that you have presented in your
> summary.  I do remember discussing the "What ICANN does" paper.  I also
> remember you pointing out that I seemed to be happy with ICANN's current
> functions as laid out in that paper.  I did not and do not now disagree
> with that summarization of my opinion.  On the other hand, I find it
> problematic that you have formulated what appears to be a mission
> statement when I do not remember any agreement on this issue.  Secondly, I
> do not remember the NC ever agreeing on either concept that you have
> labeled "Recommendations" in your report.  I do remember some discussion
> on these issues, but I believe that it is an overstatement to say they are
> NC recommendations.
> 		I have no problem with you attempting to move the
> discussions along.  I do, however, find it disturbing that your
> characterizations are far more conclusive than I remember our discussions
> being.  In fact, I reported to the IPC that we ( the IPC) needed to put
> together a written proposal on our view of ICANN's mission for submission
> to the NC.  Accordingly, many members of our constituency have worked long
> hours to put together the necessary document.  I now look a bit foolish
> when the NC Chair subsequently posts a document purporting to set forth
> conclusions from the NC call which, frankly, I think overstate the
> position and do not accurately reflect the discussion on the NC call.
> 		I therefore request that the agenda for tomorrow's call be
> amended to include a discussion of your report and then we can vote on
> whether it is the NC's position.
> 		Regards.
> 		J. Scott Evans
> 			----- Original Message ----- 
> 			From: Philip Sheppard
> <mailto:philip.sheppard@aim.be> 
> 			To: NC (list) <mailto:council@dnso.org> 
> 			Sent: Wednesday, April 03, 2002 2:36 AM
> 			Subject: [council] Conclusions to call no on ICANN
> Evolution
> 			Council,
> 			Following input from Thomas Roessler and Marilyn
> Cade, I am happy to adopt their suggested wording (last two paragraphs) as
> friendly amendments and propose the following as conclusions to our first
> call. In order to make progress I will assume the NC agrees to this unless
> I hear to the contrary before the start of our next call.
> 			Philip
> 			---------------------
> 			DRAFT version 2
> 			Scope and mission of ICANN
> 			In broad terms the NC agreed with the factual
> description of ICANN's functions listed in "What ICANN Does" at:
> <http://www.icann.org/general/toward-mission-statement-07mar02.htm> 
> 			"ICANN is responsible for coordinating the
> Internet's naming, address allocation, and protocol parameter assignment
> systems. These systems enable globally unique and universally
> interoperable identifiers for the benefit of the Internet and its users.
> 			ICANN's paramount concern is the stability of these
> services. 
> 			ICANN's role includes both operational and
> policymaking functions. "
> 			The ICANN note specifies that ICANN's operations (in
> broad summary) cover:
> 			1. General operational functions (such as IP address
> allocation, maintaining the DNS root zone file).
> 			2. gTLD administrative functions (such as registrar
> accreditation, supervising the Uniform Dispute Resolution Policy). 
> 			3. ccTLD administrative functions (such as requests
> for delegation and redelegation).
> 			4. Policy coordination for infrastructure security.
> 			5. Policymaking including:
> 			  5.1. IP address and AS number allocation,
> 			  5.2  ccTLD global policy coordination,
> 			  5.3. Protocol numbering via the IANA registries,
> 			  5.4 gTLD registry-level policies.
> 			The Names Council specified the following existing
> functions of ICANN where the NC would like ICANN to do better in carrying
> them out:
> 			- ccTLD administrative functions
> 			- root server administration
> 			- Registry and Registrar contract enforcement with
> respect to intellectual property and other existing conditions.
> 			Recommendation 1: Create clearly delineated
> divisions within ICANN responsible for the administration of certain
> technical functions. This would  establish separate staff functions for
> policy and  operational functions. 
> 			The Names Council felt that the greatest danger of
> mission creep lay in the areas of security and consumer protection. The
> creation of infrastructure for at-large membership was also mentioned;
> however, it was also argued that this topic should not be discussed
> alongside with ICANN's functions.
> 			Recommendation 2. ICANN's functions should not be
> extended beyond what is outlined in the note "What ICANN Does" .

<<< Chronological Index >>>    <<< Thread Index >>>