Subject: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 3 Jan 2019 20:49:41 +0000

Hello All,
Please note that this latest version is in response to the AD review and covers the review provided in [1]-[4].

There are a couple of substantive changes based on AD review (versus version -13) of which the group should be aware:

  1.  Sec. 4.2.1.  Under the description of the SSRC field, the following requirement was previously a SHOULD:  “"The repair streams’ SSRC’s CNAME MUST be identical to the CNAME of the source RTP stream(s) that this repair stream protects.”
  2.  Sec. 5.1.  All media types are no longer provisionally registered.

In addition, there were a couple of re-wordings that were not directly covered in my latest review response [4]:

  1.  Under Figures 10 and 12 the description of the Repair Payload has been changed:  “The Repair "Payload", which follows the FEC Header, includes repair of everything following the fixed 12-byte RTP header of each source packet, including any CSRC identifier list and header extensions if present.”
  2.  In Sec. 5.2.2, the references to RTSP were further clarified:  “In declarative usage, like SDP in the Real-time Streaming Protocol (RTSP, for RTSP 1.0 see [RFC2326] and for RTSP 2.0 see [RFC7826]) …”

I hope this addresses all concerns.  However, if it does not, please make myself and all co-editors aware of any necessary modifications.  I would much rather submit another I.-D. version than an errata on an RFC.

Thanks,
-Giri Mandyam

[1] https://mailarchive.ietf.org/arch/msg/payload/tT4lQ_oVsDWuRmcFn7OImwy87oo
[2] https://mailarchive.ietf.org/arch/msg/payload/vfiVlSDhj-WY985KJ4Kinmjzxds
[3] https://mailarchive.ietf.org/arch/msg/payload/kx_C9UjQpE2ItfCYkE3eJMgKSPk
[4] https://mailarchive.ietf.org/arch/msg/payload/t-JKXuPvIeJ9VDbqw7pDwyc9vfA

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Jan 2019 10:26:19 +0000

Hi,

In regard to the below.

On 2019-01-03 21:50, Giridhar Mandyam wrote:

There was actually a reason for this SHOULD. That should likely have been written out explicitly. In case of a RTP middlebox adding FEC to one or more streams it forwards towards to a downstream receiver or other middlebox then it can't use the CNAME of the source stream if there are multiple ones from different sources. Secondly, even if it forwards only from one, that SSRC sending the FEC stream probably shouldn't be required to give the impression that it is the source entity doing this. In some cases RTP middleboxes are considering doing this on behalf of the original source, but not always.

Thus, I am opposed to make this change. I rather add an exception statement after the SHOULD.

The repair streams’ SSRC’s CNAME SHOULD be identical to the CNAME of the source RTP stream(s) that this repair stream protects. An FEC stream that protects multiple source RTP streams with different CNAMEs uses the CNAME associated with entity generating the FEC stream or the CNAME of the entity on whose behalf it perform the protection operation.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

---

From: "Roni Even (A)" <[email-masked]>
Date: Mon, 7 Jan 2019 11:30:42 +0000

Hi Magnus,
This also what I thought specially the case of multiple sources.
Roni Even as Individual

From: Magnus Westerlund [mailto:[email-masked]]
Sent: Monday, January 07, 2019 12:26 PM
To: Giridhar Mandyam; [email-masked]; [email-masked]; Ben Campbell
Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

Hi,

In regard to the below.

  1.  Sec. 4.2.1.  Under the description of the SSRC field, the following requirement was previously a SHOULD:  ""The repair streams' SSRC's CNAME MUST be identical to the CNAME of the source RTP stream(s) that this repair stream protects."

The repair streams' SSRC's CNAME SHOULD be identical to the CNAME of the source RTP stream(s) that this repair stream protects. An FEC stream that protects multiple source RTP streams with different CNAMEs uses the CNAME associated with entity generating the FEC stream or the CNAME of the entity on whose behalf it perform the protection operation.

Cheers

Magnus Westerlund

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 7 Jan 2019 18:38:42 +0000

Hi All,

I am in favor of making the change Magnus recommended below.  My apologies - I did not consider all use cases when responding to the AD review.  I will submit a revision next week (with this change and any other requested changes), assuming there are no objections.

-Giri

From: Roni Even (A) <[email-masked]>
Sent: Monday, January 7, 2019 3:31 AM
To: Magnus Westerlund <[email-masked]>; Giridhar Mandyam <[email-masked]>; [email-masked]; [email-masked]; Ben Campbell <[email-masked]>
Subject: RE: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

CAUTION: This email originated from outside of the organization.
Hi Magnus,
This also what I thought specially the case of multiple sources.
Roni Even as Individual

From: Magnus Westerlund [mailto:[email-masked]]
Sent: Monday, January 07, 2019 12:26 PM
To: Giridhar Mandyam; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ben Campbell
Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

Hi,

In regard to the below.

Cheers

Magnus Westerlund

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Jan 2019 16:21:39 -0600

Hi Giri,

I’ve looked at the update. I agree with Magnus’s recommendation.

Additionally, when I suggested using “[email-masked] <mailto:[email-masked]>” for the contact for IANA registrations, I did not mean to change the “author” field to that for the registrations that include an author. The point is to list the IESG as a contact for future communications, not to attribute authorship credit.

