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

["Miguel A. Garcia" <[e-mail]>]

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 [phone] Ericsson Spain
>>
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain