[Internal-cg] Draft webinar deck and outline
Elise Gerich
elise.gerich at icann.org
Tue Jul 28 15:06:15 UTC 2015
Hi Martin,
Thanks for the confirmation that the CWG proposal does not replace the
NTIA¹s operational authorization role.
Perhaps the slide deck could be revised to remove the text that indicates
that the CSC was ³established to perform the operational responsibilities
previously performed by the U.S. Government.² That would avoid any possible
misinterpretation that the CSC would have an active role in operations.
-- Elise
From: Martin Boyle <Martin.Boyle at nominet.org.uk>
Date: Tuesday, July 28, 2015 at 3:47 AM
To: Elise Gerich <elise.gerich at icann.org>, Mary Uduma <mnuduma at yahoo.com>,
Russ Mundy <mundy at tislabs.com>, Paul Wilson <pwilson at apnic.net>
Cc: IANA etc etc Coordination Group <internal-cg at ianacg.org>
Subject: RE: [Internal-cg] Draft webinar deck and outline
> Hi Elise,
>
> No! This would be a change from the CWG¹s proposal. The CWG¹s approach was
> to avoid replacing the NTIA¹s administrative and clerical role by something
> that might become a gatekeeper.
>
> There is an authorisation role for more changes affecting root-zone management
> architecture and operation (such as, in the past, the introduction of DNSSEC),
> but that was more about a process for such changes documented in the section
> at paragraph 154 et seq.
>
> Hope this helps, Elise,
>
> Martin
>
>
>
> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Elise
> Gerich
> Sent: 27 July 2015 17:54
> To: Mary Uduma; Russ Mundy; Paul Wilson
> Cc: IANA etc etc Coordination Group
> Subject: Re: [Internal-cg] Draft webinar deck and outline
>
>
> All,
>
>
>
> Slide 13 states that the mission of the Customer Standing Committee (CSC) is
> ³Established to perform the operational responsibilities previously performed
> by the U.S. Government, ensure continues satisfactory performance of the IANA
> naming function."
>
>
>
> One of the operational responsibilities of NTIA today is to authorize changes
> to the root zone. It was my understanding from the CWG proposal that the
> ³authorization² responsibility of root zone changes would go away. Is this
> slide implying that the CSC will have an operational role authorizing root
> zone changes?
>
>
>
> Regards,
>
> -- Elise
>
>
>
>
>
> From: Internal-cg <internal-cg-bounces at ianacg.org> on behalf of Mary Uduma
> <mnuduma at yahoo.com>
> Reply-To: Mary Uduma <mnuduma at yahoo.com>
> Date: Monday, July 27, 2015 at 12:14 AM
> To: Russ Mundy <mundy at tislabs.com>, Paul Wilson <pwilson at apnic.net>
> Cc: IANA etc etc Coordination Group <internal-cg at ianacg.org>
> Subject: Re: [Internal-cg] Draft webinar deck and outline
>
>
>>
>> All,
>>
>> Quite happy with the webinar deck. In addition to the points already raised
>> by others, I wish to suggest the following
>>
>> 1. Explanation of the lines, the straight and the broken ones. (New Comers)
>>
>> 2. Few of the acronyms in the diagram be explained for the uninformed.
>>
>> 3 Further adjustment on slide 28 regarding the numbers and the protocol
>> relationship with the ICANN and IFO. While the Protocol shows connection from
>> IETF pointing to PTI (Vmetrics), the Numbers (Review Performance) points to
>> ICANN. There is no broken line between the Numbers and PTI unlike the Names
>> and the Protocols diagrams.
>>
>> I am glad to receive clarifications, if I am wrong on my point 3.
>>
>>
>>
>> By the way, would the deck be adjusted for each audience? When addressing
>> community like the ccTLDs for example.
>>
>>
>>
>> Great work, folks.
>>
>>
>>
>> Mary Uduma
>>
>>
>>
>>
>> On Monday, July 27, 2015 5:59 AM, Russ Mundy <mundy at tislabs.com> wrote:
>>
>>
>>
>> On Jul 26, 2015, at 8:17 PM, Paul Wilson <pwilson at apnic.net> wrote:
>>
>>> > For slide 3, let¹s rely on the term ³Registry² rather than ³Database² or
>>> ³Info². Registry is commonly used, and carries the implications of
>>> structure and purpose which are missing from the alternatives.
>>
>> I agree that Registry is the commonly used term in the Numbers and Protocol
>> Parameters realms but not in the Names realm.
>>
>>> >
>>> > For numbers, the label should be ³Numbers Registries², like ³Protocol
>>> Parameters Registries².
>>
>> I would be fine with these terms for those two OCs.
>>
>>> >
>>> > Personally I also prefer ³Names Registries² or ³Root Zone Registry² - but
>>> I would defer to those responsible to make the call on that.
>>
>> The highly visible DNS information handled and published by IANA is
>> predominantly related to the Root Zone and (as Patrik points out) is
>> generally of two types, i.e., direct Root Zone content related info and whois
>> info. The whois info could be considered a Œregistry¹ but that¹s not how it
>> is usually referred to, it¹s simply called Œwhois¹ information.
>>
>> The Root Zone content information handled by IANA in filling it¹s role in the
>> Root Zone Management process is not 'IANA registry¹ information like the
>> Numbers and Protocol Parameters OCs. There are multiple reasons for this not
>> the least of which is that IANA is not the authoritative source of this
>> information in the running DNS. The root name servers provide the
>> authoritative root zone information for the running DNS and they receive the
>> zone content from Verisign in their role as Root Zone Maintainer. So in
>> addition to the Root Zone not being like Registries in the Names and Protocol
>> Parameters OCs, the Root Zone in the running DNS is not usually thought of or
>> described as an IANA Registry.
>>
>> I don¹t think that the slide deck should try to differentiate between Root
>> Zone content and whois information but I think we need a single, collective
>> term or phrase that describes both types of information - (probably obvious)
>> I don¹t think ŒRoot Zone Registries¹ is the a viable phrase, I hope we can
>> come up with a better one.
>>
>> Russ
>>
>>
>>
>>> >
>>> > Paul.
>>> >
>>> >
>>> >
>>> >
>>> > On 27 Jul 2015, at 9:58, Patrik Fältström wrote:
>>>> >> On 27 Jul 2015, at 0:27, Russ Mundy wrote:
>>>> >>
>>>>> >>> Folks,
>>>> >>
>>>> >> I have a few comments on this...
>>>> >>
>>>>> >>> -- Change "Make Change Requests" to "Submit Requests" . Many but not
>>>>> all requests are for changes so "Change" should be dropped (also change
>>>>> Slide 10).
>>>> >>
>>>> >> Hmmm....I think it is fair to say "change" as all requests do imply
>>>> changes to the "databases". Some are changes to the data, some are
>>>> unallocations and some are new allocations. But all are changes.
>>>> >>
>>>>> >>> -- Some of the information provided by the OCs is maintained in
>>>>> databases but calling everything a "Database" is simply not accurate.
>>>>> This is particularly true for the Root Zone Maintainance process but the
>>>>> other OCs also have some information that are not accurately called
>>>>> "Database". I suggest the following renaming:
>>>> >>
>>>> >> I am not as picky as you regarding the use of the term "database", and
>>>> specifically:
>>>> >>
>>>>> >>> --- Change "Names Database" to "DNS Root Zone Info" (also change
>>>>> Slide 10)
>>>> >>
>>>> >> ...I think this would be confusing as people might think all requests
>>>> related to names have to do with "the root zone", which I think it is
>>>> correct to say that some of the requests are related to the whois service
>>>> and not the root zone.
>>>> >>
>>>> >> Now, whether "DNS root zone info" include not only the root zone itself
>>>> but also the whois database and other things, that is to complicated the
>>>> slide deck too much.
>>>> >>
>>>> >> Patrik
>>>> >> _______________________________________________
>>>> >> Internal-cg mailing list
>>>> >> Internal-cg at mm.ianacg.org
>>>> >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org
>>> >
>>> > ________________________________________________________________________
>>> > Paul Wilson, Director-General, APNIC dg at apnic.net
>>> > http://www.apnic.net <http://www.apnic.net/>
>>> @apnicdg
>>
>>
>> _______________________________________________
>> Internal-cg mailing list
>> Internal-cg at mm.ianacg.org
>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20150728/8f626ac1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5037 bytes
Desc: not available
URL: <http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20150728/8f626ac1/attachment.p7s>
More information about the Internal-cg
mailing list