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

[Eric Burger <[e-mail]>]

Thanks!

Dan - got it?

Done.
--
- Eric

On Oct 31, 2011, at 11:36 AM, Miguel A. Garcia wrote:

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