[AVTCORE] Re: AD review : draft-ietf-avtcore-rtp-payload-registry

[Zaheduzzaman Sarker <[e-mail]>]

On Fri, Sep 13, 2024 at 11:05 AM Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
>
>
> We are changing the text of RFC 8088, for that reason we need a normative
> reference, i.e. this spec affects this document of a lower status. This is
> one of these cases where the down-ref is obvious to happen, but also
> non-problematic. Just note it in the IETF last call, no one will object.
>

That part I already know :-).

RFC 8088 is informaitonal, so what I am trying to understand - why do we
need a PS to update an information spec?
//Zahed


>
>
> /Magnus
>
>
>
>
>
> *From: *Zaheduzzaman Sarker <[e-mail]>
> *Date: *Friday, 13 September 2024 at 10:44
> *To: *Magnus Westerlund <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *Re: [AVTCORE] AD review :
> draft-ietf-avtcore-rtp-payload-registry
>
> Thanks Magnus.
>
>
>
> One more thing, is this necessary to have RFC8088 as normative reference?
>
>
>
> And for my information and for the record, why do we need this
> specification to be standard track? Was this a requirement from IANA or any
> registry policy? As we don't even know the souce of the registry and hence
> no policy attached to it, wouldn't a infomation RFC can also do this job?
>
>
>
> //Zahed
>
>
>
> On Fri, Sep 13, 2024 at 8:56 AM Magnus Westerlund <
> [e-mail]> wrote:
>
> Hi Zahed,
>
>
>
> Yes, your sentences are clearer. I have substituted the paragraph and
> submitted -02.
>
>
>
> /Magnus
>
>
>
> *From: *Zaheduzzaman Sarker <[e-mail]>
> *Date: *Thursday, 12 September 2024 at 15:21
> *To: *[e-mail] <[e-mail]>
> *Subject: *[AVTCORE] AD review : draft-ietf-avtcore-rtp-payload-registry
>
> Hi,
>
>
>
> Thanks for working on closing the unused registry where we even don't how
> it was created.
>
> I have an editorial suggestion. Then following text is well understandable
> in the introducton section however, it is kind of not that well conducted
> in abstract. I have following proposal
>
> OLD:
>
> To resolve this situation this document performs the following.
>
>    First it updates the registry to include known RTP payload formats at
>
>    the time of writing.  Then it closes the IANA Registry for RTP
>
>    Payload formats Media Types for future registration.  Beyond
>
>    instructing IANA to close this registry, the instructions to authors
>
>    in RFC 8088 are updated to reflect this.
>
>
>
> NEW:
>
>
>
> This document resolves the situation by first updating the RTP Payload Format Media Type registry to include all the known RTP payload formats at
>
>    the time of writing, then it closes this IANA Registry for any future registration.  Beyond
>
>    instructing IANA to close this registry, the instructions to authors
>
>    in RFC 8088 are updated to reflect this.
>
>
>
>
>
> If this is something that makes sense, then please update the draft and I
> will directly start the IETF LC.
>
>
>
> //Zahed
>
>