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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Gonzalo,

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

> 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


That's all fine, of course.

Spencer