[Internal-cg] Draft webinar deck and outline
Alissa Cooper
alissa at cooperw.in
Wed Jul 29 16:51:47 UTC 2015
Hi Elise, all,
This text came from the slides that the CWG co-chairs used in Buenos Aires.
Would it make sense to say the following instead?
"Established to ensure continued satisfactory performance of the IANA naming functions."
Or, we could take words directly from paragraph 106 of the CWG proposal:
“Established to monitor the performance of the IANA naming functions and escalate non-remediated issues."
Thoughts?
Alissa
On Jul 28, 2015, at 8:06 AM, Elise Gerich <elise.gerich at icann.org> wrote:
> 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 @apnicdg
>>>
>>> _______________________________________________
>>> Internal-cg mailing list
>>> Internal-cg at mm.ianacg.org
>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org
>>>
>>>
> _______________________________________________
> 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/20150729/a13fb504/attachment.html>
More information about the Internal-cg
mailing list