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

[Zaheduzzaman Sarker <[e-mail]>]

Thanks Bernard, thanks Magnus for the resolution.

//Zahed

On Fri, 20 Sep 2024 at 02:50, Bernard Aboba <[e-mail]> wrote:

> I updated the shepard writeup to provide the justification for the
> Proposed Standard designation, along the lines that Magnus provided.
>
> On Wed, Sep 18, 2024 at 9:18 AM Zaheduzzaman Sarker <
> [e-mail]> wrote:
>
>>
>>
>> On Wed, Sep 18, 2024 at 4:41 PM Magnus Westerlund <
>> [e-mail]> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Please see below. If you are not happy with the answer lets schedule an
>>> call to try to resolve this so that we don’t spend too much time on it.
>>>
>>>
>>>
>>> *From: *Zaheduzzaman Sarker <[e-mail]>
>>> *Date: *Tuesday, 17 September 2024 at 14:38
>>> *To: *Bernard Aboba <[e-mail]>
>>> *Cc: *Magnus Westerlund <[e-mail]>, [e-mail] <
>>> [e-mail]>
>>> *Subject: *Re: [AVTCORE] Re: AD review :
>>> draft-ietf-avtcore-rtp-payload-registry
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Sep 17, 2024 at 2:02 PM Bernard Aboba <[e-mail]>
>>> wrote:
>>>
>>> Magnus said:
>>>
>>>
>>>
>>> "I think both I and the chairs defaulted to Proposed due to the IANA
>>> registration rule changes."
>>>
>>>
>>>
>>> [BA] Yes.  In particular, the IANA rule changes will affect the IANA
>>> considerations section of future standards track documents.
>>>
>>>
>>>
>>> How is that? We closing an registry and updating the instructions, how
>>> is that going to affect future PS? I am trying to understand.
>>>
>>>
>>>
>>> MW: So I assume what Bernard meant here is the praxis (encoded in RFC
>>> 8088) to in all RTP Payload format specification (including the standards
>>> track) to register the RTP Payload format, and this document changes what
>>> we are expected to do. Thus, affecting what is written in future standards
>>> track documents.
>>>
>>>
>>>
>>> So the arguments for making this PS is that having scrutinized this
>>> change on PS level ensures that we have established sufficient consensus to
>>> make this change and close this registry which was created in relation to
>>> an standards track RFC 4855.
>>>
>>>
>>>
>>> If IANA and the IESG is okay to take this document through despite it is
>>> unclearness in how the registry came into existence as Informational then I
>>> fine with this. I think you simple have to ask yourselves what will cause
>>> least problem here.
>>>
>>
>> That is what I am trying to do :-).
>>
>>
>>> It appears that both I as author and the WG chairs think PS would cause
>>> the least amount of future issue with this document. If you as AD have
>>> indication that this would not be the case then change the intended status.
>>>
>>>
>>>
>>> I don’t think you will get much clearer answer, at least my choice is
>>> based on the unclarity in how the registry came into existence and by
>>> ensuring this have been reviewed as a standards action it can’t be
>>> questioned after its approval.
>>>
>>
>> This argument that due to unclarity of existance of the registry the WG
>> agreed to have a PS document to close this. This makes sense to me. I would
>> like the document shepherd ( @[e-mail] ) to capture this
>> in the write-up. I will proceed when this is done.
>>
>> Thanks for the cooperation!!
>>
>> //Zahed
>>
>>
>>
>>
>>>
>>>
>>> /Magnus
>>>
>>>
>>>
>>>
>>>
>>>