On a related note, in section 5.1.3, it shows “[email-masked] <mailto:[email-masked]>” as “[email-masked] <mailto:[email-masked]>”.

Please submit the new revision when you are ready.

Thanks!

Ben.

> On Jan 7, 2019, at 12:38 PM, Giridhar Mandyam <[email-masked]> wrote:
> 
> Hi All,
> 
> I am in favor of making the change Magnus recommended below.  My apologies – I did not consider all use cases when responding to the AD review.  I will submit a revision next week (with this change and any other requested changes), assuming there are no objections.
> 
> -Giri
> 
> From: Roni Even (A) <[email-masked] <mailto:[email-masked]>>
> To: Magnus Westerlund <[email-masked] <mailto:[email-masked]>>; Giridhar Mandyam <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Ben Campbell <[email-masked] <mailto:[email-masked]>>
> From: Magnus Westerlund [mailto:[email-masked] <mailto:[email-masked]>]
> To: Giridhar Mandyam; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; Ben Campbell
> Sec. 4.2.1.  Under the description of the SSRC field, the following requirement was previously a SHOULD:  “"The repair streams’ SSRC’s CNAME MUST be identical to the CNAME of the source RTP stream(s) that this repair stream protects.”
> 
> 
> SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 14 Jan 2019 16:41:26 -0600

I see version 15 is posted. The IANA changes do not quite reflect what I was trying to say:

The "Person & email address to contact for further information:” should refer to the IESG <[email-masked]>. They currently say “Varun Singh <[email-masked]>" which is the correct email address but the wrong display name.

Along the same lines, I was asking to have the “Author” fields changed back to Varun. They now say "Varun Singh <[email-masked]>” which is the correct display name but the wrong email address.

Thanks!

Ben.

> On Jan 7, 2019, at 4:21 PM, Ben Campbell <[email-masked]> wrote:
> 
> Signed PGP part
> Hi Giri,
> 
> Additionally, when I suggested using “[email-masked]” for the contact for IANA registrations, I did not mean to change the “author” field to that for the registrations that include an author. The point is to list the IESG as a contact for future communications, not to attribute authorship credit.
> 
> On a related note, in section 5.1.3, it shows “[email-masked]” as “[email-masked]”.
> 
>> 	• Sec. 4.2.1.  Under the description of the SSRC field, the following requirement was previously a SHOULD:  “"The repair streams’ SSRC’s CNAME MUST be identical to the CNAME of the source RTP stream(s) that this repair stream protects.”
>> 
>> 
>> SE-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 14 Jan 2019 22:52:27 +0000

Sorry about that.  

Regarding IESG <[email-masked]> -  IESG isn't really a person.  Can I change "Person & email address to contact for further information:" to "Email address to contact for further information:"?

Regarding:  "Varun Singh <[email-masked]>”, I thought the intent was to be able to contact the author regardless of whether their email address changes.  But I can put the original email address back in the revision.

Thanks,

-Giri Mandyam

-----Original Message-----
From: Ben Campbell <[email-masked]> 
Sent: Monday, January 14, 2019 2:41 PM
To: Giridhar Mandyam <[email-masked]>
Cc: Adam Roach <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

Thanks!

Ben.

>> To: Magnus Westerlund <[email-masked]>; Giridhar 
>> Mandyam <[email-masked]>; 
>> [email-masked]; 
>> [email-masked]; Ben Campbell <[email-masked]>
>> To: Giridhar Mandyam; 
>> [email-masked]; 
>> [email-masked]; Ben Campbell
>> ---------------------------------------------------------------------
>> - Network Architecture & Protocols, Ericsson Research

---

From: Ben Campbell <[email-masked]>
Date: Mon, 14 Jan 2019 16:55:21 -0600

> On Jan 14, 2019, at 4:52 PM, Giridhar Mandyam <[email-masked]> wrote:
> 
> Sorry about that.
> 
> Regarding IESG <[email-masked]> -  IESG isn't really a person.  Can I change "Person & email address to contact for further information:" to "Email address to contact for further information:”?

Well, I guess the IESG is made of persons :-) I’d leave it as is rather than change the template.

> Regarding:  "Varun Singh <[email-masked]>”, I thought the intent was to be able to contact the author regardless of whether their email address changes.  But I can put the original email address ba…

Putting the iesg address in the “for further information” field is enough to accomplish that.

Thanks!

Ben.

>>> -

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 17 Jan 2019 19:58:36 +0000

Version 16 now posted to address the comments below.
Thanks,

-Giri Mandyam

-----Original Message-----
From: Ben Campbell <[email-masked]> 
Sent: Monday, January 14, 2019 2:55 PM
To: Giridhar Mandyam <[email-masked]>
Cc: Adam Roach <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes

Thanks!

Ben.

> Cc: Adam Roach <[email-masked]>; [email-masked]; 
> [email-masked]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 18 Jan 2019 16:47:30 -0600

Thanks!

I will coordinate with Adam to request IETF LC for this and for the related RTCWEB draft.

Ben.

> On Jan 17, 2019, at 1:58 PM, Giridhar Mandyam <[email-masked]> wrote:
>