![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Brian E Carpenter wrote:
"CoDoNS enables multiple namespace operators to manage the same part of
the name hierarchy [...] Ideally, competing operators would preserve a
single consistent namespace by issuing names out of a common, shared
pool. In the presence of conflicting or inconsistent records,
One doesn't need to read further to observe that this is a broken namespace.
An alternate view is that one does not need to read further to note that this scheme calls for coordination at the top of the naming hierarchy, just like any other scheme needs to, in order to be viable.
Whether the coordination is performed by a central authority or a cooperative society of participants is entirely irrelevant, to the underlying requirement of preventing name conflicts.
Yes. And I should add that I didn't mean to attack CoDoNS as if it was a bad piece of work. I meant to promote the notion that substituting one way of guaranteeing namespace uniqueness for another really doesn't change anything fundamental, if we still have to admit the possibility of "conflicting or inconsistent records".
Brian
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.