Hi Eric:
I think I understand your motivation, and I believe you now understand
that the IANA registry does not warrant any further interoperability. I
think you have convinced me that the registry may encourage developers to
publish their specifications, something that, otherwise, it won't happen.
As long as you understand that there is no warranty for success, I have
no problem. Please proceed with the IANA registry. Make sure that the
registry itself contains a contact person and a pointer to the published
specification.
BR,
Miguel
On 31/10/2011 16:24, Eric Burger wrote:
This is an area where I think we are violently agreeing.
We do not require a specification. That meets FCFS requirements. To
make a no-registration-required policy work, we need a self-organizing
mechanism that avoids conflicts. Reverse DNS names seems to fit this
bill.
While we do not require a specification, we do ENCOURAGE publications
of specifications. To make that sensible, and to have a place to refer
to published specifications, we are establishing a registry.
IANA has gotten really good at establishing registries. It no longer
takes months or years for them to set one up. Moreover, this is the
lowest-involvement kind of registry for them to run, so it is low
impact on their operations. [These are two important items for me to
consider with my IAOC hat on.]
If we are getting into a dogmatic or religious discussion, we are more
than willing to give up on asking for a registry that might improve
long-term interoperability for the short term goal of getting MRCPv2
published. Even the ITU-T is waiting for this document to become an
RFC.
Thanks.
On Oct 31, 2011, at 10:46 AM, Miguel A. Garcia wrote:
Hi Eric:
Although this is a laudable effort, you won't get the expected
results.
First, because the registry does not require a specification. The
policy (last thing we heard) is First Come First Served, and does
not require a specification.
Second, a publicly available specification is something that
companies won't do if they don't want to disclose their own
extensions. Instead, they will simply create extensions identified
by their DNS names, and they won't need the IANA registration.
So, I am even more confused than before. If you want to push
companies to public their specifications, they are not going to do
it because you say it in a standards document. IANA won't help you.
/Miguel
On 31/10/2011 14:46, Eric Burger wrote:
Miguel - One thing I would like to be clear on. We do want a
registry to encourage interoperability. By saying "use reverse DNS
names" I do not mean "don't have a registry." Using reverse DNS
names is a sufficient mechanism for avoiding naming collisions in
the header space. However, avoiding collisions does not mean we
foster interoperability.
The reason we want a registry is we want to encourage developers
of proprietary extension to document them. By having some
documentation out there, the hope is people will learn from each
other and hopefully, if something sticks, we can later do some
standards track work.
We did not mandate registration of an extension to use it. There
is no protocol police, so there is no point mandating something
that one cannot test. Using reverse DNS name space does give us a
high probability of non-collisiion.
Likewise, we did not say, "Developers MAY register proprietary
headers." That gives people the easy out, and then we get no
documentation benefits of the registry.
One thing I would offer to additionally lower the bar on
registration with the goal of improving registrations is to drop
the requirement that the documentation for the header be published
as an RFC. However, I would leave that determination up to the
IESG.
Does this work for you? -- - Eric
On Oct 31, 2011, at 8:18 AM, 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
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
