Ballot for draft-ietf-avtcore-multiplex-guidelines
Yes
No Objection
Recuse
Note: This ballot was opened for revision 10 and is now closed.
Thank you for an interesting, and readable document.
Thank you for addressing my Discuss point. A couple things I noticed while reviewing the diff: Section 3.1's "might not be the choice suitable in another situation or combination of reasons" seems like it's comparing things of different types. Section 4.3.1 now has: SRTP [RFC3711] as specified uses per SSRC unique keys, however the original assumption was a single session master key from which SSRC specific RTP and RTCP keys where derived. However, that assumption was proven incorrect, as the application usage and the developed key- mamangement mechanisms have chosen many different methods for ensuring SSRC unique keys. The key-management functions have I didn't try to look at RFC 3711 and see if there was now-believed-to-be-incorrect text in need of an update or not. I guess any potential violations of 3711 are in the "application usage and the developed-key-management techniques" that we describe, not in this document itself, so there's not really a question of this document being in conflict with 3711. Also, nit: s/mamangement/management/
One processing question: Should this document update RFC3550 given the last paragraph each in section 3.4.1 and 3.4.3? And one comment on section 4.2.1: "Different Differentiated Services Code Points (DSCP) can be assigned to different packets within a flow as well as within an RTP stream. " not sure what you mean by flow here but at least RFC7657 says "Should use a single DSCP for all packets within a reliable transport protocol session" Maybe you can say a bit more here to ensure the guidance provided in RFC7657 is reflected accurately. Even though I didn't see any discussion of the TSV-ART review (Thanks Bernard!) I believe all comments have been addressed. Thanks for that! Fully editorial minor comments: 1) In the intro maybe: OLD The authors hope that clarification on the usefulness of some functionalities in RTP will result in more complete implementations in the future. NEW This document aims to clarify the usefulness of some functionalities in RTP which will hopefully result in more complete implementations in the future. 2) sec 3.2 s/one or transport flows/one or more transport flows/ And maybe also s/transport flows, e.g. an UDP destination port./transport flows, e.g. based on the UDP destination port./? 3) sec 3.2.1: " RTP does not contain a session identifier, yet different RTP sessions must be possible to identify both across different endpoints and within a single endpoint." Not sure I can parse this sentence correctly... 4) sec 4.1.3: s/Signalling, choosing and policing/Signalling, choosing, and policing/ -> missing comma 5) sec 6 maybe: s/specification writers/specification designers/
I am a co-author