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 <[email protected]
<mailto:[email protected]>>
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 symbol. Or an empty paragraph.
BR,
Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
