Subject: Re: [AVT] Working group last call: draft-ietf-avt-avpf-ccm-07

From: Keith Lantz <[email-masked]>
Date: Thu, 05 Jul 2007 15:09:27 -0700

As promised, here are my comments on the latest draft:

- First and foremost, this is *much* improved since the last version 
I reviewed (version 03). The result is that these comments are almost 
exclusively minor editorial nits. My compliments to the authors (and 
anyone else who contributed to that improvement)!

- Arguably the only non-editorial comment is this: In Section 4.3.3.2 
it says that if the recipient of a TSTR receives several TSTRs with 
different sequence numbers, it "SHALL" only respond to the request 
with the highest sequence number. Unfortunately, the sequence numbers 
are modulo 256, which means there will be occasions where the 
recipient will respond to an *older* request -- when a more recent 
request wraps back to 0. Is this not a problem?

Now for the editorial comments:

- The "header" on the 2nd and subsequent pages contains a fairly 
non-descriptive title: "AVPF RTCP-RR Extensions". Something like 
"Codec Control Messages in AVPF" would seem much more appropriate.

- Section 2.1 and elsewhere: "AMID" --> "AIMD".

- Section 2.2, defn. of stream thinning: "when subject to" --> "when 
subjected to"

- Section 2.3, defn. of Topo-Multicast: consider deleting "as in RFC 3550"

         defn. of Topo-Translator: "translator based as" --> 
"translator-based communication" & consider deleting "as in RFC 3550"

         defn. of Topo-Mixer: "mixer based as" --> "mixer-based 
communication" & consider deleting "as in RFC 3550"

         defn. of Topo-Video-switch-MCU: eliminate the closing comma

         defn. of Topo-RTCP-terminating MCU: replace with 
"RTCP-terminating, mixer-based communication"

- Section 3.1, item 7: "AMID" --> AIMD"

         "does generally result" --> "generally results"

- Section 3.5.1, 2nd paragraph: Given the widespread use of "FVU" for 
this functionality, add "fast video update" to the list of "also known as".

         3rd paragraph: "MPEG-4" --> "MPEG-4 Part 2"

         5th paragraph: Restructure 2nd sentence as "A receiver that 
receives a request closely after sending a decoder refresh point -- 
within 2 times the longest Round Trip Time (RTT) known, plus and 
AVPF-induced RTCP packet sending delays -- should await ..."

- Section 3.5.2, 3rd paragraph: "finally the new trade-off is 
selected" --> "the new trade-off is finally selected"

         4th paragraph: "translator, mixer or endpoint's" --> 
"translator's, mixer's or endpoint's"

- Section 3.5.2.3, 2nd paragraph: Remove comma after "(and bit rate)".

- Section 3.5.2.4: Consider replacing "request-sender" with "requester".

- Section 3.5.3: "oversimplifying" --> "oversimplified"

         p. 19: Insert comma after "messages" in "In response to the 
opaqueness of the H.271 messages"

- Section 3.5.3.1: Remove the closing period from "clause 3.5.1.1.". 
(This is the case for several other cross-references as well. Then 
too, several cross-references have line breaks inserted -- e.g. the 
reference to section 3.5.4.2 at the top of p. 40.)

- Section 3.5.4, 3rd paragraph: Restructure last sentence as "... 
because calculations are carried out in terms of variables that have 
the same value at the sender as at the receiver -- for example, 
packet rate and net media rate."

- Section 3.5.4.2, 2nd paragraph: Insert commas after "First" and 
"Fortunately".

         p. 26, the "basic idea" paragraph: This discussion should 
probably make explicit that the X and Y axes comprise two sides of 
the "polygon" under discussion. Perhaps "The lower envelope of the 
set of lines corresponding to the complete set of TMMR tuples, 
together with the X and Y axes, defines a polygon."

- Section 3.5.4.3, 2nd paragraph: Restructure as "In practice, 
unfortunately, media-aware streaming thinning is a very ..."

