Subject: [Gen-art] review of draft-ietf-avtcore-feedback-supression-rtp-16.txt

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Apr 2012 17:42:15 +0200

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-avtcore-feedback-supression-16.txt
Reviewer: Francis Dupont
Review Date: 20120323
IETF LC End Date: 20120326
IESG Telechat date: 20120412

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:

These are about the -15 version updated to -16

 - I-D name: supression -> suppression

 - Abstract page 1: implosion -> explosion (things which can implode are rare :-)

 - Abstract page 1: signalling -> signaling

 - Toc page 2 and 9 page 12: Acknowledgement -> Acknowledgment

 - Introduction page 4: RTCP is not a well known abbrev: as it is first you have
 to introduce it.

 - Introduction page 4: same for SSM: please introduce the abbrev

 - Introduction page 4: implosion -> explosion

 - Introduction page 4 and other places: e.g. -> e.g.,

 - 3 page 6: ,which -> , which

 - 4 page 6: missing characters/words in "the PT, FMT,length SSRC"

 - 4.1 page 7: all caps in "transport layer third-party loss"

 - 4.2 page 7: if the SSRC is an IPv4 address the "set to 0" is not very correct.

 - 4.2 page 7: media Source -> media source

 - 4.2 page 8: :32 -> : 32

 - 6.1 page 9: source- specific -> source-specific

 - 6.1 page 9: reason( -> reason ( & a RTCP -> an RTCP & NACK)and -> NACK) and

 - 6.2 page 10: Sources(BRS) -> Sources (BRS)

 - 6.2 page 10: a RTCP -> an RTCP

 - 6.4 page 10: receivers. e.g., -> receivers: e.g.,

 - 6.4 page 10:	a RTCP -> an RTCP

 - 6.5 page 11: a RTCP -> an RTCP (with a line break in the middle :-)

 - 7 page 11: supression -> suppression

 - 9 page 12: Acknowledgement -> Acknowledgment, VAN CAENEGEM -> van Caenegem,
  Johansson S -> Johansson

 - 10.2 page 14: please give the names of I-Ds

 - Appendix A page 14: usually the change log is in the reverse order (?)

 - A.8 page 16: ,Security -> , Security

 - A.14 page 17: refereces -> references

Regards

[email-masked]

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Apr 2012 17:03:21 +0800

Hi,Francis:
Thank you for careful and valuable review.please see my replies below inline.

Regards!
-Qin
----- Original Message ----- 
From: "Francis Dupont" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 11, 2012 11:42 PM
Subject: review of draft-ietf-avtcore-feedback-supression-rtp-16.txt

> - I-D name: supression -> suppression

[Qin]: Agree, but I assume I am not allowed to change I-D name at this stage,:-).

> - Abstract page 1: implosion -> explosion (things which can implode are rare :-)

[Qin]: RFC4588 referenced by this document is using "implosion". So I think it should
be fine to use the same term in this document.:-)
 
> - Abstract page 1: signalling -> signaling

[Qin]: Okay.
> - Toc page 2 and 9 page 12: Acknowledgement -> Acknowledgment

[Qin]: Okay.
> - Introduction page 4: RTCP is not a well known abbrev: as it is first you have

[Qin]Okay and will expand this abbrev.

> - Introduction page 4: same for SSM: please introduce the abbrev

[Qin]: I have introduced this abbrev in the glossary section(i.e., section 2.1).
> - Introduction page 4: implosion -> explosion

[Qin]: See above.

> - Introduction page 4 and other places: e.g. -> e.g.,

[Qin]: Okay.
> - 3 page 6: ,which -> , which

[Qin]: Okay.
> - 4 page 6: missing characters/words in "the PT, FMT,length SSRC"

[Qin]: Yes, missing a comma between "length" and "SSRC".
> - 4.1 page 7: all caps in "transport layer third-party loss"

[Qin]: Okay.
> - 4.2 page 7: if the SSRC is an IPv4 address the "set to 0" is not very correct.

[Qin] If SSRC is not used, it should be set to 0. 
RFC5104 also use this rule. So we follow this.
On the other hand if the SSRC is an IPv4 address, IPv4 address MUST not be set to
0 since 0 has already be reserved for the other use mentioned above. 
Also it is easy to cause SSRC collision if IPv4 address can be choose as 0.0.0.0 which is broadcast address.

> - 4.2 page 7: media Source -> media source

[Qin]: Okay.
> - 4.2 page 8: :32 -> : 32

[Qin]: Okay.
> - 6.1 page 9: source- specific -> source-specific

[Qin]: Okay.

> - 6.1 page 9: reason( -> reason ( & a RTCP -> an RTCP & NACK)and -> NACK) and

[Qin]: Okay.

> - 6.2 page 10: Sources(BRS) -> Sources (BRS)

[Qin]: Okay.

> - 6.2 page 10: a RTCP -> an RTCP

[Qin]: Okay.

> - 6.4 page 10: receivers. e.g., -> receivers: e.g.,

[Qin]: Okay.

> - 6.4 page 10: a RTCP -> an RTCP

[Qin]: Okay.

> - 6.5 page 11: a RTCP -> an RTCP (with a line break in the middle :-)

[Qin]: Okay,:-).

> - 7 page 11: supression -> suppression

[Qin]: Okay.

> - 9 page 12: Acknowledgement -> Acknowledgment, VAN CAENEGEM -> van Caenegem,

[Qin]: Okay.

> - 10.2 page 14: please give the names of I-Ds

[Qin]: Okay.

> - Appendix A page 14: usually the change log is in the reverse order (?)

