Subject: [AVT] Working group last call: 2833bis and 2833bisdata

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Oct 2005 12:17:02 +0100

This is to announce a working group last call on the following two  
drafts:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-10.txt
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisdata-04.txt

Please send any final comments on these two drafts to the mailing  
list by 31 October 2005. If no substantive issues are raised by that  
time, we intend to submit these to the IESG for publication as  
proposed standard RFCs, updating RFC 2833.

Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Oct 2005 17:06:06 +0200

Hi

I have reviewed draft-ietf-avt-rfc2833bis-10 and have the following issues:

1. The abstract contains normative language. Not at all suitable.

2. There is not text in the draft stating its relation to RFC 2833. Is 
this document obsoleting or updating RFC 2833. The WG last call says 
updating, but what of RFC 2833 is kept compared to the other documents?

3. Section 2.2.1: What is the definition of measurement point?

4. Section 7. States that these media types are new. Which isn't true 
they are updated.

5. Section 7.1: I think it should be noted that the registrations are 
done in accordance with RFC 3555 and draft-freed-media-type-reg-05.txt.

6. Section 7.1.1: Events parameter. The default that no value indicates 
0-15 should be explicitly stated also here.

7. Section 7.1.1: Encoding consideration. Yes, this is correct according 
to RFC 3555 but not according to draft-freed-media-type-reg-05. As we 
will update RFC 3555 we should follow freeds document. Thus the encoding 
considerations should state that the content is "framed" and "binary". 
See freeds draft for the definitions.

8. Section 7.1.1: No restriction on usage. This heading shall state that 
this media type is only defined for transfer using RTP.

9. Section 7.1.2: Apply commend 7 and 8 on this section also.

10. Reference 17 is not used. Please fix that either by removing or 
actually using it.

I would also like to note that also this WG last call forgot to send the 
draft to ietf-types for review.

Cheers

Magnus

Colin Perkins wrote:
> This is to announce a working group last call on the following two  drafts:
> 
> Please send any final comments on these two drafts to the mailing  list 
> by 31 October 2005. If no substantive issues are raised by that  time, 
> we intend to submit these to the IESG for publication as  proposed 
> standard RFCs, updating RFC 2833.
> 
> Colin
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 25 Oct 2005 15:00:49 -0400

Thanks for reviewing this again.  My responses below.

> 1. The abstract contains normative language. Not at all suitable.
[PTT] I will delete the word "MUST" in the second paragraph.
> updating, but what of RFC 2833 is kept compared to the other documents?
[PTT] The intention is that it obsoletes RFC 2833.  I will replace the 
second and third sentences of the abstract with that statement, and fold 
those sentences into a later part of the abstract.
> 3. Section 2.2.1: What is the definition of measurement point?
[PTT] I will delete the first sentence of 2.2.1, which uses this term, 
and replace "that time" in the second sentence with "the time given by 
the RTP timestamp".
> 4. Section 7. States that these media types are new. Which isn't true 
OK.  "... updates the descriptions of two RTP payload formats ...".  And 
"documents" rather than "defines" DTMF event codes.
> done in accordance with RFC 3555 and draft-freed-media-type-reg-05.txt.
OK
> 0-15 should be explicitly stated also here.
OK
> See freeds draft for the definitions.
OK
> this media type is only defined for transfer using RTP.
OK
> 9. Section 7.1.2: Apply commend 7 and 8 on this section also.
OK
> 10. Reference 17 is not used. Please fix that either by removing or 
[PTT] G.729 is part of the example, Figures 3-5.  I'll call out the 
reference when G.729 is first mentioned.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Oct 2005 16:37:05 +0200

Hi,

Now I also have reviewed draft-ietf-avt-rfc2833bisdata-04. I have very 
few comments, it looks good from a reading perspective. I don't know the 
different signalling methods to comment on the correctness of the 
description and handling of the signals.

1. Reference [7] is not used.

2. Reference [13] is not used.

3. Reference [19] is not used.

Authors please remember to check that your references actually are used!

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Oct 2005 16:38:42 +0200

Hi,

The proposed changes look good. Please update when the WG last call has 
ended.

Cheers

Magnus

Tom-PT Taylor wrote:
>> 6. Section 7.1.1: Events parameter. The default that no value 
>> indicates 0-15 should be explicitly stated also here.
> 
> OK
> 
>>
>> 7. Section 7.1.1: Encoding consideration. Yes, this is correct 
>> according to RFC 3555 but not according to 
>> draft-freed-media-type-reg-05. As we will update RFC 3555 we should 
>> follow freeds document. Thus the encoding considerations should state 
>> that the content is "framed" and "binary". See freeds draft for the 
>> definitions.
> 
> OK
> 
>>
>> 8. Section 7.1.1: No restriction on usage. This heading shall state 
>> that this media type is only defined for transfer using RTP.
> 
> OK
> 
>>
>> I would also like to note that also this WG last call forgot to send 
>> the draft to ietf-types for review.
>>
>> Cheers
>>
>> Magnus
>>
>> Colin Perkins wrote:
>>

-- 

Magnus Westerlund