- Section 4.2, opening paragraph: Note that the syntax used here is 
not identical to that used in Section 4.3. Here you write "RTCP 
packet type value RTPFB", whereas in Section 4.3 you write "RTCP 
packet type value PT=PSFB" -- i.e. you insert the "PT=". Either way 
works, but you should be consistent.

- Section 4.2.1.1, defn. of Measured Overhead: "according to 
description" --> "according to the description"

- Section 4.2.1.1 (& also 4.2.2.1): Similar to the next to previous 
comment, the structure used here is not identical to that used in 
Sections 4.3.1, 4.3.2 and 4.3.3. In the latter sections you include 
sentences that specify the PT and FMT values -- e.g. "The FIR message 
is identified by RTCP packet type value PT=PSFB and FMT=4." Here (and 
in 4.2.2.1) you do *not* include such sentences. Again, either way 
works, but you should be consistent.

- Section 4.2.1.2: As per a similar comment above, "See section 5." 
--> "See section 5".

- Section 4.3: As noted above, the syntax used here is not identical 
to that used in Section 4.2. Here you write "RTCP packet type 
value  PT=PSFB", whereas in Section 4.3 you write "RTCP packet type 
value RTPFB" -- i.e. *without* the "PT=". Either way works, but you 
should be consistent.

- Section 4.3.1: Similarly, the structure use here (and in Sections 
4.3.2 and 4.3.3) is not the same as that used in Sections 4.2.1.1 and 
4.2.2.1. See the comment on Section 4.2.1.1 above for further clarification.

- Section 4.3.1.2: There are a *lot* of "Notes" in this section that 
really impair readability. Strongly suggest that this section be 
rewritten/restructured to incorporate most of that content in the 
body of the section itself.

         Also, in the 2nd note: "However a session" --> "However, a 
session". (This happens elsewhere as well. I just didn't flag them all.)

         And "reasons, such an application SHOULD also be capable to 
receive and react" --> "reasons such an application SHOULD also be 
capable of receiving and reacting".

- Section 4.3.1.5: "Hence waiting" --> "Hence, waiting". (Ditto for 
similar sentences elsewhere.)

- Section 4.3.2: See comment on Section 4.2.1.1 above.

         Defn. of Index (& elsewhere): "trade off" --> "trade-off"
                 "value of 0 index" --> "value of 0 indicates"

- Section 4.3.2.2: "to which the TSTR applies to" --> "to which the 
TSTR applies"

- Section 4.3.2.3: "requires a quick feedback" --> "requires quick feedback"

- Section 4.3.2.4: Contains another of several cross-references where 
line breaks have been erroneously inserted.

- Section 4.3.2.5: "refer to the resolution, measured" --> "refer to 
resolution as measured"

- Section 4.3.3: See comment on Section 4.2.1.1 above.

- Section 4.3.3.2: The second sentence is really hard to follow. The 
following might be at least marginally better: "One TSTN entry in a 
TSTN feedback message SHALL be sent for each TSTR entry targeted at 
the sender (of the TSTN message) -- i.e., each TSTR entry that 
contains the sender in its SSRC field."

- Section 4.3.4: See comment on Section 4.2.1.1 above.

- Section 4.2.4.5: Contains another of cross-reference where a line 
break has been erroneously inserted.

- Section 5 (& elsewhere): "Thus modified" --> "Thus, modified"

         "reduced transmission bit rate thus" --> "reduced 
transmission bit rate, thus"

- Section 6, enumerated list: The structure of these bullets is 
inconsistent -- with the first three being structured as if they were 
all part of the same sentence, separated by semi-colons, and the 
fourth being its own sentence. They should all be structured as 
self-standing sentences or the fourth should incorporated into the 
same "sentence" as the previous three.

- Section 7: Drop the "protocol" from "codec control protocol".

         first paragraph on p. 59: Insert comma after "For example".

         Rewrite the two sentences preceding the bullet list as 
follows: 'The "ccm" feedback value SHOULD be used with parameters 
that indicate the specific codec control commands supported. In this 
draft we define four such parameters, namely:"

         Then, in every bullet: "indicates the support" --> "indicates support"

