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

[Giridhar Mandyam <[e-mail]>]

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

-Giri Mandyam

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



> On Jan 14, 2019, at 4:52 PM, Giridhar Mandyam <[e-mail]> wrote:
> 
> Sorry about that.
> 
> Regarding IESG <[e-mail]> -  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 <[e-mail]>”, 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.

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

Thanks!

Ben.

> 
> Thanks,
> 
> -Giri Mandyam
> 
> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Sent: Monday, January 14, 2019 2:41 PM
> To: Giridhar Mandyam <[e-mail]>
> Cc: Adam Roach <[e-mail]>; [e-mail]; 
> [e-mail]
> Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14 notes
> 
> 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 <[e-mail]>. They currently say “Varun Singh <[e-mail]>" 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 <[e-mail]>” which is the correct display name but the wrong email address.
> 
> Thanks!
> 
> Ben.
> 
>> On Jan 7, 2019, at 4:21 PM, Ben Campbell <[e-mail]> wrote:
>> 
>> Signed PGP part
>> Hi Giri,
>> 
>> I’ve looked at the update. I agree with Magnus’s recommendation.
>> 
>> Additionally, when I suggested using “[e-mail]” 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 “[e-mail]” as “[e-mail]”.
>> 
>> Please submit the new revision when you are ready.
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> 
>>> On Jan 7, 2019, at 12:38 PM, Giridhar Mandyam <[e-mail]> 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) <[e-mail]>
>>> Sent: Monday, January 7, 2019 3:31 AM
>>> To: Magnus Westerlund <[e-mail]>; Giridhar 
>>> Mandyam <[e-mail]>; 
>>> [e-mail];
>>> [e-mail]; Ben Campbell <[e-mail]>
>>> 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:[e-mail]]
>>> Sent: Monday, January 07, 2019 12:26 PM
>>> To: Giridhar Mandyam;
>>> [e-mail];
>>> [e-mail]; Ben Campbell
>>> Subject: Re: [payload] draft-ietf-payload-flexible-fec-scheme-14
>>> notes
>>> 
>>> Hi,
>>> 
>>> In regard to the below.
>>> 
>>> On 2019-01-03 21:50, Giridhar Mandyam wrote:
>>> 
>>> There are a couple of substantive changes based on AD review (versus version -13) of which the group should be aware:
>>> 
>>> 	• 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.”
>>> 
>>> 
>>> 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  [phone]
>>> Torshamnsgatan 23           | Mobile [phone]
>>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>>> --------------------------------------------------------------------
>>> -
>>> -
>> 
>> 
>> 
>