You know my opinion. I don't buy Dan's argument of using the IANA
registration for avoiding some syntax violation. A registry won't avoid it.
/Miguel
On 31/10/2011 13:18, Eric Burger wrote:
Now I get it.
Let me put it this way: we can create a protocol parameters space and
ask IANA to create a registry full of opaque strings that happen to
look like DNS names. Collisions are avoided because IANA manages these
opaque strings that look like DNS names. Or, we can use DNS names and
ask IANA to do their day job of ensuring that DNS names are unique,
which they are.
Therefore, simply saying MRCPv2 will use reverse DNS names is
sufficient to ensure a unique vendor name space. If there is a
collision, we can let ICANN run the full domain name dispute
resolution process. No need to get the IESG or an IETF expert
involved.
I vote to simply use reverse DNS names.
On Oct 31, 2011, at 7:44 AM, Dan Burnett wrote:
Since we are down to only this one comment we can just top-reply :)
The reason we are using this syntactic structure is because that is
what implementers of MRCPv1 are already used to. It is a convenient
way to distinguish among different vendors' parameters.
However, the registry is to ensure there are no conflicts. Merely
recommending that vendors use a particular syntax does not ensure
that they will do so. A (public) registry does, at least insofar as
making it public when they violate the recommendation.
-- dan
On Oct 31, 2011, at 4:54 AM, Miguel A. Garcia wrote:
Hi Dan.
First, I believe I agree with all your previous comments. Thanks
for addressing it.
Now, back to this comment related to the IANA registration. See
below.
On 31/10/2011 2:20, Dan Burnett wrote:
I have removed all but one of your comments below. This comment
had not yet been addressed. With this reply I believe I have
addressed all of your comments. If you find that I have missed
one please let me know.
-- dan
On May 3, 2011, at 2:39 AM, Miguel A. Garcia wrote:
- Section 13.1.6 describes a mechanism where vendor-specific
extensions use the reverse DNS mechanism, for example.,
"com.example.foo". Then, if the vendor-specific extension is
connected to DNS to avoid clashes in names, why is there a
need for an expert review policy prior to its registration? I
see a contradiction in having a self-managing registry by
avoiding clashes due to the connection to DNS, and then having
anything else than a volunteer registry.
In the next draft I will replace "Expert Review" with "First
Come First Served".
This does not solve my concern. My concerns is why do you need at
the same time:
a) a self-managed registry, by linking reversed DNS names to
features
b) an IANA-controlled registry.
There is a redundancy here. The goal of both is to avoid clashes
of different features with the same name. If you need an IANA
registry, then features do not need to be linked with their DNS
names. If you need a reversed DNS names for the features, then
their names are self-managed and need not be maintained by IANA.
So, I still do not understand what you are trying to achieve.
BR,
Miguel
-- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
