On 17 Jun 2007, at 20:54, Miguel 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
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.
An implementation can send zero length DCCP-Data packets. This is
explicitly allowed by the DCCP specification.
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.
There are two reasons it's a "SHOULD" rather than a "MUST": 1) the
DCCP CCID used might provide a transport level keepalive (this is
mentioned at the end of the paragraph you cite); and 2) the
application knows there is no NAT on the path. I thought the second
reason implicitly obvious, but I can add a sentence to make it explicit.
So, bearing these two issues in mind, does the offending sentence
make sense? Has this been discussed in the DCCP working group?
It has been discussed extensively in the DCCP working group, and I
believe it makes sense.
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.
I'm not sure it is, since it redefines "attribute".
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.
RFC 4340 section 8.1.2 suggests service codes be written with the SC:
prefix.
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
The draft explicitly lists the registries (SDP "proto" field, SDP
attribute, DCCP service code, and DCCP port), along with the values
to be registered. I think it's clear that new values are to be
registered, but can be even more explicit.
Furthermore, RFC 4566 (SDP) provides a template for registration of
SDP attributes that should be included in the draft.
All the information requested in RFC 4566 seems to be provided. What
do you think is missing?
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.
They're the RTP/AVP profile using RTP on port 5004 and RTCP on port
5005 in all three cases. I'll try to come up with some clarifying
wording (this may also mean changing the existing text in the IANA
registry, which isn't clear).
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?
No, this is a mistake. I'll remove the sentence.
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.
^^^
Okay.
Thanks,
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
