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

"Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com> Tue, 19 July 2011 07:27 UTC

Return-Path: <miguel.a.garcia@ericsson.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 52F7C21F85F5 for <gen-art@ietfa.amsl.com>; Tue, 19 Jul 2011 00:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level:
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZPFWQEKkdAi for <gen-art@ietfa.amsl.com>; Tue, 19 Jul 2011 00:27:19 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0572F21F85F2 for <gen-art@ietf.org>; Tue, 19 Jul 2011 00:27:18 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-12-4e2531d5b577
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A4.69.09774.5D1352E4; Tue, 19 Jul 2011 09:27:17 +0200 (CEST)
Received: from [159.107.24.224] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 09:27:16 +0200
Message-ID: <4E2531D4.7080900@ericsson.com>
Date: Tue, 19 Jul 2011 09:27:16 +0200
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Dan Burnett <dburnett@voxeo.com>
References: <4DBFA327.7070404@ericsson.com> <656E03F7-D6C2-42F3-BBFB-EAC6C9C1CDA1@voxeo.com>
In-Reply-To: <656E03F7-D6C2-42F3-BBFB-EAC6C9C1CDA1@voxeo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
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: Tue, 19 Jul 2011 07:27:23 -0000

Hi Dan:

I have some further discussions on a couple of comments. I have deleted 
from this e-mail all those comments for which no more discussion is needed.

On 12/07/2011 1:40, Dan Burnett wrote:
> Miguel,
>
> Thank you for your comments. I have replied to each with either the
> action I intend to take or the reason why I believe a change is not
> warranted at this time, with one exception.
>
> There is one item below, regarding the Vendor Parameters registry, which
> is still under discussion.
>
> Draft-25, which I will post in a few minutes, addresses the comments that
> I say below that I will address.
> It does not address all of the draft-24 review comments received from
> others, so there will be another draft after the IETF 81 publication
> moratorium expires.
>
> -- dan
>
> On May 3, 2011, at 2:39 AM, Miguel A. Garcia wrote:
>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft. For background on Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>
>> Please resolve these comments along with any other comments you may
>> receive.
>>
>> Document: draft-ietf-speechsc-mrcpv2-24.txt
>> Reviewer: Miguel Garcia <miguel.a.garcia@ericsson.com
>> <mailto:miguel.a.garcia@ericsson.com>>
>> Review Date: 2011-05-03
>> IETF LC End Date: 2011-04-13
>>
>> Summary: The document is on the right track, but has some issues that
>> should be addressed before publication as a standards track RFC.
>>
>> Major issues: none
>>
>> Minor issues:
>>
>> - Section 4.2 reads:
>>
>> To remain backwards compatible with conventional SDP usage,
>> the format field of the m-line MUST have the arbitrarily-selected
>> value of "1".
>>
>> The comment is that in other protocols, for example, MSRP [RFC4975] it
>> has been selected to use an asterisk "*" in the format field. I wonder if
>> it is possible to unify criteria, in order to allow usage of conventional
>> SDP parsers.
>
> I don't see how this has any relationship to "conventional SDP parsers".
> Any SDP parser should be able to parse the value "1", and the allowed
> value is protocol-specific anyway. Since the values of the media and
> protocol fields are completely different in our case, and because this
> would break existing implementations of MRCP, I see no sufficient reason
> to change the value.

Let me give you an example. If I have an SDP class that encodes SDP, the 
class would not be able to decide whether to write an asterisk "*" or a 
"1" in the format field, when you invoke it. Writing "1" or "*" will be 
dependent on the application.

Then, if you see an SDP body captured by Wireshark or similar, you will 
need to know which application generated it before you could decided 
whether the SDP is correct or not. And Wireshark will not be able 
indicate "format is irrelevant" until it knows which application carried 
that SDP.

I haven't heard a good reason for keeping the value "1". So, I am still 
proposing to reuse the "*".


>> - On Sections 9.4.9, 10.4.8, and 11.4.11, there is no indication of the
>> possible values of the "media-type-value". I guess you want to say that
>> these are intended to be MIME types (so far, the word "MIME type" is
>> not written), and in that case, you should also say that possible
>> values are any of the values included in the MIME media types registry
>> maintained by IANA.
>
> I originally referred to these as MIME types. However, a prior reviewer
> assured me that "media type" was the more proper term (since MIME is
> about Internet Mail and media types are used for much more than email),
> so I replaced every instance of "MIME type" with "media type". I would
> need a very strong argument to change them all back.

Yes, you are right, the terminology used these days is "media types", so 
keep on using it.


>> - Question: In Sections 9.4.21 and 10.4.6, should "1*UTFCHAR" be
>> included in quotes? It is true that there is no other subfield in the
>> same header, meaning that there is no intention to parse the text. But
>> somehow I feel safer if you enclosed the text in quotes. Also, remember
>> that this text is coming from other protocol beyond your control, so
>> you never know, for example, if the other protocol is going to add CRLF
>> or something weird that will crash the recipient of the header.
>>
>> Note that the resolution of this issue should also be applied to
>> Section 10.4.6.
>
> I checked with my engineer implementing this. We don't see how this is
> any different from, say, "Subject:" in SIP, which also allows unquoted
> descriptive text, except that MRCP specifically does not allow LWS. Just
> like for any other descriptive header field that does not allow LWS, if
> the sender includes a CRLF as content it will be interpreted as an end to
> the header, quote or no.
> I do not plan to make a change at this time.

Ok, it is fine to leave it as is.


>>
>> - Sections 4.2 and 10.6. The text says that if physical security is
>> provided, one can void TLS and merely used TCP. I have the feeling that
>> the connection of these two concepts (physical security and lack of
>> TLS) is not sufficiently justified for the security experts. One could
>> access the resources of the MRCP server remotely, via a TCP connection,
>> not using TLS. Or even sniff the network. So, physical security is not
>> enough for voiding TLS.
>
> Many of the deployments of MRCP are single-box deployments, or
> deployments contained completely in fixed-topology, few-node, local-area
> networks in physically-secure rooms. Both of these are situations where
> neither remote access nor network sniffing are issues unless physical
> access to machines is compromised, in which case few security models are
> sufficient. We do not want to require the use of TLS for such deployments.
> I expect that "the security experts" you mention will express an opinion
> if there is a problem with this.

I'm sympathetic with the spirit of the text. But once more, the lack of 
TLS is not only connected to physical security, as I understood in the 
draft. I think TLS can be omitted in controlled environments (e.g., not 
in the public Internet) where both nodes are inside a protected 
perimeter, for example, preventing access to the MRCP server from remote 
nodes outside the controlled perimeter.

>> Nits:
>> ====
>>
>>

>> - It would be good to have numbers in those tables in Section 5.4. I
>> mean, there should be a caption saying "Table 1: Success 2xx response
>> codes".
>
> I am using XML2RFC. If I can figure out how to get it to number the
> tables I will do this.

The trick is to write an 'anchor' attribute and presumably a 'title' 
attribute as well, for example:

<texttable anchor="table_ex" title="IETF Meetings in 2005">

Source: http://xml.resource.org/xml2rfcFAQ.html#anchor27


>>
>> - Sections 13.7.1 and 13.7.2. There are two tokens being registered in
>> each Section. Can you add an empty line in between these two
>> registrations (within the same Section) for the sake of readability?
>
> Hmm, XML2RFC did this. If I can find a way to add an empty line I will do so.
>

Try adding an &nbsp; symbol. Or an empty paragraph.

BR,

        Miguel



-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain