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

Dan Burnett <> Mon, 31 October 2011 23:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E526711E83A9 for <>; Mon, 31 Oct 2011 16:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePmifeyrqZS5 for <>; Mon, 31 Oct 2011 16:40:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A6A1011E83A3 for <>; Mon, 31 Oct 2011 16:40:40 -0700 (PDT)
Received: from [] (account HELO []) by (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 98421897; Mon, 31 Oct 2011 23:40:16 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Dan Burnett <>
In-Reply-To: <>
Date: Mon, 31 Oct 2011 19:40:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Eric Burger <>
X-Mailer: Apple Mail (2.1084)
Cc: Shanmugham Saravanan <>, Dave Oran <>, General Area Review Team <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Oct 2011 23:40:42 -0000

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., "". 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