Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt

[Eric Burger <[e-mail]>]

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 [phone] Ericsson Spain
>>>> 
>>> 
>> 
> 
> -- 
> Miguel A. Garcia
> [phone]
> Ericsson Spain