Subject: [Gen-art] Gen-ART review of IETF LC draft-ietf-dccp-rtp-06.txt

From: Miguel Garcia <[email-masked]>
Date: Sun, 17 Jun 2007 22:54:01 +0300

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-masked]>
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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Jun 2007 16:39:47 +0100

On 17 Jun 2007, at 20:54, Miguel Garcia wrote:
> Summary: This draft is basically ready for publication, but has  
> nits that should be fixed before publication.
>
> Comments:
>
> 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.

> which is correct, no doubt, but sort of re-defines the attribute  
> (a=) line in SDP, because the %x61 character is bound to attributes.
>

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:
>
> 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.

> 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?

> DCCP. However, I took a look at the port number registration, and  
> here is how they look today:
>
> 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?
>
> 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).

> 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:
>

Okay.

Thanks,
-- 
Colin Perkins
http://csperkins.org/

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 18 Jun 2007 23:00:46 +0300

Hi Colin:

Some more inline discussion (only points that require further discussion).

Colin Perkins wrote:
>> 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.
> 

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.

>> 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.

> 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 
>> service codcs (RTPA, RTPV, etc.), without the "SC:", which is already 
>> in the ABNF.
> 

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.

> 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.
> 
> 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

>> 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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 19 Jun 2007 22:16:58 +0100

Hi Miguel,

> Some more inline discussion (only points that require further  

Thanks again for the comments. More inline.

>>> 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.
> 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.

>>> 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.
>> 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  

Okay - will do.

> 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.

>>> 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:
>>>
>> 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.

>>> 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
>> 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 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:
>>>
>>> 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/

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Jun 2007 09:14:39 +0300

Miguel,

thanks for the review!

Colin: Is the current set of changes that were the result of the IETF  
LC concise enough to be put into an RFC Editor Note? If so, can you  
send me one before the telechat tonight? Otherwise I'll ask that the  
document be put into "Revised ID Needed."

Thanks,
Lars

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Jun 2007 08:57:44 +0100

On 20 Jun 2007, at 07:14, Lars Eggert wrote:
> Colin: Is the current set of changes that were the result of the  
> IETF LC concise enough to be put into an RFC Editor Note? If so,  
> can you send me one before the telechat tonight? Otherwise I'll ask  
> that the document be put into "Revised ID Needed."

No, I'll submit a revised draft. Do you want it today, or after the  
telechat?

Colin

---

From: Lars Eggert <[email-masked]>
Date: Wed, 20 Jun 2007 11:05:45 +0300

On 2007-6-20, at 10:57, ext Colin Perkins wrote:
>> can you send me one before the telechat tonight? Otherwise I'll  
>> ask that the document be put into "Revised ID Needed."
>

Then let's wait until after - there may be more comments coming  
during IESG Evaluation.

Lars