Re: [payload] New version of draft-ietf-payload-vp8

[Colin Perkins <[e-mail]>]

Remind me?

> On 22 Sep 2015, at 21:57, Harald Alvestrand <[e-mail]> wrote:
> 
> Would you be OK with the shorter version I suggested?
> 
> Den 22. september 2015 22:51:55 CEST, skrev Colin Perkins <[e-mail]>:
>  On 22 Sep 2015, at 18:32, Harald Alvestrand <[e-mail]> wrote:
>  
>  On 09/22/2015 04:40 PM, Ben Campbell wrote:
>  Hi Harald,
>  
>  I will check with Alissa to see if her concerns have been addressed.
>  
>  Has there been closure on Elwyn's Gen-ART telechat review and on
>  Colin's comments on the payload list? I was under the impression that
>  at least Colin's comments might result in an update (although we can
>  handle minor changes with RFC editor notes)
>  
>  Also, I had some comments a while back to which I do not recall seeing
>  a response:
>  
>  -- section 3, Payload Type: "... the VP8 RTP payload profile MUST
>  assign a dynamic payload type number ..."
>  
>  If I read correctly, Colin Perkins objected to this change. Did you
>  consider his objection?
>  I asked in response if we can delete the whole thing about payload type
>  assignment, since it's not a proper concern of the payload type. I did
>  not get a response, so I thought it couldn’t be important.
> 
> I thought the question was for others in the working group. My opinion is that we do need text here, and I proposed something I thought appropriate, although I’m open to other suggestions. The current text does need to be changed, however.
> 
> Colin
> 
> 
> 
> 
> 
>  
>  -- 4.2
>  
>  I didn't see anything addressing Elwyn's Gen-ART (last call) review
>  question about: “What happens if L=1 but both T=0 and K=0 so that
>  there is no TID value present? Or indeed if T=0 but K=1 so that the
>  TID field is there but 'MUST be ignored by the receiver'  (definition
>  of TID field)?” Did I miss something?
>  
>  On this matter, we thought the text was clear that those streams would
>  be illegal, and we don't specify the processing of illegal streams. But
>  if it isn't clear that it's illegal, we may want to reconsider.
>  
>  Thanks!
>  
>  Ben.
>  
>  
>  On 10 Sep 2015, at 11:24, Harald
> Alvestrand wrote:
>  
>  On 09/10/2015 03:28 AM, Colin Perkins wrote:
>  On 9 Sep 2015, at 23:12, Ben Campbell <[e-mail]> wrote:
>  
>  On 9 Sep 2015, at 16:01, Henrik Lundin wrote:
>  
>  We have made no technical changes to the document, but have added
>  a number of grammar updates and clarifications. Some of the
>  important clarifications are as follows:
>  Payload participants: Please note that there are in fact changes to
>  2119 language in this version. I
> won't quibble about whether or not
>  those count as "technical" changes, but please take a moment to
>  review them. If people object to any of them please say so asap ,
>  as this draft will likely be on the agenda for the IESG telechat
>  next week.
>  The new text about the Payload Type in Section 4.1 says:
>  
>  Payload type (PT):  In line with the policy in Section 3 of
>   [RFC3551], applications using the VP8 RTP payload profile MUST
>   assign a dynamic payload type number to be used in each RTP
>   session and provide a mechanism to indicate the mapping.  See
>   Section 6.2 for the mechanism to be used with the Session
>   Description Protocol (SDP) [RFC4566].
>  
>  This would be okay, except that RTP profiles that don’t derive from
>  RFC 3551 could be defined. A better wording might be:
>  
>  Payload Type (PT): The assignment of an RTP payload type for this
>  packet format is outside the scope of
> this document and will not be
>  specified here.  It is expected that the RTP profile for a particular
>  class of applications will assign a payload type for this encoding,
>  or if that is not done, then a payload type in the dynamic range
>  SHALL be chosen by means of an out-of-band signaling protocol. See
>  Section 6.2 for the mechanism to be used with the Session Description
>  Protocol (SDP) [RFC4566].
>  
>  
>  In Section 4.2, rather than add a note that “this X bit is not to be
>  confused with the X bit in the RTP header”, would it not make sense
>  to rename this X bit?
>  
>  We considered this option, but decided that having a large existing body
>  of documentation outside of the IETF that refers to the "X bit" and
>  having a payload type registration that called it something else, it ws
>  better to keep the name and just make a note that it's different.
>  
>  Similarly for the M bit in the extension data fields, and the P bit
>  in the payload header (which isn’t mentioned). Or, at least,
>  annotate each mention of these fields to say which X, M, or P bit it
>  required (e.g., “the P bit in the payload header” or “the P bit in
>  the RTP header” rather than “the P bit”).
>  
>  This can be done, and probably should be done for any reference that
>  occurs outside of the section describing the VP8 payload descriptor
>  (section 4.2) - I couldn't find any such references.
>  
>  There is no P bit in the VP8 payload descriptor, but there is one in the
>  VP8 payload header, which is why we missed warning about the name
>  collision there. It's never referred to in text.
>  
>  
>  
>  Colin
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  -- 
>  Surveillance is pervasive. Go Dark.
>  
>  
> 
>  payload mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/payload <https://www.ietf.org/mailman/listinfo/payload>
>  
>  
>  -- 
>  Surveillance is pervasive. Go Dark.
>  
> 
>  payload mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/payload <https://www.ietf.org/mailman/listinfo/payload>
> 
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.



-- 
Colin Perkins
https://csperkins.org/