Document: draft-ietf-dccp-rtp-06.txt
Reviewer: Miguel Garcia <miguel.garcia@nsn.com>
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 ...