Hi Miguel,
On 18 Jun 2007, at 21:00, Miguel Garcia wrote:
Some more inline discussion (only points that require further
discussion).
Thanks again for the comments. More inline.
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.
Yes, I believe so.
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.
Okay - will do.
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.
Okay. I think this is a problem with the ABNF in RFC 4566, which
doesn't have an extension hook for attributes.
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.
Ah... yes, makes sense. I'll make the change.
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
I think it's clear as it is, and IANA didn't have any issues with
this text, so I'd prefer to leave it as-is.
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
Will do.
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
