[Internal-cg] ICG FAQ ..

Kavouss Arasteh kavouss.arasteh at gmail.com
Tue Sep 30 12:12:35 UTC 2014


Manal
Martin
Further to my previous questions WHICH YET TO BE ASNWERED .
I RAISE THE FOLLOWING
AT PRESENT TIME

"

*2. Administrative Functions Associated with Root Management.*

*A second important aspect* *of the IANA function involves administrative
functions associated with management of the authoritative domain-name
system (DNS) root**. Under the leadership of Dr. Postel, the IANA team
undertook the project of delegating 243 of the country-code top-level
domains (ccTLDs) listed (except for grandfathered cases) on ISO 3166-1
(three more ccTLDs are still undelegated). These 243 ccTLDs, in conjunction
with the seven generic top-level domains (gTLDs), and the special, legacy
second-level domain, in-add.arpa, make up the root zone of the DNS that is
disseminated to thirteen root name servers deployed throughout the world.*

*Continuing maintenance of this root zone involves a variety of
administrative functions that are key to maintaining the stable operation
of the DNS. These tasks involve, first, maintenance of accurate records not
only of the root-zone file information (i.e. correspondence of TLDs to host
computers providing authoritative name service for those domains) but also
of detailed contact information so that persons seeking second-level
domains know who to contact and so that problems with a particular TLD can
be quickly resolved. Routine requests for technical changes are made by the
delegated operators of ccTLDs and the IANA/ICANN team has developed various
means of verifying the authenticity of these requests based on its
familiarity with the various operators. The IANA/ICANN team is experienced
in working closely with Network Solutions, which currently generates the
authoritative root-zone file and operates the root-zone Whois service, and
with the U.S. Department of Commerce, which approves various changes to the
root-zone file. ICANN proposes to continue processing routine requests for
technical changes in the root-zone file and root-zone contact information
in the same manner as is currently done, subject to changes in procedures
agreed with the U.S. Department of Commerce Government consistent with
ICANN's MOU with that agency.*

*A second aspect* *of the administrative tasks associated with root
management is receiving requests for redelegation of existing TLDs and,
where new TLDs are created, for initial delegation. **After receiving the
request**, the IANA investigates the circumstances of the request,
evaluates its conformity with the relevant guidelines as contained in ICANN
Corporate Policy (ICP-1), reports the results to the U.S. Department of
Commerce, and if appropriate recommends a course of action on the request.
Often a key stability-enhancing technique is the mediation of delegation
disputes, which the ICANN staff has performed frequently, resulting in
nearly all disputes being resolved by a consensual solution.*

*At this stage in the U.S. Government's transition to private-sector-led
technical management of the Internet, the U.S. Department of Commerce acts
on delegation and redelegation requests by giving approval as appropriate
to changes in root-zone files and associated information. **Nothing in the
current contract contemplates any change in the IANA's role with respect to
authorizing modifications, additions, or deletions to the root-zone file or
associated information that constitute delegation or redelegation of
top-level domains; **those issues are to be dealt with under the MOU
between ICANN and the U.S. Department of Commerce and past and future
amendments to that MOU.*

*Actions by the U.S. Department of Commerce on delegation and redelegation
requests are made after reviewing reports submitted by the IANA, which
makes the reliability of the reports especially vital. The ICANN team is
uniquely situated to perform the investigation and reporting function based
on its unequalled familiarity with ccTLD delegees worldwide, familiarity of
precedents in prior delegation and redelegation situations, and
longstanding reputation for handling requests impartially and in a manner
that promotes the benefits of the Internet worldwide.*

*A third aspect** of the administrative tasks associated with root
management is coordination with the operators of the thirteen root
nameservers deployed throughout the world. **ICANN is closely involved with
the operation of the root nameservers**, **and this relationship will
permit it to facilitate a stable transition from the current system of
volunteer (but nonetheless highly professional) operation to a more
accountable and formally documented system. ICANN itself operates one of
the root nameservers ("L"), one of ICANN's nineteen directors (Jun Murai)
is involved in the operation of another ("M"), and ICANN works closely with
USC-ISI's staff, which operates another ("B"). In addition, ICANN's Root
Server System Advisory Committee has as its members the operators of all
thirteen root nameservers. ICANN proposes to work collaboratively through
the Committee to develop a set of contracts between ICANN and each operator
that will permit stable evolution and enhancement of the procedures under
which the root nameserver system is operated" *

*Questions *

*After transition who and how and under what accountability terms the above
tasks are envisaged to be done*

*Regards*

*KAVOUSS .*

*'*


2014-09-30 13:15 GMT+02:00 Manal Ismail <manal at tra.gov.eg>:

