Re: [AVTCORE] AD Evaluation of draft-ietf-avtcore-rfc5764-mux-fixes-10

["Ben Campbell" <[e-mail]>]

On 19 Jul 2016, at 15:24, Gonzalo Salgueiro (gsalguei) wrote:

[...]

>>
>> On 19 Jul 2016, at 14:53, Gonzalo Salgueiro (gsalguei) wrote:
>>
>>> Hi Ben -
>>>
>>> Comments inline…
>>>
>>>> On Jul 16, 2016, at 11:56 PM, Ben Campbell <[e-mail]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> This is my AD Evaluation of 
>>>> draft-ietf-avtcore-rfc5764-mux-fixes-10. I think these comments can 
>>>> be addressed in parallel to the IETF last call, so I'm going to 
>>>> request that shortly.
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>>> Substantive Comments:
>>>>
>>>>
>>>> - This draft has a pre-RFC5378 disclaimer. Is that really needed? 
>>>> Am I correct it is due to the excerpted "OLD" text from RFC5764? If 
>>>> so, has anyone checked with the authors of that (Ekr and David 
>>>> McGrew) about whether they would agree to let this draft progress 
>>>> without the disclaimer?
>>>
>>> We sent an email to David McGrew and EKR asking to publish without 
>>> the pre-RFC5378 disclaimer. McGrew was in favor but EKR stated "I am 
>>> not sure that all the text in 5764 is pre-5378, so probably better 
>>> to be safe.”  This is the reason we have proceeded with the 
>>> disclaimer.
>>>
>>
>> I'm okay leaving the disclaimer if there is a reason. But I'm a bit 
>> confused about the quote from ERK. Text that is _not_ pre-5378 
>> shouldn't matter.
>
> I can add you to the thread and perhaps you can shed light on that for 
> EKR.

Maybe :-) I mainly wanted to make sure that the sense of his comment had 
not gotten reversed along the way (or in my own reading...)

>
>>>> -1, last paragraph:
>>>>
>>>> Are there any plans to fix 7345 or bundle-negotiation?
>>>
>>> I co-authored 7345 with Christer, so we can have a discussion about 
>>> fixing that one.
>>
>> Okay
>>
>>>
>>>> I see that 7345 replicates language from 5764 rather than 
>>>> references it, but it looks like a fairly easy fix.
>>>
>>> Are you think bis effort?
>>
>> ... or an update.
>
> I was thinking bis=update, so we can get that going once mux-fix gets 
> published.

I guess I meant a minor, focused update, rather than a complete 
revision.

>

[...]

>>>> Editorial Comments:
>>>>

[...]

>>>> Also, I'm a little confused by the last sentence--what is the point 
>>>> of "even if a codepoint is not initially thought to be useful”?
>>>
>>> Good catch.  Perhaps it would be clearer to say "even if the feature 
>>> related to a codepoint is not initially thought to be useful in the 
>>> context of demultiplexing”?
>>
>> I'm still a little confused. " by not useful" do you mean codepoints 
>> that do not affect demuxing? Why does this draft need to talk about 
>> such codepoints?
>
> Well the added text was meant to reduce scope to "useful in the 
> context of demultiplexing”.  So it is my intent to specifically 
> refer to codepoints that might make use of demux.

Okay.