- Section 7.2: "are similar those" --> "are similar to those"

         "parameters which it does" --> "parameters that it does"

         "everyone shall use" --> "everyone SHALL use"

- Section 7.3, last sentence: "So in the above example only" --> "So, 
in the above example, only".

That's it!

Regards, Keith

At 02:51 AM 6/20/2007, Even, Roni wrote:

>This is to announce a working group last call on the Codec Control 
>Messages in the RTP Audio-Visual Profile with Feedback (AVPF).
>
>This is a second last call after the authors addressed comments in the list
>
>Please send any final comments to the mailing list by July 6th 2007.
>
>If no issues are raised, we will request the IESG consider this for 
>publication as a Proposed Standard RFC.
>
>Thanks
>Roni Even - AVT co-chair
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Audio/Video Transport Working Group 
>of the IETF.
>
>         Title           : Codec Control Messages in the RTP 
> Audio-Visual Profile with Feedback (AVPF)
>         Author(s)       : S. Wenger, et al.
>         Filename        : draft-ietf-avt-avpf-ccm-07.txt
>         Pages           : 71
>         Date            : 2007-6-1
>
>This document specifies a few extensions to the messages defined
>    in the Audio-Visual Profile with Feedback (AVPF).  They are
>    helpful primarily in conversational multimedia scenarios where
>    centralized multipoint functionalities are in use.  However some
>    are also usable in smaller multicast environments and point-to-
>    point calls.  The extensions discussed are messages related to the
>    ITU-T H.271 Video Back Channel, Full Intra Request, Temporary
>    Maximum Media Stream Bit Rate and Temporal Spatial Trade-off.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-avt-avpf-ccm-07.txt
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

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

---

From: Randell Jesup <[email-masked]>
Date: Thu, 05 Jul 2007 23:39:30 -0400

Keith Lantz <[email-masked]> writes:
>- Arguably the only non-editorial comment is this: In Section 4.3.3.2 it
>says that if the recipient of a TSTR receives several TSTRs with different
>sequence numbers, it "SHALL" only respond to the request with the highest
>sequence number. Unfortunately, the sequence numbers are modulo 256, which
>means there will be occasions where the recipient will respond to an
>*older* request -- when a more recent request wraps back to 0. Is this not
>a problem?

Not if you use "normal" unsigned-sequence-number math, and define 'older'
and 'newer' to be ranges of around +- 127/128 modulo 256 from the current
value.  This math is used all the time in sequence number and timestamp
comparisons.  So long as 1/2 the sequence bits is enough time in the
forward and backward directions to avoid realistic packet reordering/loss
issues, you're ok.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 06 Jul 2007 13:09:42 +0200

Thanks for the comments.

Keith Lantz skrev:
> - First and foremost, this is *much* improved since the last version I 
> reviewed (version 03). The result is that these comments are almost 

Thanks, and a lot of gratefulness from us authors goes to Tom Taylor 
that made a significant contribution on rewriting the worst part.

> says that if the recipient of a TSTR receives several TSTRs with 
> different sequence numbers, it "SHALL" only respond to the request with 
> the highest sequence number. Unfortunately, the sequence numbers are 
> modulo 256, which means there will be occasions where the recipient will 
> respond to an *older* request -- when a more recent request wraps back 
> to 0. Is this not a problem?
> 

I think the easiest resolution is to be clear that this is in modulo 
arithmetic. Sure some carefullnes are needed.

I will try to address the editorial comments before the deadline. If 
there are any unclarities or disagreemetns I will send a reply about this.

Thanks

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Even, Roni" <[email-masked]>
Date: Sat, 7 Jul 2007 00:32:47 +0300

Hi
It took me some time but I have some comments and nits

1. In section 3.5.2 I suggest to delete "(as it is common in state-of-the-art video conferencing systems). I am not sure that it adds value and voice an opinion.