[Qin]: Okay,I can change that based on your suggestion.

> - A.8 page 16: ,Security -> , Security

[Qin]: Okay.

> - A.14 page 17: refereces -> references

[Qin]: Okay.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 12 Apr 2012 13:43:20 +0200

In your previous mail you wrote:

>  [Qin]: RFC4588 referenced by this document is using "implosion". So
>  I think it should be fine to use the same term in this document.:-)

=> RFC 2887 too. IMHO it is time to stop this "implosion" madness and
to return to a correct language (BTW we have the same problem in French, for
an unknown reason the word implosion is often used in place of explosion
when it has the exact opposite meaning...).

>  > - 4.2 page 7: if the SSRC is an IPv4 address the "set to 0" is not very correct.

=> the real problem is what is the SSRC. No spec is very clear, so the
assumption it is not an IPv4 address is right IMHO. (i.e., I withdraw this comment)

> Also it is easy to cause SSRC collision if IPv4 address can be
>  choose as 0.0.0.0 which is broadcast address.

=> BTW 0.0.0.0 is *never* a broadcast address (it could be the only address
in this case :-).

Regards

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Apr 2012 16:19:44 +0800

Hi,Francis:
Sorry for late reply. please see my repy inline.
----- Original Message ----- 
From: "Francis Dupont" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, April 12, 2012 7:43 PM
Subject: Re: review of draft-ietf-avtcore-feedback-supression-rtp-16.txt 

> when it has the exact opposite meaning...).

[Qin]:I can understand it is more sensitive to use "explosion" than "implosion"in France.:-)
However my understanding is implosion seems to mean feedback messages overwhelm the network capacity.
If we change "implosion" into "explosion", we seems to change the meaning of "feedback implosion", 
that is to say, "feedback explision " means feedback message has already paralyzed the network. The Network dies :-).
I am aware that RFC4585 also use "feedback implosion". Since this draft references RFC4585,
Isn't draft-ietf-avtcore-feedback-supression-rtp in accordance with RFC4585?

[Qin]: Okay.
> => BTW 0.0.0.0 is *never* a broadcast address (it could be the only address

[Qin]: Agree.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Apr 2012 10:37:18 +0200

> Isn't draft-ietf-avtcore-feedback-supression-rtp in accordance with RFC4585?

I would like to point out that feedback implosion actually can be seen
as an implosion event. All the feedback traffic generated are
concentrated at the target for the feedback. Thus causing an implosion
of the feedback target under the "weight" of all the feedback.

But, seriously "Feedback Implosion" is an established expression within
computer science. Thus although it may not be all correct we shouldn't
change it. I would recommend that you google "Feedback Implosion" all
the hits on the first page are related to computer science, at least for me.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Apr 2012 16:56:01 +0800

Hi,
----- Original Message ----- 
From: "Magnus Westerlund" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 13, 2012 4:37 PM
Subject: Re: review of draft-ietf-avtcore-feedback-supression-rtp-16.txt

> of the feedback target under the "weight" of all the feedback.

[Qin]: Exactly.

> change it. 

[Qin]: Agree. 

>I would recommend that you google "Feedback Implosion" all

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Apr 2012 11:06:55 +0200

In your previous mail you wrote:

> [Qin]:I can understand it is more sensitive to use "explosion" than
> "implosion" in France.:-)

=> both words exist in both language with the same spelling and
meaning.  Perhaps do you mean we are more attached to use the right
term in France (:-)?

> messages overwhelm the network capacity.

=> this is the definition of explosion.

>  If we change "implosion" into "explosion", we seems to change the
>  meaning of "feedback implosion", that is to say, "feedback
>  explosion " means feedback message has already paralyzed the
>  network. The Network dies :-).  I am aware that RFC4585 also use
>  "feedback implosion". Since this draft references RFC4585, Isn't
>  draft-ietf-avtcore-feedback-supression-rtp in accordance with
>  RFC4585?

=> you have the choice between using the correct term or keeping the
wrong term because some did the error in referenced documents.
You know my opinion.

Regards

PS: perhaps we should ask the RFC Editor to produce a collective
Errata to fix this misuse of implosion for explosion?

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Apr 2012 11:13:57 +0200

In your previous mail you wrote:

>  I would like to point out that feedback implosion actually can be
>  seen as an implosion event. All the feedback traffic generated are
>  concentrated at the target for the feedback. Thus causing an
>  implosion of the feedback target under the "weight" of all the
>  feedback.
>
>  But, seriously "Feedback Implosion" is an established expression
>  within computer science. Thus although it may not be all correct we
>  shouldn't change it. I would recommend that you google "Feedback
>  Implosion" all the hits on the first page are related to computer
>  science, at least for me.

=> hum, it seems the incorrect use of the term implosion is well
established. IMHO it should be like the use of the incorrect term
encrypted, so should be handled the same way: to fix it is the right
way in French, in English it is pedantic so in general should not be
fixed (and this is a real example for RFCs).

So I give up on it...

Thanks

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Apr 2012 17:18:43 +0800

Hi,
----- Original Message ----- 
From: "Francis Dupont" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, April 13, 2012 5:06 PM
Subject: Re: review of draft-ietf-avtcore-feedback-supression-rtp-16.txt 

> meaning.  Perhaps do you mean we are more attached to use the right

[Qin]: Yes.:-)

> => this is the definition of explosion.

[Qin]: please refer to Magnus's feedback on this thread in a separate email. 

[Qin]: Okay.

> You know my opinion.

[Qin]: Understand such ambiguity.