Subject: Re: [AVTCORE] Spencer Dawkins' Yes on draft-ietf-avtcore-rfc5764-mux-fixes-10: (with COMMENT)

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 1 Sep 2016 22:19:28 +0000

Hi Spencer  - 

Thanks for your review. Sorry for the delayed response but things got hectic. 

Responses inline..

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for doing this update. You're helping avoid problems later.
> 
> This specification was pretty dense and difficult for me to understand
> (there's quite a bit going on), until I got to the OLD TEXT/NEW TEXT in
> Section 7, which made everything much clearer. You might consider moving
> Section 7 forward, so that the organization of the document becomes "here
> is the new multiplexing scheme", followed by "here's why the changes are
> needed”.

I’ve thought about this and quite honestly I’m not seeing it.  I know you’re simply making a subjective statement about stylistic preference, but given this document was reviewed and WGLC’ed by 3 different WGs it feels unwise to start moving section order around this late in the game and considering nobody else has mentioned anything similar.  Does that resonate and are you OK with such inactivity being the resolution?

> In these list entries:
> 
>   1.  It implicitly allocated codepoints for new STUN methods without
>       an IANA registry reflecting these new allocations.
> 
> and
> 
>   3.  It implicitly allocated codepoints for new Transport Layer
>       Security (TLS) ContentTypes without an IANA registry reflecting
>       these new allocations.
> 
> is it correct to say "without entries in an IANA registry reflecting
> these new allocations"? I was reading the text as saying there were no
> registries for STUN methods or TLS ContentTypes, but that's not what you
> meant, is it?

No.  The intent is to say that the allocations made by the multiplexing algorithm in 5764 implicitly and inadvertently allocated TLS ContentTypes and STUN Methods that were unintended and overlapping.  This document updates the multiplexing algorithm so that these are are non-overlapping and it cleans up the IANA registries by making the allocations explicitly distinct.  I’ve re-read the text and I think it indicates this clearly.

Cheers,

Gonzalo

Thanks,

Gonzalo

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Sep 2016 18:45:39 -0500

Hi, Gonzalo,

On Thu, Sep 1, 2016 at 5:19 PM, Gonzalo Salgueiro (gsalguei) <
[email-masked]> wrote:

> I’ve thought about this and quite honestly I’m not seeing it.  I know
> you’re simply making a subjective statement about stylistic preference, but
> given this document was reviewed and WGLC’ed by 3 different WGs it feels
> unwise to start moving section order around this late in the game and
> considering nobody else has mentioned anything similar.  Does that resonate
> and are you OK with such inactivity being the resolution?
>
> > In these list entries:
> >
> No.  The intent is to say that the allocations made by the multiplexing
> algorithm in 5764 implicitly and inadvertently allocated TLS ContentTypes
> and STUN Methods that were unintended and overlapping.  This document
> updates the multiplexing algorithm so that these are are non-overlapping
> and it cleans up the IANA registries by making the allocations explicitly
> distinct.  I’ve re-read the text and I think it indicates this clearly.
>
> Cheers,
>
> Gonzalo
>
>
>
> Thanks,
>
> Gonzalo

That's all fine, of course.

Spencer