[Internal-cg] Draft webinar deck and outline
Elise Gerich
elise.gerich at icann.org
Wed Jul 29 17:04:02 UTC 2015
Hi Alissa,
Thanks for proposing alternate text. I think either of the two suggested
revisions would be an improvement.
-- Elise
From: Alissa Cooper <alissa at cooperw.in>
Date: Wednesday, July 29, 2015 at 9:51 AM
To: Elise Gerich <elise.gerich at icann.org>
Cc: Martin Boyle <Martin.Boyle at nominet.org.uk>, Mary Uduma
<mnuduma at yahoo.com>, Russ Mundy <mundy at tislabs.com>, Paul Wilson
<pwilson at apnic.net>, IANA etc etc Coordination Group
<internal-cg at ianacg.org>
Subject: Re: [Internal-cg] Draft webinar deck and outline
> 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 <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/0b66c385/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/20150729/0b66c385/attachment.p7s>
More information about the Internal-cg
mailing list