Subject: [payload] #2: Section 8.2: Updates RFC 4585?

From: "payload issue tracker" <[email-masked]>
Date: Tue, 10 Dec 2013 02:13:34 -0000

#2: Section 8.2:  Updates RFC 4585?

 Use of the RPSI feedback message as positive acknowledgement is
    deprecated.  In other words, the RPSI feedback message MUST only be
    used as a reference picture selection request, such that it can also
    be used in multicast.

 This appears to update RFC 4585 Section 6.3.1.1 and yet the document does
 not have an Updates: RFC 4585 in the header.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-payload-
  [email-masked]          |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:  milestone1
Component:  rtp-h265                 |    Version:  1.0
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/2>
payload <http://tools.ietf.org/payload/>

---

From: "payload issue tracker" <[email-masked]>
Date: Tue, 10 Dec 2013 03:50:51 -0000

Comment (by [email-masked]):

 Another reason for Updates: RFC 4585 is that Section 8.1 defines the SPLI
 Feedback Message.

 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/2#comment:1>
payload <http://tools.ietf.org/payload/>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 10 Dec 2013 21:50:15 +0000

Hi Bernard,

I don¹t think it would be a particularly good idea if every payload format
spec is marked as ³updating² a general purpose spec when *for that payload
only* the payload spec allows/disallows/modifies aspects of the general
purpose spec.  

Hi Chairs: any guidance?

Thanks,
Stephan

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Dec 2013 14:59:32 -0800

I didn't understand from the text that the modification was only for H.265.   I had assumed that the references to feedback messages (and new message definition) was for all codecs.   
 
> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> CC: [email-masked]
> Subject: Re: [payload] #2: Section 8.2:  Updates RFC 4585?
> Date: Tue, 10 Dec 2013 21:50:15 +0000
> 
> Hi Bernard,
>

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Tue, 10 Dec 2013 23:23:17 +0000

We had the intention that those related to RFC 4585 in draft-ietf-payload-rtp-h265 are only for H.265.

OK, then I think we just need to make this intention clearly said in the draft. Will include this clarification into the next version.

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, December 10, 2013 3:00 PM
To: Stephan Wenger; payload issue tracker; [email-masked]
Cc: [email-masked]
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> CC: [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> >Comment (by [email-masked]<mailto:[email-masked]>):
> >
> > [email-masked]<mailto:[email-masked]> | [email-masked]<mailto:[email-masked]>

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Wed, 11 Dec 2013 00:14:24 +0000

Sorry, Bernard, I replied too quickly.

In the draft, we define the following in section 8:

1)      The SPLI Feedback Message (in 8.1)

2)      Use of HEVC with the RPSI Feedback Message (in 8.2)

3)      Use of HEVC with the SPLI Feedback Message (in 8.3)

Only items 2 and 3 are only for H.265, while the first item defined in section 8.1 also applies to other codecs, and we even have the following note included in the section:

Informative note: The SPLI message defined in this memo also applies to other codecs, and may later be moved to another extension of RFC 4585.

Thus, your suggestion still needs to be considered.

Would it be sufficient to just add "Updates RFC 4585", or it would actually better to document the SPLI feedback message in a non-codec-specific document?

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Wang, Ye-Kui
Sent: Tuesday, December 10, 2013 3:23 PM
To: Bernard Aboba; Stephan Wenger; payload issue tracker; [email-masked]
Cc: [email-masked]
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, December 10, 2013 3:00 PM
To: Stephan Wenger; payload issue tracker; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Dec 2013 19:16:02 -0800

I am ok with whatever path you and the WG agree on. However it is a bit obscure to add a general capability within an H.265 payload document, so if that path is chosen, the generality should be made clear for example, in the abstract.

> On Dec 10, 2013, at 4:14 PM, "Wang, Ye-Kui" <[email-masked]> wrote:
> 
> Would it be sufficient to just add “Updates RFC 4585”, or it would actually better to document the SPLI feedback message in a non-codec-specific document?
>  
> BR, YK
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 11 Dec 2013 10:31:57 +0000

