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

From: "Ben Campbell" <[email-masked]>
Date: Sat, 16 Jul 2016 23:56:10 +0200

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?

-1, last paragraph:

Are there any plans to fix 7345 or bundle-negotiation? I see that 7345 
replicates language from 5764 rather than references it, but it looks 
like a fairly easy fix. 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.
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.

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"? 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"?

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 19 Jul 2016 12:53:36 +0000

Hi Ben - 

Comments inline…

> On Jul 16, 2016, at 11:56 PM, Ben Campbell <[email-masked]> 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.

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

> 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 filing an errata? 

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

> 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

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

> 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”?

Cheers,

Gonzalo

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 19 Jul 2016 15:06:57 +0200

Thanks, comments also inline:

Ben.

On 19 Jul 2016, at 14:53, Gonzalo Salgueiro (gsalguei) wrote:

>> 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 co-authored 7345 with Christer, so we can have a discussion about 

Okay

> Are you think bis effort?

... or an update.

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

>
>> 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 :-)

> 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

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

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 19 Jul 2016 13:24:39 +0000

> On Jul 19, 2016, at 3:06 PM, Ben Campbell <[email-masked]> wrote:
> 
> 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.

>> Are you think bis effort?

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.

> Yes.

Done.

> 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

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 19 Jul 2016 16:09:36 +0200

On 19 Jul 2016, at 15:06, Ben Campbell wrote:

> confused about the quote from ERK. Text that is _not_ pre-5378 
> shouldn't matter.

Hrm. EKR, that is. Apparently I can't type today.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 19 Jul 2016 16:15:06 +0200

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

[...]

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

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

>>>> I see that 7345 replicates language from 5764 rather than 
>>>> references it, but it looks like a fairly easy fix.
>>>

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

[...]

>>>> Editorial Comments:

[...]

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