[Internal-cg] Draft webinar deck and outline

[Russ Mundy]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20150727/6887501d/attachment.asc>