>  Many thanks Martin .. I've noted your concern on Q9 1/2 and added the
> sentence you proposed to Q14's answer .. I have incorporated all comments,
> to my best, in the attached version and in Dropbox .. Hope this reflects
> accurately what has been suggested ..
>
> I'm not clear about the modifications you are suggesting for Q15 & Q16, so
> apologies for that ..
>
>
>
> I also recall that we, the drafting group, have agreed to share a clean
> version with ICG colleagues, so if you have comments pending from earlier
> drafting iterations appreciate adding them or letting me know ..
>
>
>
> Kind Regards
>
> --Manal
>
>
>
> *From:* Martin Boyle [mailto:Martin.Boyle at nominet.org.uk]
> *Sent:* Tuesday, September 30, 2014 12:41 PM
> *To:* Manal Ismail
> *Cc:* Milton L Mueller; internal-cg at icann.org
> *Subject:* Re: [Internal-cg] ICG FAQ ..
>
>
>
> I agree with Manal's concern on the final sentence of Q9 1/2.  Better
> might be to look at the level of support for the position and the way the
> community proposal addresses the issue.
>
>
>
> On Q14 is it worth adding after the first sentence that, "Operational
> communities have been asked to consider oversight and accountability in
> their proposals."
>
>
>
> For Q15, Manal is right about running behind the moving train. But I now
> realise that the answer is very ICANN centric!  In part this is corrected
> in the next question, but I would suggest that  this question should look
> at the operational communities and those directly engaged with them (GAC,
> ALAC...), while the next question could then refer to addressing those who
> do not take part, but will be affected - the business community, ccTLDs
> that are not in ICANN etc
>
> Sent from my iPhone
>
>
> On 30 Sep 2014, at 10:48, "Manal Ismail" <manal at tra.gov.eg> wrote:
>
>  Many thanks Milton ..
>
> Noted ..
>
> Further comments inline below ..
>
>
>
> Kind Regards
>
> --Manal
>
>
>
> *From:* Milton L Mueller [mailto:mueller at syr.edu <mueller at syr.edu>]
> *Sent:* Tuesday, September 30, 2014 3:13 AM
> *To:* Manal Ismail; internal-cg at icann.org
> *Subject:* RE: ICG FAQ ..
>
>
>
> Manal et al
>
>
>
> Good start.
>
>
>
> I would propose the following modifications.
>
>
>
> Add a new           question between #9 and #10, which I here label 9 ½ :
>
>
>
> *9 ½ Can I submit my own proposal for how the IANA transition should take
> place? *
>
>
>
> You can, but the ICG is not authorized to pick and choose among competing
> proposals. That would centralize the authority over the IANA transition in
> ICG’s hands, and the general preference is for a bottom up, consensual
> process. If you submit a proposal directly to the ICG without participating
> in the processes convened by the operational communities, all the ICG can
> do is forward that proposal to the relevant OCs. If you think your ideas
> have been ignored or not fairly treated in the OC proposal development
> process, you can express this view directly to the ICG or in the public
> comment period. But the ICG cannot give these objections any weight if the
> person made no effort to participate in the operational community-convened
> process.
>
>
>
> [MI]: Noted .. will add it to the new version that is to be circulated
> shortly .. Although, personally, I would be reluctant to leave the last
> sentence "But the ICG cannot give these objections any weight if the
> person made no effort to participate in the operational community-convened
> process." .. I think it's a bit negative and I don't think it adds ..
>
>
>
> On *Question 14*, I found the answer not very meaningful. I would propose
> the following alternative language:
>
>
>
> ICG is closely following ICANN Accountability Process
> <https://community.icann.org/category/accountability>. After receiving
> consensus proposals from the operational communities, ICG will conduct an
> analysis of their overall implications for ICANN accountability. If there
> are gaps or problems, ICG will check to see whether these gaps are filled
> by the results of the ICANN enhanced accountability process. If they are
> not, ICG will return the proposals to the relevant operational
> community(ies) for amendment.
>
>
>
> [MI]: Happy to replace with your proposed language .. Looking forward to
> other reactions as this is one of the few questions we did not discuss
> thoroughly and have no agreed position on ..
>
>
>
> On *Question 15*, “How is ICG reaching out?”  I would delete the language
> “ICG members have participated in the IANA stewardship transition session
> <http://london50.icann.org/en/schedule/thu-iana-stewardship-transition>
> held at the ICANN 50 meeting in London, and
>
> If someone asks that question now they don’t care what we did 3-4 months
> ago. They want to know what we are doing now.
>
>
>
> [MI]: Noted .. although soon after, this will also become a past event.
>
>
>
> *From:* internal-cg-bounces at icann.org [
> mailto:internal-cg-bounces at icann.org <internal-cg-bounces at icann.org>] *On
> Behalf Of *Manal Ismail
> *Sent:* Monday, September 29, 2014 2:16 PM
> *To:* internal-cg at icann.org
> *Subject:* [Internal-cg] ICG FAQ ..
>
>
>
> Dear All ..
>
>
>
> Please find attached, and in dropbox, a draft FAQ we (Martin, Patrik,
> Mohamed, Alissa & myself) have prepared to be discussed on the upcoming
> call ..
>
> This is supposed to be a living document ..  So the target is to come up
> with an initial agreed version rather than an exhaustive complete one ..
>
>
>
> Looking forward to receiving your feedback over email and/or during the
> call ..
>
>
>
> Kind Regards
>
> --Manal
>
>  _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
>
>
> _______________________________________________
> Internal-cg mailing list
> Internal-cg at icann.org
> https://mm.icann.org/mailman/listinfo/internal-cg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140930/7c78373e/attachment.html>


More information about the Internal-cg mailing list