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

[Dan Burnett <[e-mail]>]

I think the only change I will have to make is that instead of an RFC defining the value a requester merely needs documentation.

On Oct 31, 2011, at 11:37 AM, Eric Burger wrote:

> 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
>