Justin (and *AD), Thank you for your reply. We have updated your status to “Approved” at the AUTH48 status page (see below).
We believe we are awaiting word from the *AD regarding the following: > We have updated to use Mo’s proposed text as related to question 10 (the text > sent to the WG). We will await *AD review/confirmation that we are okay to > go forward with this text: > > Current: > U: Switching up point. When this bit is set to one, if the > current picture has a temporal-layer ID equal to value T, then > subsequent pictures with temporal-layer ID values higher than T > will not depend on any picture before the current picture (in > decode order) with a temporal-layer ID value greater than T. We have sent along a request for IANA to update https://www.iana.org/assignments/media-types/video/VP9 to match Section 7 of this document. Once we confirm that the two match, we will mark IANA as concluded on the AUTH48 status page. Links below for the *ADs ease of use: Please review the files carefully as we do not make changes after publication. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9628.txt https://www.rfc-editor.org/authors/rfc9628.pdf https://www.rfc-editor.org/authors/rfc9628.html https://www.rfc-editor.org/authors/rfc9628.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9628-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9628-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9628-lastdiff.html (last to current version only) https://www.rfc-editor.org/authors/rfc9628-lastrfcdiff.html (ditto but side by side) Please contact us with any further updates/questions/comments you may have. We will await approvals from each of the parties listed on the AUTH48 status page prior to moving forward to publication. The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9628 Please see the AUTH48 status page for all documents here: https://www.rfc-editor.org/auth48/C324 Thank you. RFC Editor/mf > On Mar 13, 2025, at 12:18 PM, Justin Uberti <jus...@uberti.name> wrote: > > I see the address has been updated. I approve the publication of this > document. > > Justin > > On Fri, Mar 7, 2025 at 11:55 AM Jonathan Lennox <jonathan.len...@8x8.com> > wrote: > For this draft as well, I approve once the issue of Justin’s postal address > is resolved. > > > On Mar 4, 2025, at 2:11 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > > wrote: > > > > Authors (and *AD), > > > > Just checking in to see if you’ve had a chance to review the files posted > > and/or *AD queries in the emails below? > > > > Please let us know if any further changes are necessary or if you’d like to > > approve the current version. > > > > We are awaiting approvals from authors and *AD guidance/approval: once > > those are received, we will send any necessary updates to IANA registries > > to align them with the document. After the registry update(s) are > > confirmed, this document will be ready to move forward in the publication > > process with its cluster. > > > > The AUTH48 status page for this document is available here: > > > > https://www.rfc-editor.org/auth48/rfc9628 > > > > Please see the AUTH48 status page for all documents in the cluster here: > > > > https://www.rfc-editor.org/auth48/C324 > > > > Thank you. > > > > RFC Editor/mf > > > >> On Feb 21, 2025, at 3:10 PM, Megan Ferguson > >> <mfergu...@staff.rfc-editor.org> wrote: > >> > >> Just an update to add the following change to the AD review list: > >> > >>> In the definition of Picture ID, in section 4.2, in the phrase "if the > >>> field transitions from 15 bits to 7 bits, it is truncated (i.e., the > >>> value after 0x1bbe is 0xbf)” the value “0xbf” should be replaced by > >>> “0x3f”. (0xbf is not a 7-bit value.) > >> > >> Thank you. > >> > >> RFC Editor/mf > >> > >> > >>> On Feb 21, 2025, at 3:08 PM, Megan Ferguson > >>> <mfergu...@staff.rfc-editor.org> wrote: > >>> > >>> Hi Jonathan, Justin, and *AD, > >>> > >>> Thanks for your reply. > >>> > >>> We have updated to use Mo’s proposed text as related to question 10 (the > >>> text sent to the WG). We will await *AD review/confirmation that we are > >>> okay to go forward with this text: > >>> > >>> Current: > >>> U: Switching up point. When this bit is set to one, if the > >>> current picture has a temporal-layer ID equal to value T, then > >>> subsequent pictures with temporal-layer ID values higher than T > >>> will not depend on any picture before the current picture (in > >>> decode order) with a temporal-layer ID value greater than T. > >>> > >>> We are hoping to hear from Justin as to how to edit the postal address > >>> (affiliation has been updated as requested). > >>> > >>> Please review the files carefully as we do not make changes after > >>> publication. > >>> > >>> The files have been posted here (please refresh): > >>> https://www.rfc-editor.org/authors/rfc9628.txt > >>> https://www.rfc-editor.org/authors/rfc9628.pdf > >>> https://www.rfc-editor.org/authors/rfc9628.html > >>> https://www.rfc-editor.org/authors/rfc9628.xml > >>> > >>> The relevant diff files have been posted here (please refresh): > >>> https://www.rfc-editor.org/authors/rfc9628-diff.html (comprehensive diff) > >>> https://www.rfc-editor.org/authors/rfc9628-auth48diff.html (AUTH48 > >>> changes only) > >>> https://www.rfc-editor.org/authors/rfc9628-lastdiff.html (last to current > >>> version only) > >>> https://www.rfc-editor.org/authors/rfc9628-lastrfcdiff.html (ditto but > >>> side by side) > >>> > >>> Please contact us with any further updates/questions/comments you may > >>> have. > >>> > >>> We will await approvals from each of the parties listed on the AUTH48 > >>> status page prior to moving forward to publication. > >>> > >>> The AUTH48 status page for this document is available here: > >>> > >>> https://www.rfc-editor.org/auth48/rfc9628 > >>> > >>> Thank you. > >>> > >>> RFC Editor/mf > >>> > >>>> On Feb 21, 2025, at 1:53 PM, Jonathan Lennox <jonathan.len...@8x8.com> > >>>> wrote: > >>>> > >>>> I also notice that Justin’s affiliation was updated for 9627, but not > >>>> for 9628. > >>>> > >>>>> On Feb 21, 2025, at 3:51 PM, Jonathan Lennox <jonathan.len...@8x8.com> > >>>>> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On Feb 20, 2025, at 2:21 PM, Megan Ferguson > >>>>>> <mfergu...@staff.rfc-editor.org> wrote: > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> Thank you for your replies. We have updated according to the > >>>>>> responses we have received thus far to the document—specific and > >>>>>> cluster-wide queries. > >>>>>> > >>>>>> We had the following questions/comments to (hopefully) finish the list > >>>>>> of queries out: > >>>>>> > >>>>>> 1) Related to the cluster-wide bit name question: we suggest making no > >>>>>> changes to this document as we were able to glean these names from the > >>>>>> existing in-document descriptions (and no pattern seems to be changing > >>>>>> in RFC 9626 to use “the X (name) bit” format). > >>>>> > >>>>> Good. > >>>>> > >>>>>> > >>>>>> 2) Jonathan - please review the suggested text that uses “module” > >>>>>> where the document used “modulo”. We will await your reply prior to > >>>>>> closing this out. > >>>>>> > >>>>>>> Same item next paragraph, I realized the wording as written > >>>>>>> technically contradicts the first paragraph. The last sentence should > >>>>>>> read “Every picture containing a frame with show_frame==1, however, > >>>>>>> MUST have a unique timestamp module the 2^32 wrap of the field.” > >>>>>>> I.e., add “picture containing a” after “Every”. > >>>>> > >>>>> Thanks for catching that, yes, that was an autocorrect error. It > >>>>> should indeed be “modulo”. > >>>>> > >>>>> > >>>>>> 3) Just a reminder that this document has a question out to the WG and > >>>>>> that IANA updates to match the changes in the Media Type Registration > >>>>>> in Section 7 will be requested once all author approvals are received > >>>>>> (as possible delays to moving forward in the publication process). > >>>>> > >>>>> Mo had a response to the WG mail about that language — I agree with > >>>>> him, the parenthetical phrase would be better as “(in decoding order)” > >>>>> to match other usages. > >>>>> > >>>>> > >>>>> I also have two more changes for this document: > >>>>> > >>>>> In the definition of Picture ID, in section 4.2, in the phrase "if the > >>>>> field transitions from 15 bits to 7 bits, it is truncated (i.e., the > >>>>> value after 0x1bbe is 0xbf)” the value “0xbf” should be replaced by > >>>>> “0x3f”. (0xbf is not a 7-bit value.) > >>>>> > >>>>> The title of section 4.5 should be “Example of a VP9 RTP Stream”, > >>>>> because there is only one example. > >>>>> > >>>>> Thank you! > >>>> > >>> > >> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
