Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 10/9/18 1:22 PM, Dave Crocker wrote:
> On 10/8/2018 10:15 PM, Adam Roach wrote:
>> My top-line concern is that, while the table established by this 
>> document
>> appears to intend to be a strict superset of the Enumservices table, 
>> there are
>> no instructions of any kind to the IANA that would result in these 
>> tables
>> remaining in sync -- that is, when a new service is added to the 
>> "Enumservice
>> Registrations" table, one might presume that it needs to also appear 
>> in the
>> new registry established by this document.
>
>
> Adam,
>
> Ongoing dependence on these other tables was the original model, and 
> for a long time.  It is not the model now.
>
> A major motivation for making this change was exactly to avoid the 
> synchronization challenge you note. So the round of effort that 
> produced the document split to a base and and a -fix also produced a 
> change in the use of the independent tables.
>
> The current specification /eliminates/ dependence on these other tables.
>
> The goal has been to register all the names that are known to be used, 
> from the various other tables, and then modify the specs that were 
> originally written using those other tables to, instead, require 
> making further additions directly and only to the _underscore registry.
>
> There was quite a bit of discussion about the challenge of 
> synchronization.  This was not helped by the fact that the IANA folk 
> are so accommodating and expressed a willingness to attempt to keep 
> things in sync. However it isn't reasonable to task them with that 
> on-going synchronization effort: it's certain to fail at some point.  
> So instead we eliminated the requirement. 


This is based on an assumption that document authors who add 
enumservices are more likely to notice the need [1] to add their service 
name to two tables than the IANA are. Given the respective levels of 
rigor, that seems like a losing bet.

/a


____
[1] Given the 100% coverage in the current table (modulo the "web" 
issue, which I continue to suspect to be an error), "need" seems to be 
appropriate here.