[Internal-cg] Draft webinar deck and outline

[Elise Gerich]

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/20150727/5af8de00/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/20150727/5af8de00/attachment.p7s>