2. In 4.2.1.2 " If the media sender concludes that it can increase the maximum total media bit rate value, it SHALL wait before actually doing so, for a period long enough to allow a media receiver to respond to the TMMBN if it determines that its tuple belongs in the bounding set."

I was wondering if the SHALL is also true for unicast point to point case.

3. In 4.2.2.2
"As indicated in section 4.2.1.2, when a media sender determines
   that an "owner" of a bounding tuple has left the session, then
   that tuple is removed from the bounding set, and the media sender
   SHALL send a TMMBN message indicating the remaining bounding
   tuples.  If there are no remaining bounding tuples a TMMBN without
   any FCI SHALL be sent to indicate this."

If there are no remaining bounding set what is the current bit rate. Does it mean that the sender may raise the bit rate to the negotiated rate in the signaling.

4. In 4.3.1.2

Do we need the note bellow in the final version.

"Note: Mandating a maximum delay for completing the sending of a decoder refresh point would be desirable from an application     viewpoint, but is problematic from a congestion control point of view.  "As soon as possible" as mentioned above appears to be a reasonable compromise"

5. in section 7.1 " MaxPacketRateValue = 1*15DIGIT" what are the units for this parameter. I think that based on the example it is in 1000's of bits per second but please clarify.
Fix the value in example 3 based on the units, currently it say 120 and I assumed 120*1000 bits/s

6. In the 7.2 " The offerer MAY indicate the capability to support selected codec commands and indications.  The answerer MUST remove all ccm parameters which it does not understand or does not wish to use in this particular media session."
I am not sure what you mean do not want to use, is it does not want to send or just does not want to receive but may send. 
Based on your response the text for the answer in example 3 should have the same semantics.

Nits:

1. Bounding set definition in 2.2 "such as that in section 3   " there is a linefeed that should not be there.

Same in 4.2.1.2 " corresponding algorithm defined in section
   3.5.4.2."

Same in the end of 4.3.2.4

Same in the beginning 0f 4.3.4.5

2. In 2.3 "topo-video-switch-mcu" should be "topo-rtp-switch-mcu" also change the other video-swicth in the same line

3. in 3.5.1.1

"An RTP mixer that receives an FIR from a media receiver is"
Suggset change to 
"An RTP mixer or RTP switching MCU that receives a FIR from a media receiver is"

4. The last paragraph of 3.5.2 " four TSTR/TSTN scenarios need to be distinguished, based on the topologies described in [Topologies].  The scenarios are described in the following sub-clauses."
I think you have only three and not four scenarios

5. In 4.2.1.2 in the discussion section
 " it does not matter which if either tuple" I think it should be of instead of "if"

6. In 4.3.1.2 last sentence " A TSTR message MAY contain requests to multiple media senders, using one FCI entry per target media sender."

Should be FIR and not TSTR

7. In 4.3.3.1 "Seq. nr (8 bits): The sequence number value from the TSTN" Should be TSTR

8. In 4.3.4.2 "Note: There are possible overlaps between the VBCM sub-
          messages and CCM/AVPF feedback messages, such FIR." 
Should be "such as FIR" 

9. In 4.3.4.5 " Note: There has been some discussion whether the payload type field in this message is needed." I suggest changing to "the RTP payload type" since there are two definition to payload type in this section.

Also in the same note you have twice "TSTS" instead of "TSTR"

Regards
Roni

---

From: Randell Jesup <[email-masked]>
Date: Sat, 07 Jul 2007 18:24:19 -0400

"Even, Roni" <[email-masked]> writes:
>5. in section 7.1 " MaxPacketRateValue = 1*15DIGIT" what are the units for
>   this parameter. I think that based on the example it is in 1000's of
>   bits per second but please clarify. 

I'd assume that's in packets-per-second, but it should be spelled out.

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 8 Jul 2007 08:38:51 +0300

Randell,
Packet per second is not a precise number for video. It is also
dependent on MTU size and how the sender breaks a big frame to packets
smaller than MTU size.

