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

Dan Burnett <dburnett@voxeo.com> Mon, 31 October 2011 11:45 UTC

Return-Path: <dburnett@voxeo.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EE121F8BFB for <gen-art@ietfa.amsl.com>; Mon, 31 Oct 2011 04:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.216
X-Spam-Level:
X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrwi7ACwE1Yn for <gen-art@ietfa.amsl.com>; Mon, 31 Oct 2011 04:45:27 -0700 (PDT)
Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id 845A221F8BB9 for <gen-art@ietf.org>; Mon, 31 Oct 2011 04:45:24 -0700 (PDT)
Received: from [209.237.253.55] (account dburnett@voxeo.com HELO vpn-cust-10-119-4-142.witopia.net) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 98396243; Mon, 31 Oct 2011 11:45:01 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Dan Burnett <dburnett@voxeo.com>
In-Reply-To: <4EAE6228.7050501@ericsson.com>
Date: Mon, 31 Oct 2011 07:44:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <169A8C44-102D-4B0B-A63A-DE88819F9146@voxeo.com>
References: <4DBFA327.7070404@ericsson.com> <DBDEADE6-F5F4-4A25-B5E5-C857382D29F1@voxeo.com> <4EAE6228.7050501@ericsson.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: Saravanan Shanmugham <sarvi@cisco.com>, Dave Oran <oran@cisco.com>, General Area Review Team <gen-art@ietf.org>, Eric Burger <eburger@standardstrack.com>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-speechsc-mrcpv2-24.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Oct 2011 11:45:28 -0000

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
> +34-91-339-3608
> Ericsson Spain