[Internal-cg] Draft webinar deck and outline

[Russ Mundy]

Glad to get some discussion on the draft slide deck as I expect that they will probably get fairly wide attention.  I’ll respond with to comments inline below.

Russ

On Jul 26, 2015, at 7:58 PM, Patrik Fältström <paf at frobbit.se> 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.

One of the really challenging thing about describing all three OCs information and processes on a single slide is that each OC has different information and it’s handled differently - I think the main concern here is the information rather than the processes.  In some case of Names and Numbers, the structures and quantity of structures are pretty much static (the set of Registries for Numbers and the Root Zone content and associated whois information plus some other special zone administration) so referring to what occurs as “Changes” makes sense.  For Protocol Parameters, the structures used are Registries that are created (new ones added) very regularly - the contents of some Registries do change on occasion but having new Registries created/added is much more common than changing contents of existing ones.  Thus, I felt the word “Change” did not properly apply to all three OCs.

> 
>> -- 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.

I’m not certain that “DNS Root Zone Information” is the best descriptor to use but I strongly object to using “Names Database” because it is easy for those not familiar with DNS or how it works to infer that the “Names Database” has the entire content of the DNS in it and I don’t think that anyone wants to infer that.  The original draft set of slides only has one occurrence of the word “root” which is on a diagram that has no explanatory text - no where in the draft slide deck does it identify that the IANA DNS function are primarily related to the Root Zone.   My intent with the phrase “DNS Root Zone Information” is that it includes both root zone content information and related whois information without trying to describe or differentiate any further detail in the slide deck itself, i.e., trying to find one term that fits all IANA names related “stuff” (& I don’t think it can be ‘registry’).  

I think the important for the slide deck is that we ensure that it’s clear the IANA functions (& all of the associated oversight process) applies to _only_ the DNS Root Zone rather than the entire DNS.  I don’t know how many DNS uninformed/unknowledgable people will be responding (or writing about) the combined proposal based just on what they see in the slides but we need to make it as clear as possible that the Combined Proposal refers predominantly to DNS Root Zone and not the entire DNS.  I’m certainly open to other ways of describing this but the draft slides are not clear about this important aspect.

Russ

> 
>   Patrik