Roni

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]]
> Sent: Sunday, July 08, 2007 1:24 AM
> To: Even, Roni
> Cc: [email-masked]; Magnus Westerlund; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [AVT] Review draft-ietf-avt-avpf-ccm-07
> 
> >5. in section 7.1 " MaxPacketRateValue = 1*15DIGIT" what are the
units
> for
> >Fix the value in example 3 based on the units, currently it say 120
and I
> >assumed 120*1000 bits/s
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team
> [email-masked]
> "The fetters imposed on liberty at home have ever been forged out of
the
> weapons
> provided for defence against real, pretended, or imaginary dangers
from
> abroad."

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 8 Jul 2007 10:49:09 +0300

Hi,
The working group last call has ended. It was reviewed and most of the comments are editorial.
Thanks to Keith Lantz for his review.

Since there were no technical issues, I suggest that after fixing the editorial changes it will go to publication. The authors should also fixed the nits listed in http://tools.ietf.org/wg/avt/draft-ietf-avt-avpf-ccm/

Thanks
Roni Even

> From: Even, Roni [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2007 12:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Working group last call: draft-ietf-avt-avpf-ccm-07
> 
> 
> This draft is a work item of the Audio/Video Transport Working Group of
> the IETF.
> 
> 	Title		: Codec Control Messages in the RTP Audio-Visual Profile
> with Feedback (AVPF)

---

From: Randell Jesup <[email-masked]>
Date: Sun, 08 Jul 2007 09:34:36 -0400

>dependent on MTU size and how the sender breaks a big frame to packets

Sure, actual packet rate is dependant on a lot of things.  But (correct me
if I'm wrong) SMAXPR is how you signal a maximum packet rate for use in the
TMMBR algorithm above, and so should be in some variation of packets per
unit time, and my assumption is that we don't need any higher resolution
than integer packets per second.

I don't understand how it could be in bits per second...

>> >5. in section 7.1 " MaxPacketRateValue = 1*15DIGIT" what are the units
>> >   for this parameter. I think that based on the example it is in
>> >   1000's of bits per second but please clarify.

---

From: "Even, Roni" <[email-masked]>
Date: Sun, 8 Jul 2007 17:03:46 +0300

Randell,
Thanks, you are right about the parameter. 

I assume that the default of infinity to this parameter make sense. This
parameter is not important for a unicast point to point call where the
MTU is fixed but for multiple receivers that may have different path MTU
sizes and different overhead.

Roni

> Sent: Sunday, July 08, 2007 4:35 PM
> To: Even, Roni
> if I'm wrong) SMAXPR is how you signal a maximum packet rate for use
in
units
> and
> >> >I assumed 120*1000 bits/s
> >>
OS
the
from

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Jul 2007 19:17:27 +0200

Thanks for the review.

> 1. In section 3.5.2 I suggest to delete "(as it is common in state-of-the-art video conferencing systems). I am not sure that it adds value and voice an opinion.

Agreed

> I was wondering if the SHALL is also true for unicast point to point case.

Yes, this also applies to point to point. The reason is that one can't 
really reliably know which topology you are in. Thus, it is safest to do 
this also in point to point cases. Do you think we need to add any text 
on this?

> If there are no remaining bounding set what is the current bit rate. Does it mean that the sender may raise the bit rate to the negotiated rate in the signaling.

Yes, we have clarified this by adding the following sentence:

"Without a remaining bounding tuple, the maximum media bit rate and 
maximum packet rate negotiated in session signaling, if any, apply."

> "Note: Mandating a maximum delay for completing the sending of a decoder refresh point would be desirable from an application     viewpoint, but is problematic from a congestion control point of vi…

No, but this has been moved into Section 4.3.2.5 (Remarks) where it 
makes more sense to have it as explanation.

> Fix the value in example 3 based on the units, currently it say 120 and I assumed 120*1000 bits/s

We added clarification that this is packets per second.

> Based on your response the text for the answer in example 3 should have the same semantics.

The intention is that you must have the capability to receive such CCM 
requests and in cases, like TSTR to send the response. A agent is not 
required to initiate CCM messages, but expected I would say. Thus I 
propose the following addition to section 7.2:

Note, that including a CCM parameter in an offer or answer indicates 
that the agent (offerer or answerer) is at least capable of receiving 
the corresponding CCM message(s) and act upon them. In cases when the 
reception of a negotiated CCM messages mandates the agent to respond 
with another CCM message, it also must have that capability. Although 
not mandated to initiate CCM messages of any negotiated type it is 
generally expected that the agent will initiate CCM messages when suitable.

Cheers

Magnus Westerlund

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 25 Jul 2007 20:36:20 +0300

Thanks,

Inline

> > 2. In 4.2.1.2 " If the media sender concludes that it can increase the

> maximum total media bit rate value, it SHALL wait before actually doing

> so, for a period long enough to allow a media receiver to respond to the

> TMMBN if it determines that its tuple belongs in the bounding set."

> > I was wondering if the SHALL is also true for unicast point to point

> case.

[RE:] I think a clarification will make sense. 

> > 6. In the 7.2 " The offerer MAY indicate the capability to support

> selected codec commands and indications.  The answerer MUST remove all ccm

> parameters which it does not understand or does not wish to use in this

> particular media session."

> > I am not sure what you mean do not want to use, is it does not want to

> send or just does not want to receive but may send.

> > Based on your response the text for the answer in example 3 should have

> the same semantics.

> generally expected that the agent will initiate CCM messages when

> suitable.

[RE:] I am still not sure I understand. Example the offer includes tmmbr, tstr and fir. The answer responds with tstr only.

Does it mean that the answerer may send tmmbr, tstr and fir but the offerer can only send tstr. 

Also if the above is right it will mean the answerer sending tmmbr will be able to process the response.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Jul 2007 02:58:29 +0200

Hi Roni,

Please see inline.

Even, Roni skrev:
> */ [RE:] I think a clarification will make sense. /*
> 

Okay, I will include the following:

This should be done also for point-to-point sessions, as it not 
guaranteed that a participant can determine correctly if the sources are 
present in a single node and co-ordinated.

Is that okay? I only use should as it is strictly not needed if you are 
convinced that you can correctly determine that the back-off is not needed.

>>   
> 
> */ [RE:] I am still not sure I understand. Example the offer includes 
> tmmbr, tstr and fir. The answer responds with tstr only. /*
> 
> */ Does it mean that the answerer may send tmmbr, tstr and fir but the 
> offerer can only send tstr. /*
> 
> */ Also if the above is right it will mean the answerer sending tmmbr 
> will be able to process the response. /*
> 

Okay, I think there might be missing some word in there that these are 
symmetric and both side need to announce support for it to be possible 
to use it. These parameter does not make sense as declarative ones.

Now the complete sectiond reads:

7.2. Offer-Answer

The Offer/Answer [RFC3264] implications for codec control protocol 
feedback messages are similar to those described in [RFC4585].  The 
offerer MAY indicate the capability to support selected codec commands 
and indications.  The answerer MUST remove all ccm parameters 
corresponding to the CCM messages that it does not support or does not 
desire to be used in this particular media session.  The answerer MUST 
NOT add new ccm parameters in addition to what has been offered.  The 
answer is binding for the media session and both offerer and answerer 
MUST only use feedback messages that both sides have explicitely 
indicated in the messages.  In others words only the joint subset of CCM 
parameters from the offer and answer may be used.

The session maximum packet rate parameter part of the TMMBR indication 
is declarative and everyone SHALL use the highest value indicated in a 
response.  If the session maximum packet rate parameter is not present 
in an offer it SHALL NOT be included by the answerer.

Cheers

Magnus Westerlund

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 30 Jul 2007 12:52:48 +0300

Magnus,
Looks OK.
Thanks
Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, July 27, 2007 3:58 AM
> To: Even, Roni
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Review draft-ietf-avt-avpf-ccm-07
> 
> Hi Roni,
> 
> Please see inline.
> 
> Even, Roni skrev: