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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

> On Jul 19, 2016, at 3:06 PM, Ben Campbell <[e-mail]> wrote:
> 
> Thanks, comments also inline:
> 
> Ben.
> 
> 
> 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.

>>> -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.

>> or filing an errata?
> 
> I don't think errata is the correct approach. That's more for minor errors where a draft doesn't reflect the authors' intent at the time of writing. That doesn't seem to be the case here.

Agreed.

>>> I wonder if bundle-negotiation really needs a fix beyond the fact that it's reference to 5764 will effectively inherit any fixes due to the obsolescence of 5764.
>> 
>> Bundle isn’t published, so presumably they are in time to fix it.  I’ll leave that one to you to handle in the best way possible.
> 
> Good point :-)
> 
>> 
>>> This paragraph will likely be overtaken by events at some point. Remember that an RFC lasts forever. Language to the effect of "at the time of this writing" might be helpful.
>> 
>> OK, we can prepend to the first sentence of the last paragraph something like what you suggest, namely "at the time of this writing”.  Would that work
> 
> Yes.

Done.

>>> Editorial Comments:
>>> 
>>> - Section 1, paragraph 6 (First paragraph after numbered list)
>>> 
>>> This paragraph goes a bit far into value judgements. Can we dispense terms like "bad design" and "socially undesirable”?
>> 
>> This text came more or less verbatim from Stephen Farrell during the TLS WG review of the document and is what they signed off on. I hesitate to undo that at this point, but we can discuss it as part of IESG review.
> 
> Okay.
> 
>> 
>>> 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.

-G