I agree with Stephan here. As long as these are h265 related, I dont think we need to "update" 4585.

On Dec 10, 2013, at 1:50 PM, Stephan Wenger <[email-masked]> wrote:

> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "Roni Even" <[email-masked]>
Date: Wed, 11 Dec 2013 13:31:43 +0200

Hi,

My first comment is that the value 8 that you want for the SPLI message is
already assigned
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-para
meters-9

So ask an allocation from IANA.

As for Bernard comment.

My view is that you should clarify the text in 8.2  to clarify that you are
not changing RFC 4585 (deprecate is not the right term) but only make a
change for HEVC.

As for the new message SPLI in section 8.1, if it is for all codec like the
section states it will be good to specify it very clearly that this is the
only update to RFC4585. Still I suggest  that it will be clearer in a
separate document that will be an update to RFC4585.  

Roni Even

Payload co-chair

From: payload [mailto:[email-masked]] On Behalf Of Wang, Ye-Kui
Sent: 11 December, 2013 2:14 AM
To: Bernard Aboba; Stephan Wenger; payload issue tracker;
[email-masked]
Cc: [email-masked]
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

Only items 2 and 3 are only for H.265, while the first item defined in
section 8.1 also applies to other codecs, and we even have the following
note included in the section:

Informative note: The SPLI message defined in this memo also applies to
other codecs, and may later be moved to another extension of RFC 4585.

Would it be sufficient to just add “Updates RFC 4585”, or it would actually
better to document the SPLI feedback message in a non-codec-specific
document?

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Wang, Ye-Kui
Sent: Tuesday, December 10, 2013 3:23 PM
To: Bernard Aboba; Stephan Wenger; payload issue tracker;
[email-masked]
Cc: [email-masked]
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

We had the intention that those related to RFC 4585 in
draft-ietf-payload-rtp-h265 are only for H.265.

OK, then I think we just need to make this intention clearly said in the
draft. Will include this clarification into the next version.

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, December 10, 2013 3:00 PM
To: Stephan Wenger; payload issue tracker;
[email-masked]
Cc: [email-masked]
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

I didn't understand from the text that the modification was only for H.265.
I had assumed that the references to feedback messages (and new message
definition) was for all codecs.   

> From: [email-masked]
> To: [email-masked];
[email-masked]; [email-masked]

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Wed, 11 Dec 2013 18:16:34 +0000

Hi Roni,

Thanks for your advices. I will check how to get an allocation from IANA.

On the SPLI in section 8.1, if we go with a separate document, should we keep that in the PAYLOAD WG (as this part is now a part of an official draft of the PAYLOAD WG), or make it to a different WG? And in either case, should it start with an individual draft or a WG draft?

If the process is going to be complicated, maybe it would be easier just to keep it here in this draft, but as Bernard and you suggested, say it clearly in the abstract that there is something that updates RFC 4585 here, and clearly say in the text that there is only one aspect that  updates RFC 4585.

But we will surely follow whatever the WG agrees :)

BR, YK

From: payload [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Wednesday, December 11, 2013 3:32 AM
To: Wang, Ye-Kui; 'Bernard Aboba'; 'Stephan Wenger'; 'payload issue tracker'; [email-masked]
Cc: [email-masked]
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

Hi,
My first comment is that the value 8 that you want for the SPLI message is already assigned http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-9
So ask an allocation from IANA.

As for Bernard comment.
My view is that you should clarify the text in 8.2  to clarify that you are not changing RFC 4585 (deprecate is not the right term) but only make a change for HEVC.
As for the new message SPLI in section 8.1, if it is for all codec like the section states it will be good to specify it very clearly that this is the only update to RFC4585. Still I suggest  that it will be clearer in a separate document that will be an update to RFC4585.

Roni Even
Payload co-chair

To: Bernard Aboba; Stephan Wenger; payload issue tracker; [email-masked]<mailto:[email-masked]>

BR, YK

To: Bernard Aboba; Stephan Wenger; payload issue tracker; [email-masked]<mailto:[email-masked]>

BR, YK