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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
