I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-dccp-rtp-06.txt
Reviewer: Miguel Garcia <[EMAIL PROTECTED]>
Review Date: 2007-06-17
IETF LC End Date: 2007-06-20
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
Comments:
There are a few of comments that I would like to discuss with the author.
1) In Section 4.1, second paragraph, a sentence reads:
To ensure NAT
bindings are kept open, an end system SHOULD send a zero length DCCP-
Data packet once every 15 seconds during periods when it has no other
data to send.
I have two problems with the above sentence. The first one is that this
seems to impose a requirement to the DCCP implementation, rather than to
the RTP implementation. However, I read the document thinking that the
draft should describe the behavior of RTP and SDP implementations if
they happen to have a DCCP stack at its disposal. If I am on the right
track, then is it possible that the RTP implementation tells the DCCP
stack what when to send a zero-length DCCP packet? I believe the answer
is not.
The second problem I have with the same sentence: There is no condition
for the SHOULD strength, nor cases when the SHOULD strength shouldn't be
honored. So, what about if the two endpoints have got IPv6 or public
IPv4 addresses, and there isn't any NAT in the path? Why should they
keep on sending zero-length DCCP packets in the absence of any other
data? For example, the two endpoints might be using ICE and STUN, in
which case they have the means to determine whether they are behind a
NAT or not. If they discover they aren't natted, perhaps they shouldn't
be sending keepalives to each other.
So, bearing these two issues in mind, does the offending sentence make
sense? Has this been discussed in the DCCP working group?
2) About the ABNF in Section 5.2. The first line in the ABNF is:
dccp-service-attr = %x61 "=dccp-service-code:" service-code
which is correct, no doubt, but sort of re-defines the attribute (a=)
line in SDP, because the %x61 character is bound to attributes.
Wouldn't it make more sense to replace the above line with these two:
attribute = dccp-service-code-attr
dccp-service-code-attr = "dccp-service-code:" service-code
where 'attribute' is defined in RFC 4566 [3].
I think this is clearer.
3) More on ABNF. The draft defines a number of initial Service Codes in
ASCII. Those are the RTPA, RTPV, RTPT, etc. However, I am missing a
sentence that puts then into context as ASCII representations of the
service code. I would suggest to replace the existing sentence:
The following DCCP service codes are registered for use with RTP
with this one:
A number of initial DCCP Service Codes are initially registered for
use with RTP. These service codes are ASCII representations and
correspond to the 'sc-char' element in the ABNF:
and then, of course, the list would just need to list the name of the
service codcs (RTPA, RTPV, etc.), without the "SC:", which is already in
the ABNF.
4) IANA considerations section
The IANA considerations section does not follow the rules nor the
templates: It does not say what is the action to IANA (create a new
registry, or add a value to an existing registry), nor it specifies
which is the registry IANA should operatete upon
Furthermore, RFC 4566 (SDP) provides a template for registration of SDP
attributes that should be included in the draft.
5) Ports in IANA section
The draft tries to register ports 5004 and 5005 for use of RTP over
DCCP. However, I took a look at the port number registration, and here
is how they look today:
avt-profile-1 5004/tcp avt-profile-1
avt-profile-1 5004/udp avt-profile-1
avt-profile-2 5005/tcp avt-profile-2
avt-profile-2 5005/udp avt-profile-2
So, it seems that ports 5004 and 5005 are reserved to the AVT profile,
not to generally to RTP and RTCP. So, how should the new registration
look like?
avt-profile-1 5004/dccp avt-profile-1
avt-profile-2 5005/dccp avt-profile-2
My comment is that it is somehow strange that the registration does not
say RTP or RTCP. And it is not clear to me whether the intention is to
show RTP or RTCP in the new registration, in which case some outsider
might get confused with the mixture of AVT profile and RTP/RTCP.
6) Unable to parse a sentence in IANA considerations section.
The last sentence of the IANA considerations section reads:
The four services codes listed above are to be associated with these
ports
I was looking for four services codes, but I found a group of 5 in the
immediate paragraph, so I probably there is an error somewhere. But more
important, I don't understand what IANA has to do with the service
codes. As far as I know, IANA should not list any binding of service
codes to RTP, or am I missing something?
7) A nit in Section 5.1, to bind the SDP token "DCCP" with the protocol
"DCCP".
OLD:
The "DCCP" protocol identifier is similar to the "UDP" and "TCP"
protocol identifiers and describes the transport protocol, but not
the upper-layer protocol.
NEW:
The "DCCP" protocol identifier is similar to the "UDP" and "TCP"
protocol identifiers and denotes the DCCP transport protocol [2], but
^^^^^^^^^^^^^^^^ ^^^^
not its upper-layer protocol.
^^^
8) Nit: As a matter of personal taste, I don't like to see references
when the referred document is not printed. For example,
OLD:
As noted in Section 17.1 of [2], there is....
which is a common way to refer to documents. I prefer this one:
NEW:
As noted in Section 17.1 of DCCP (RFC 4340 [2]), there is ...
That's it.
/Miguel
--
Miguel A. Garcia tel:+358-50-4804586
Nokia Siemens Networks Espoo, Finland
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
