Hi Colin:
Some more inline discussion (only points that require further discussion).
Colin Perkins wrote:
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.
Ok, and the DCCP implementation exposes an API to the RTP implementation
that allows the RTP implementation to send zero-lenght data. If so, then
it is fine.
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.
I would appreciate this sentence when there isn't a NAT. People who are
not familiar with our way of writing specs might take sentences
literally, so better being 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".
My point that dccp-service-attr is not anchored to the SDP ABNF. So,
someone who is reading the ABNF wouldn't know how to add it to the
existing grammar. However, I see your point... I think there should be a
place in the SDP ABNF that could be used as an anchor for extending
attributes. Perhaps 'att-field' is the anchor point, but I have to look
deeper into this.
In any case, the text and the examples are complete the ABNF and there
is no doubt about the 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.
Yes, fine, I don't have a problem with that. I just thought that the
draft does not say that the tokens RTPA, RTPV, etc correspond to the
grammar 'sc-char'. The reader has to implicitly understand it from the text.
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?
The first paragraph currently reads:
The following SDP "proto" field identifiers are registered: "DCCP",
"DCCP/RTP/AVP", "DCCP/RTP/SAVP", "DCCP/RTP/AVPF" and "DCCP/RTP/SAVPF"
(see Section 5.1 of this memo).
The text does not say which registry IANA has to operate, so I would
suggest to replace the above with:
This memo request IANA to add the folowing new values to the 'proto'
subregistry of the s'Session Description Protocol (SDP) Parameters'
registry:
DCCP
DCC/RTP/AVP
DCCP/RTP/SAVP
DCCP/RTP/AVPF
DCCP/RTP/SAVPF
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).
Yes, I think the best solution, unless there is a technical glitch, is
to change the existing IANA registry to refer to RTP and RTCP rather
than the AVT profile
/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
