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

[Dan Burnett <[e-mail]>]

On Jul 19, 2011, at 3:27 AM, Miguel A. Garcia wrote:

> 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 <[e-mail]
>>> <mailto:[e-mail]>>
>>> 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 "*".

I believe this has been addressed separately with Robert Sparks.  I will leave the text as-is.

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

Now I understand.  The problem is that I have not used the proper wording to describe the environment.  I agree with you and in 4.2 and 4.5 (and linked there from 10.6) will change "physically secure environments" to "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

I will do this in the next draft.

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

I will do this in the next draft.

> 
> BR,
> 
>       Miguel
> 
> 
> 
> -- 
> Miguel A. Garcia
> [phone]
> Ericsson Spain